Green Lumber Fallacy in Software Engineering

“Green lumber” is a term used to describe freshly cut lumber. One of the most successful traders of green lumber, Joe Siegel, mistakenly thought that green lumber was lumber that had been painted green. Joe made a fortune trading green lumber without knowing what it was. Other commodity traders, more well-versed in the theory of commodity trading, scoffed at Joe’s lack of what they believed to be “essential knowledge”. But while these academic style traders (many of whom went bust) obsessed over semantics and theories of what caused lumber prices to change, Joe did what he does best: trade lumber. It appears that knowing the origin of the term “green lumber” is irrelevant to becoming a successful green lumber trader, no matter how much theoreticians want to believe otherwise.

Nassim Nicholas Taleb coined the term “Green lumber fallacy” to describe scenarios where a group of people in a domain mistake irrelevant knowledge for essential knowledge. There’s a green lumber fallacy in Software Engineering. Particularly during the interview process, where candidates are expected to solve programming puzzles that require knowledge of data structures and algorithms (DSA). These test-like interviews mistake the trees (data structures and algorithms) for the forest (building software).

Sure a general grasp of data structures and algorithms helps to build software, but software development is not data structures and algorithms. Data structures and algorithms are variables ($x_1, x_2$) that contribute to the function of software development ($f(x_1..x_n)$), which is dependent on a bunch of other variables like verbal and critical thinking ability. Personally, I’d take working with someone who’s great at naming functions and variables over someone who can code a solution to the knapsack problem.

Max Howell, author of the most popular package manager on macOS, was rejected by Google for failing the technical portion of his interview. Despite having a proven track record of creating successful software (likely used by thousands of Google engineers), Max couldn’t invert a binary tree on a whiteboard, so he was given a thumbs down. That’s like cutting Shaquille O'Neil from your basketball team because he didn’t hit enough free throws in the try-out. There’s more to the game.

All the MAANG companies use algorithmic and system design style questions as their main metric for hiring candidates. The internal justification for doing so is likely a combination of “this is what everyone else does” and “it’s a quick way to evaluate someone’s skill”. To the first point I say: “everyone else is doing it wrong.” and to the second point I say: “yeah, quick way to evaluate their competitive programming skills.” I’ve never heard of an ex ICPC competitor go on to build a great piece of software, yet I’m certain every ex-ICPC competitor would outperform the best software creators on interview-style questions. It’s almost as if their entirely different skill sets.

You’re also likely to disappoint candidates (particularly junior ones) who after going through a technically rigorous interview process find that the actual job is devoid of such mental stimulation. Instead of solving difficult problems on a tight timeline, as is done during the interview process, the real job consists mainly of writing docs, reading code, and connecting a bunch of AWS services together like grown-up Legos. The following meme does a great job of illustrating this point:

The solution to the Green lumber fallacy in the software engineering hiring process is to acknowledge that solving DSA-style problems and building software are two different things. The closer your interview process is to the actual job, the more accurately you’ll be able to assess a candidate’s ability at performing that job. Including take-home assignments and pair-programming in the interview process are steps in the right direction 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. Critics of this suggestion are usually quick to rebuttal with “Candidates would never agree to that” and “It doesn't scale”. I'd personally love a trial-based process that gives me insight into what the day-to-day actually looks like, what the real culture of the company is, and what my teammates are like. And I know plenty of engineers that share this sentiment. I agree trial work periods may not scale, but you know what else doesn’t scale? Hiring a bunch of people who lack the skills outside of DSA competency, such as communication and work ethic, that are required for building great software.