lbatx

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).

So then do you believe that Google acts differently in other countries, and only (allegedly) conducts this abuse in the US?

Note: genuinely curious as to your viewpoint. Not sure what my own opinion is here yet...

Clicked on your link just to get on the list (or move up, I suppose). ;-)

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.

And how do people decide they like the trade itself? Fine line there. How are people to know about the trades if all they hear is "go to college"?

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...

Taking your comment to its logical conclusion, then, no one should become an electrician. Too dangerous. Low (relative to a degree) pay.

Well, who then is going to fulfill this necessary role?

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.

I don't think so. This guy is the second (or third or whatever) person to sue AT&T over a SIM swap. The first case is already moving to trial: https://www.coindesk.com/att-fails-to-win-dismissal-in-24-mi....

I don't have the stats in front of me, but my recollection is something like (using the same base number for Phone Screen but our rates):

Applications: 5000 candidates; ~20% pass rate (vs unknown)

Phone Screen: 1000 candidates; ~50% pass rate (vs 40%)

Technical Test: 500 candidates; ~40% pass rate (vs 25%)

On-site interview & reference checks: 200 candidates; ~50% pass rate (vs 40%)

Offer: 100 candidates; ~80% hire rate (vs 60%)

Hired: 80

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%.

Apparently you don't visit any sites using Angular?

We fought a similar battle with Javascript-enabled sites (remember when sites worked without Javascript?) and lost...

Which parts do I choose? How do I assemble them? How do I make sure they all fit together? Plus as another commenter pointed out, I can buy an off-the-shelf combustion engine. So by your logic, it should be just as easy to build an ICE car. Yet neither is easy to design/build.

EVs are not that much less complex: interior is the same (hundreds of parts), suspension, AC, heat, wiper blades, brakes, etc. The engine is certainly different but I don't think that lowers the overall complexity of the vehicle into "anyone can do it" territory.

Worldwide?

Doubtful. I put that in since absolute statements are always dangerous. I'd say at any given time, there's an excess of 20-50%. There's virtually no chance they were lacking capacity.

I guess you're not familiar with how cloud services work. There's (generally) plenty of excess capacity.

No, we need to use more of what we get. We don't use hardly any of what hits the earth. I believe I read that the Sun supplies 50X the amount of energy we consume (if of course we could capture it as energy).

There are actually plenty, most of them have the same rules, they just don't say it that way. In other words, they are tactful.

I'd say any of the bootstrapped software companies hold those philosophies (they don't need the investment, so they can set the terms).

Your analogy falls apart. Re-read what I wrote: "share in the additional profits above and beyond". Let's say we expect to make $1MM for the year. We need to keep a reserve to pay people when we are between contracts, rent, taxes, SAAS, etc. I then work out I can pay 5 people $100K each (this is an example, not actual). If we then make $1.2MM per year (for any number of reasons) how is it peculiar that the employees should share in the extra $200K? That's nothing like your analogy.

>Is being paid well not good enough?

I would say no. Since the employees are one of the keys to the success of the company, why should they not share in the additional profits above and beyond what is planned for the year?

>Companies tend to give out stock as part of a package in lieu of all cash.

Some do. In my experience, it's been about 50/50. Startups obviously tend to lean more toward equity and lower cash, while larger companies pay well and ofter options or RSUs.

I pay market and do profit sharing.

>If you have all you want in cold hard cash, what’s the problem?

I'm not quite sure how to respond to this. If you make a good salary, would you turn down even more money?

>He sounds like an asshole but really being able to work for a privately owned fast growing company without shitty options being paid well is pretty great in the tech world.

But not as great as working for a privately owned fast growing company with good options and being paid well, no?

(And if not options, strictly speaking, how about profit sharing?)

Source: I run a bootstrapped software development company and everyone has profit sharing.