By Eric Giguere
To non-programmers, the technical interview process seems cruel and heartless. After screening by a recruiter, the candidate is subjected to a series of personal interviews that test both their programming skills and their problem-solving abilities. Armed with nothing but a marker and a whiteboard, the candidate must convince each interviewer that he or she has the chops to make a meaningful contribution as a software engineer at their company. No chops, no job—it’s that simple.
Programming interviews are a way to optimize the hiring process, much the way a compiler optimizes code. One of the simplest compiler optimizations is dead code elimination, which removes code that will never execute. Dead code elimination yields smaller executables and speeds the remaining optimization steps. Not to be harsh, but technical interviews are a form of dud coder elimination—a way to weed out the people who can code from those who can’t.
The sad truth is that many job applicants with computer science or software engineering degrees don’t actually know how to code. They may understand the technical and theoretical aspects of programming. They may know how to manage projects and teams. They may be able to give great presentations. But they can’t write good code.
Writing good code is a skill you develop mostly by writing a lot of bad code. Like any craft, it takes time and effort to develop good coding skills. The more you write, the more you learn.
The dud coders haven’t written enough code to develop those skills. A typical computer science or software engineering program doesn’t involve a whole lot of in-depth, hands-on individual programming in real-world scenarios. Dud coders can thrive in these programs by doing well on the academic side and choosing the right teammates for class projects.
Hiring a dud coder can be problematic. At best, they’ll distract the other coders by requiring extensive mentoring and in-depth code reviews and rewrites. At worst, they’ll affect the group’s morale and make negative contributions to the codebase. Dud coders eventually get fired or transferred, but they can really set a project back.
Every coder, dud or not, also has a learning curve. It takes weeks to learn a new codebase and the related development tools. Companies may not realize they’ve hired a dud until months have passed.
Unfortunately, recruiters can’t always tell the duds from the non-duds, especially when they have the right accreditations and experience. The only way to ferret out the good coders from the bad or inexperienced ones is to get them to program something.
Companies could hire software engineers on a probationary basis in order to properly assess their programming skills. In fact, internships and co-op work terms are a great way for firms to find raw talent without any long-term commitment. But short-term probationary contracts don’t appeal to most programmers, especially the skilled ones.
Enter the programming interview. While it’s not a perfect process by any means, it’s a great way to get some good signals on how well a candidate can program. Several detailed interviews by experienced interviewers—software engineers who went through the same hiring process and have been trained to ask good questions—is usually enough to discern the dud coders from the good coders. And if there’s any doubt, the hiring committee will err on the side of not hiring the candidate—that’s the price most companies are willing to pay to not hire dud coders.
That’s why technical interviews matter. And why you don’t want to interview like a dud coder. Preparation and practice are the keys to landing that great programming job. Don’t be a victim of dud coder elimination!
Eric Giguere is the co-author of Programming Interviews Exposed and several other programming books. He has bachelor’s and master’s degrees in computer science and is not a dud coder. Join the mailing list for more technical interview advice.