Green Lumber Fallacy in Software Engineering

EDIT: I have made it through those interviews. That's not really the point. The way you make it through is by preparing, just like you'd prepare for the test in school. Doesn't show anything.

We paid them for the week like a contractor, and made an evaluation at the end of the week. It weeded people out who were great at code but bad culturally, or people who worked great.

Sometimes we couldn't get a whole week to commit, but just a few days -- but these days made a huge difference.

Now, I work at a FAANG company and _hate_ the interview process. Give me 3 months and I think I could teach just about any CS interview how to pass it (without being specific to any particular FAANG company), but that doesn't mean they would be good engineers.

They are loosely related but different skills.

exactly. i mean like try to apply to IB at a BB and see if anyone even skims your resume without an ivy+ on it. they can't fathom how good they have it because they've never done anything else (which is, of course, what breeds entitlement).

i'm good at what i do - my implementations are clean. they got that way (surprise surprise) as a side-effect of me implementing many times.

Because I've seen the algorithm more recently than "school" but perhaps not "last night while feverishly cramming so I can forget it in a week". Because I've probably solved the problem I'm looking at before, if not a neighbor close enough to get me in the ballpark, and I am never going to be without a search engine for the actual triviality that is the solution once that is identified. Because it is. It is triviality that has been turned into a measuring stick for one's technical coupling equipment by folks who have no better metric by which to evaluate. (And, to be fair, it's not the worst metric. It's also not a great one, though.)

The example that comes to mind first: I've written a topographical sort half a dozen times over the years. I recognize the problem set that it applies to on sight. And I do not have enough time in my ever-shrinking lifespan to bother to memorize how to write the thing optimally, though if I squint a little I'll probably get something that's okay if I sat down and spent half an hour with a REPL. (EDIT: went and looked up the last time I did it, and it's actually pretty good! Though bounded for `n` because I knew `n So I'm not going to shed tears that I look it up when I run across a case where it's appropriate. Does that mean that on the movie set of a never-gonna-happen where I absolutely must create a satisfaction plan for a dependency tree that runs in absolutely minimal time, the bomb's gonna blow up and kill the President? Yeah, sure, but I live in the real world.

It doesn't happen a ton, because if we're being honest most jobs even at highly scaled companies are pretty Lego-y these days--but probably once or twice a year, yeah, I go "oh, that's an XYZ problem" and Google how to implement the optimal solution (or find that there's a package for it already).

Recognizing the shape of a problem is a skill. Calling to mind the exact algorithmic solution to that problem is a different skill. One of those two things is something that Google can do. (We are nearing a world where one of these two things, GPT-3 can do.)