This sort of implies the street criminals become cyber criminals, which seems to not be a matching skill set. Call me skeptical of the study I admittedly haven't read.
Ah, thanks. As in Expired (date). Where date is every day from the day it expires until forever. Not Expired on date, but currently expired. Makes sense now.
Hmm, in that case, it's not really Google's fault. They are following the law (maybe not in every single case, but if the protections in the US are more loose, then they can/will do things here they wouldn't do somewhere with stronger employee protection).
There seems to be a weird bug on the Google Patents site. I've noticed that the expiration date of a patent is always the day I visit the site, even for patents I know expired a while ago. This may be something like that.
Agreed. I don't see how you can leave out (among other things) databases, Big O notation, networking, and call it a computer science primer. Good for what it is, but misnamed.
You make an interesting (unsupported) assertion here. You, who find talking to an IRQ controller, real-time clock, etc. interesting, find Scheme boring, therefore others (who may not share your interests in such details) will also find it boring. Bit of a logical fallacy there...
I've always thought of "order of magnitude" as adding a zero, so anything less than 10 is a different order of magnitude.
Gets weird thinking about 9 being both one number less and one order of magnitude less than 10, while 99 is both 89 more and the same order of magnitude, but it's supposed to be a rough approximation.
So by some arguments you could say Firebase was 2.5x as selective (40 offers vs 100). With a funnel like this, even small changes to the percentages end up having a larger overall effect.
Unfortunately, we don't have the Applications number from the blog post, though he says "we considered a great deal more applicants than that [1000] on paper." I suppose a "great deal" could be anywhere from double to 10x...
That could be an even more efficient version of our test. As long as it screens for what you're looking for, I would definitely agree that shorter is better.
It feels like it tests something different than writing code, though both may be a proxy for "quality candidate".
Hate it all you want. In this case, it's true. There are no hidden factors in my description. There was no token and it was a public API.
I'm sorry you've been burned, but that doesn't mean there aren't tests that actually take < 2 hours. I can't speak to every language, but what modern toolset can't open an input file, make an http(s) call, and write to a file?
I also don't understand why we shouldn't figure out how long something takes before administering it. Several people took the test and the time ranged from 15 minutes to an hour and a half, depending on language and experience level. I will say that if someone couldn't do it in 2 hours, they wouldn't have been a good fit for the team. If several team members took it, of course we're going to make an assumption about how long it takes.
Furthermore, since we didn't prescribe a specific language, there's no reason why someone wouldn't have all of the tools pre-installed. Even so, if you had to install your favorite development environment, you'd have been fine. That also wouldn't have been part of the two hour time frame (which wasn't a limit, BTW, just how long it ended up taking competent developers).
At a previous company, we too would administer a technical test. Our pass rate was close to what was described in the article (40% for ours vs 25%). However, our test was incredibly simple. At most, it should have take a competent developer two hours to complete [including writing comments and a README].
The assignment was to read a file containing a list of numbers (some formatted incorrectly, so there was some very simple parsing logic involved), call an API using each correctly formatted number as a parameter, and store what the API returned to a file. I am to this day stunned that 60% of people who passed a phone screen could not solve this task. Note that we gave them the input file, so it wasn't a matter of an edge case tripping them up or them getting one input file but the test input file having some other edge case.
My point here is that it may be possible to get the same screening value with much less investment from the candidate.
> There are just as many counterfactuals to this strategy as there are examples. The scooter market is an especially bad - there is so much capital from so many companies - if you were trying to establish monopolies that would be a bad bet.
That's not a counterfactual. The fact that the strategy wasn't executed in this market, or was poorly executed, or was executed by too many people, doesn't mean it's not a strategy. It's just a strategy that is imperfect.
I get that they are different. It was an analogy. Either way, I don't think there's enough momentum to stop it this time either.
BTW, your argument about being able to inspect local code still seems moot in light of the fact that if you interact with the server, you still have to trust it. 90% of the code might be local, but you still have to worry about that 10% that is opaque to you. And there's no practical difference between 10% of code being opaque and 90% being opaque. The "bad stuff" could happen in that 10%.