More like a) well-funded || revenue-generating firms competing in a limited pool of local talent and b) high salaries have yielded high costs of living, so to hire local, we must pay said premium
Coinbase is fully remote, i.e no local talent pool dependency, with no expectation of coming into the office, can hire from anywhere in the USA and still it mainly hires people in those locations.
It's not the only remote company where I've noticed this happening.
I too tried to get into usenet for downloading shows I wanted to watch, but I couldn't justify the cost (in time) that it would take to build/maintain a system that automatically downloads the latest episodes of select shows.
I deal w/ software all day at work. As I've gotten older, the less I want to also deal w/ software at home.
Aside from the initial fiddling I have not needed to do much of anything to my setup. It's all containerized and unraid's manager keeps them up to date for me.
25 years max for stealing billions? God bless America.
> Lichtenstein and Morgan are charged with conspiracy to commit money laundering, which carries a maximum sentence of 20 years in prison, and conspiracy to defraud the United States, which carries a maximum sentence of five years in prison. A federal district court judge will determine any sentence after considering the U.S. Sentencing Guidelines and other statutory factors.
Are they being charged for stealing? I thought the concept of crypto is to be you own bank, So as long as you have the private key, you are now technically the owner.
What if two people generate the same private key. Who is the owner ?
they haven't actually been charged with hacking, just the laundering. the complaint could be amended after investigation and the potential sentence would go up.
Given that folks have been given longer punishments for stealing less, yes. Granted, ianal and I acknowledge that things come into play like repeat offenses, etc.
Off the top of my head, I can think of a couple of things it tests for:
* Ability to reflect on and critique their own ideas, using technical common-sense. If someone has never had a reason to research or think too hard about how GPS works, then it might be reasonable to initially assume that it sends a signal to a satellite. But hopefully, when prompted to think about it a bit more, they would realize: "Hey, if that's true, then somehow these satellites that were launched in the 80's and 90's were able to scale up their capacity and handle orders of magnitude more demand, now that everyone has a smartphone in their pocket. Maybe that's not how it works?"
* General curiosity and interest in areas outside their field of specialty. This might not be strictly necessary to get a job done, but it probably has some correlation with other measures of technical aptitude that are hard to probe directly.
> General curiosity and interest in areas outside their field of specialty. This might not be strictly necessary to get a job done, but it probably has some correlation with other measures of technical aptitude that are hard to probe directly.
I think this is a bit misguided, since the scope of things outside of a candidate's field of specialty is tremendously large. Picking a random piece of tech within that space and drilling the candidate about it seems rather unfair.
A better way to handle this would be to actually ask the candidate about what else interests them outside of their specialty. But hey, maybe that doesn't stroke the interviewer's ego enough (:
Fair enough. I understand where you're coming from, at the end of the day I guess it depends on the context and the way the question is presented (left-field questions such as this one can be somewhat fun to try to answer and hypothesize about, if the interviewer creates a friendly environment to do so)
I hear ya. I would definitely not disqualify someone for not knowing the answer.
In fact, someone who is able to sort of work through the problem on the spot may even be preferable to someone who just knows the answer because they happened to read Wikipedia the week before.
Because that’s not a problem you can solve with software and algorithms. That a chemical and lithographic problem that requires a knowledge that rarely overlaps with software.
However GPS can be solved with some high school maths, and applying solutions found on the software engineering domain E.g. computing distance from latency, communicating with a remote resource over a comms link, broadcast vs unicast etc
It’s not like the interviewer is going to ask them to design the satellites and rockets themselves.
Because that's a lot more obscure. A better example might be asking something like "what's the difference between cache and RAM" or "what is a CPU register", which I'm starting to think will still catch objections from some people on the grounds of it not being relevant to Javascript.
Asking how GPS works (in general terms) is more like asking how the Internet works. Anyone who has "engineer" attached to their job title should at have a general understanding of this, or at least be able to work through it using common sense on the spot. I know we covered it early on in college (maybe in Physics, I forget).
Again, I'm not talking about low level details here. Something like "your phone measures the time it takes the signals to arrive and calculates a distance" indicates some understanding. From there, most people can figure out how that information could be used to calculate a 3d position.
>Anyone who has "engineer" attached to their job title should at have a general understanding of this
The fact that the interviewer finds so many candidates who don't answer the GPS question to their satisfaction, while companies complain about difficulty finding software engineers, should tell you all that you need to know about the question's relevancy as well as the bizarre assumptions that some interviews hold.
"Assume you are on a relatively typical unix system, you type `ls -l` and press return, walk me through what happens in as much detail as you're comfortable with."
A decent candidate will give me 5-10 minutes of delving into various parts of "unix processes", maybe "dynamic linking", most probably a bit of "file system" by judicious use of "could you explain that in more detail" or "how does X work".
A truly excellent candidate will have me taking notes for 25-30 minutes, while they pre-answer all my followup questions, go through process creation, dynamic linking, file system API, filesystem internals, maybe some disk layout, process termination and signal handling.
Out of maybe 120 candidates I've asked that question, one (maybe two) have answered it so fully on their own that I did not have to ask any followup questions. And pretty much exhausted my question graph, so once done we could pivot to "do you have any questions for me?".
You either find out the candidate knows how GPS works or you find out the candidate's willingness to say "I don't know".
It's valuable to know how someone will handle a question they don't know the answer to -- whether they recognize their own ignorance and whether they are willing to admit to it.
There are plenty of ways to get to the bottom of what a candidate knows without resorting to unreasonable questions. What you're really testing for is a candidate's patience for being toyed with.
