During today’s walk around Greenlake, I decided to reflect on an article I recently read – “Green Lumber Fallacy in Software Engineering“. In the article, the author describes the interview process in the software industry as a green lumber fallacy – mistaking irrelevant knowledge as essential knowledge. The author raises the point that the algorithm and data structure questions asked during tech interview are not relevant during the day-to-day job of a programmer. I would agree with the author that the current tech interview procedure is not the most ideal way to measure a person’s talent of programming. However, I would like to discuss from another perspective: knowing the kind of questions being asked during interviews is not super relevant, how should we – the job applicant, get prepared?
One “practical” school of thought might goes as the following: I don’t care what is relevant on the job, what’s important now is how to get the job. People subscribe to this idea usually will continue to focus on studying the code problems, ignoring the warning of “green lumber fallacy”. I would like to give a name to them – the “metric optimizer”. For a metric optimizer, it’s not important to think about the metric itself – what does it measure? why people use this metric. Instead, the score is everything. “I need to get the highest possible score, that means I’m the best”. In an ideal world, when we have perfect metrics, being a metric optimizer will be ideal. Unfortunately, the world is imperfect and we don’t have perfect metrics. My experience tells me, optimizing against the code problems will only help you reaching a certain level – solving small, well-defined problems. I’m not saying solving small, well-defined problems is naive or worthless, my point being: there just so much more down the road.
You might want to ask what’s my suggestion to people preparing for a programmer job. Here’s my 5 cents: you may want to balance your short term and long term investment. For short term investment, I’m referring to spending time in improving your interview performance. This would include practicing code problems, doing mock interviews, etc. If you have an interview coming right up, doing these practice is undeniably very beneficial. What I want to stress here is to invest in the long term: spending time to be a better programmer. This would include acquire more knowledge, following the latest tech trend and what’s most important for me: actually try to build something useful. Investing in long term may not raise your performance in the next day, but it will bring you to the next level if you are patient enough.
Programmers are generally expected to solve problems that have never been solved before. You could appear to be a good one if you know all the problems an interviewer might ask; you could also be a good one if you are actually good at solving unseen problems.