Dud Coder Elimination: Why Technical Interviews Matter

guest blog 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 at http://www.piexposed.com for more technical interview advice.




3 responses to “Dud Coder Elimination: Why Technical Interviews Matter”

  1. j says:

    “software engineers who went through the same hiring process and have been trained to ask good questions”

    Riiiiiight. Every “technical interview” I have ever had has been led by a smoozy VP, wanting to hire a “brogrammer” golf buddy.

    The “technical interview” is the worse type of hiring; it encourages silly rote-memory exercises without any deeper understanding or demonstration of technical skill. It is a great way to find an extrovert, but an awful and often humiliating way to find real technical talent.

    The best way to hire a software developer is to have him/her walk through previous code he/she has developed, demonstrating both deep theoretical and practical expertise (or lack thereof). A friend interviewing for a prestigious corporate law office was interviewed intensely for over seven hours by various partners in the firm. They asked very detailed questions of previous cases he had investigated and tried, including extensively on case law argued at trial. But never was he asked little “quizzes” on random pieces of the criminal code. When I asked him why he didn’t have to “demonstrate his technical stills vis-a-vie random criminal code and case law, he said that would be ridiculous and disrespectful, walking through his past cases was the best demonstration. This tough but FAIR interviewing technique is how real professions find qualified talent.

    Seeing an excellent job candidate “hazed” by crap ego-driven random questions or sophomoric whiteboard drills demonstrates nothing of substance.

  2. Scott Arbeit says:

    I know that this blog post is meant to help sell the book, and I know that you wouldn’t have written the book unless you believe in technical interviews (or writing it would have sucked), but I do have to disagree. A long post about it is on my website at http://dawnoftheintegralage.com/2013/03/21/algorithms-on-whiteboards/, but the relevant part is:

    “And then there’s algorithms. Of course, all computer code implements some sort of algorithm… do this, then do that. But what I’m talking about are basic college-course example algorithms. Things that you might have learned in CS201 if you took it. They’re fundamental, and they’re lovely to know, but I’ve had a successful over-twenty-year career in IT and I have never, ever, ever seen a case where I had to know or implement one of them.

    There are definitely places where knowing the fundamentals is a good thing. If I were applying for a job in the Windows kernel team, hell yes, I’d expect to be grilled for that. If I were doing some sort of sophisticated financial analysis for a Wall Street quant group, sure. If I’m analyzing Facebook data, absolutely. But for the 99.9%+ of the rest of the coding that we need done in the world, things like web sites and internal applications and mobile apps… yeah, no. I’ve never used a linked list. I’ve never used a binary search tree. I’ve certainly never had to create one… if I ever want one, they’re provided (in the .NET Framework they’re found in System.Collections.Generic).

    Why am I [re-learning algorithms]? One reason: just to get through the interviews. When I’m done, like so much else we all learned in college and high school, I’ll forget it, not because I don’t think it’s interesting, but because I won’t be using it, ever.

    At least, not until the next time I have to interview.”

  3. Technical interviews have a great value, indeed.

Leave a Reply

Your email address will not be published. Required fields are marked *