Rethinking Tech Interviews
I know that a substantial amount of column inches (blog inches?) has been given to this topic, especially in the tech blogs, but I would like to add my two cents to it.
The current tech interview process, where there are one or more rounds of technical questions usually involving data structures or some related topic and a number of questions work reasonably well. It tells the interviewer how much the interviewee knows and how they can go through the problem solving process and if the interviewer really wants to put the interviewee under the pump, they can throw curve balls mid solution to see how they adapt.
But the problem with this approach is that it is not really how actual software development works. You might solve an algorithmic problem once in a while, but usually these problems (or a form of it) are part of a bigger problem. As such, it makes more sense to ask the candidates to build something (it could be something simple like a grading mechanism, or a school social network based on class popularity… ). Not only does this tell you more about how someone will solve an actual, real-world problem but there are also enough unique types of such problems to ensure that the person has not just read an interview preparation book cover to cover and is spewing out answers from there (let’s admit it, that does happen).