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.
You literally wrote "If crime remains a constant then having shitty software security is a safety valve" - so there is some implication otherwise how would that work? Why would crime become constant? If these are two different groups of people, why don't we have increase in both? This explanation seems too simplistic to me.
I can only respond to the part of your question that is coherent to
me. The "how would that work?" part feels ill-formed and something
I've already answered.
But "Why would crime become constant?" is very interesting. For that
we turn to "criminology" [0,1]. Roughly, there are three "layers",
biological, psychological and sociological. All of these are either
fixed, or very slow and hard to change.
Indeed the biggest factors in "how much crime there is" are laws and
reporting, how visible the crime is. Obviously we could make crime
disappear overnight by declaring all behaviours legal. Really, the
justice system can only absorb and respond to what the underlying
social and economic conditions set.
Most crimes are resource motivated [2]. Violent crime makes headlines,
ruins lives, changes votes and is generally undesirable. "Soft" crimes
are less visible and have less impact, especially when they are
against actors that are so immensely wealthy they do not even care
(for example big-tech companies that see huge fines as simply the cost
of doing business as usual)
When we have a fixed pool of criminal potential (set by these
structural conditions), which would you choose as a new criminal
entering the "market"?
And not surprisingly, Pew Research polls showed "violent and property
crimes declined by 51% and 54%, respectively, between 1993 and 2018."
Therefore the hypothesis I was curious about was whether Removing the
opportunity for cyber crime (via better security) would have the
unintended side effect of shifting crime back into physical robbery
and theft with its attendant violence.
If I understand your point correctly (I'm trying to solve the "crime rate is constant but these are not the same people" conundrum), we assume there is a fixed pool of criminal potential, with some of these people inclined more to violent crime and others for soft crime, and today we have more favorable conditions toward the latter. If so, I'd arrive to the opposite conclusion: if, instead of removing the opportunity for cyber crime, we also relaxed laws related to violent crime, cyber crime wouldn't magically dwindle trying to stick to some magical constant, because even though the pool might be more or less stable, the types of people for both are mostly different.
Not necessarily that they want to act different, or even think different, just that they are constrained in the way they act by the law in the countries they operate.
In either the Netherlands or Japan (the two countries I have experience with), it either costs a lot of money, or is nearly impossible, respectively, to fire any permanent employee. So HR’s job would be much more focused on either getting the employee to leave of their own volition, or make sure their problem is resolved.
Well, Google legally can’t do a lot of things it does to workers in other countries that it does in the US...so yes? Labor protections in the US are absolutely atrocious compared to most of the European countries where they operate.
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.
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.
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 run a lot of surveys of introductory students trying to find what topics are more or less interesting to them. A part of my dissertation was committed to it, actually.
At this point, I'm more or less certain you'll rarely find situations where you have a mass-appealing context. One students' dream context is another students Most Boring Possible. You're probably better off having many diverse contexts and hit all the MUSIC guidelines (eMpower students, Useful to their long/short term goals, make students Successful, make it situationally and domain-based Interesting, and give people opportunities to demonstrate that they Care about each other).
If fewer people decide to be electricians, then pay must go up to attract them, changing the calculus. If we force every high school student into trade school, on the other hand, there will be a glut of electricians and pay will go down.
Then what do we have? A lot of very angry people who feel betrayed by our insistence on trade school. And they'd be right to feel betrayed! We should be encouraging people to pursue fields that suit their interests, talents, and ambitions. If there are financial barriers then we need to tear them down.
The economy exists for the people, not people for the economy.
The licensed electricians I know make far more than degree holders, outside of comp engineers/doctors/MBA from select schools. For the vast majority of non selective schools and non rigorous degrees, an electrician should easily outearn them.
Electrician pay will also continue to rise quite a bit over the next decade. I already pay far more every year than the year before, if I can even book a decent electrician.
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.
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.
I hate the assumption that "this should take 2 hours", as I have been given tests like that. It involved setting up a oAuth token for Instagram or some similar service. I wasted two hours trying to get that done only to be told that I would have to wait a week for it to be approved.
I am sure half of these things are never thought through. In Python setting up a new project and downloading dependencies may involve needing to install a load of other crap and often takes more than two hours. Some libraries are incompatible with others.
If you are making assumptions that the test will take two hours, make sure that it involves minimal dependencies on third party stuff.
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 my current workplace we also administer a technical test. It is designed to take less than 15 minutes and this is communicated when it is sent out.
It consists of a small chunk of code in Java/C#/Go or otherwise that has some obvious and other not so obvious mistakes. The candidate is asked to point out any issues they see in the code.
It takes them 15 minutes to do and about 15 minutes to review the response, which I feel values time on both sides.
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".
We also did similar take homes that at most should take an hour or two if someone really went overboard. I was amazed at what was returned. It wouldn’t compile or the candidate didn’t follow simple directions. I called it our version of a take home fizz buzz.
We’re the other numbers in your funnel similar as well (phone screen pass, on-site pass, offer accepted)? I ask this because the numbers I saw in the article look remarkably similar to approximate numbers I’ve seen or been told about other companies.
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...
What it looks like to me is Firebase put more emphasis on the technical test. If you keep your exact numbers, except change the test pass rate to 25%, then you come out with 62-63 offers, which, by the argument you reference, would mean Firebase was 56% more selective.
That makes sense to me, because a smaller company needs to filter out as many people who couldn't possibly get hired at earlier stages, since the later stages are even more time intensive than code reviewing the technical test.
The ROI is probably low on the LeetCode hard questions. Most people that can solve LeetCode easy, plus have some sense of Design Patterns (so you know they can think big picture too)-- and you've got yourself a good candidate.
