Green Lumber Fallacy in Software Engineering

But you're seeing the outcome of a selection process. You might feel differently if you saw the top of the funnel.

I agree with this. But asking the candidate to invert a binary tree is one thing and asking the candidate to flawlessly solve back to back leetcode "hard" level problems is another. I think the latter is mostly what people lament, where you end up doing so much prep that it boils down to "I've seen this one before" and you proceed to regurgitate what you memorized.

> but the best solution is to have trial work periods. There’s no better way to see how someone performs at the job than having them actually do the job.

> I agree trial work periods may not scale

Great to see the author uses the Green Lumber fallacy to argue against leetcode-style interviews. Now I'm going to guess he also must have skin in the game, otherwise he would only be an empty suit doing armchair recruiting.

Let's say we want to do work trial periods. I tell you what actually happened to us: we opened an internship position and we had ~1600 applicants. Since having 1600 trial periods is impossible, we need a way to weed this down to a manageable number. Congratulations, now you moved the problem of "who do we hire" to "who do we invite for a trial period".

The software engineering interview isn't perfect, but sadly trial periods are not the answer.

You are missing the point

> Having those guys memorize those won't make them better engineers, right?

They can't realistically memorize all the algorithms, they have to develop an understanding of graphs and algorithmic complexity to be able to get through. They should be able to map arbitrary problems to a corresponding graph problem. These are absolutely fundamental. At least I should be able to communicate to them, "use a topological sort" and they should be able to understand what I am talking about.

Sure, some one could set aside their job for 1 year and memorize everything and they might just get through the interview loop. But it is impossible to have a perfect filter, however DSA and complexity analysis is a bare minimum.

> Your next project is a video encoder. Write an arithmetic coder in a 20 minute interview? Motion detection? Your next project is a chess engine. Write minimax with alpha-beta cutoff in an interview? Your next project is public key cryptography ... A distributed k/v database... Can you write a bloom filter for me in an interview? Gradient descent in some machine learning application?

Funnily enough, none of these questions are asked in a FAANG interview at all. So, I don't know why you are constructing a strawman and demolishing it. The questions actually asked are from basic CS201. These are very specialized questions.

FWIW, I have already built a bloom filter, minhash and consistent hash at work and I am a machine learning engineer. So, I can implement an in memory consistent hash store, bloomfilter, minhash, count min sketch and gradient descent in an interview setting comfortably.

For motion detection a 2 dimensional derivative function should work. A simple delta between 2 images is a basic implementation . Huffman coding is not too complex to write. The basic entropy formula is pretty simple. In fact, most ML classifiers minimize cross entropy loss, so I am very familiar with entropy. Minimax - I have partly forgotten. But if the interviewer prompts me with some high level details I should be able to do it.

I have actually been asked to derive gradient descent in a Google staff eng equivalent interview and also demonstrate that gradient descent converges to global minima for the single layer perceptron[1]. Mind you, this was a specialist ML IC6+ position. Not a new college hire loop.

[1] You need to prove that the Hessian is positive semi definite. I did the basic set up but couldn't complete the derivation. However, I got an offer.