3.9 KiB
| layout | title | tags | ||||
|---|---|---|---|---|---|---|
| post | I think coding interviews categorically suck |
|
I recently had a good discussion with another engineering leader about the merits of coding interviews. They have long been a trusted part of the tech company interview process, but I have been mostly hiring without them over the last 5 years. Below I wanted to share some of the thoughts that I sent my colleague:
(in response to a concern about hiring somebody that can't actually build software)
I have also made one or two hires who didn't end up being able to really build and implement things. No interview process is going to be 100%, sometimes a dud gets through. :)
Many coding interviews necessarily need to fit in the time allotted and therefore are merely puzzles or computer science questions. The internet is littered with tools on how to practice your way into passing a coding interview, in fact, I have even seen a book or two at my library on the subject. For the most part, a coding interview tells you how well somebody can pass a coding interview, it doesn't actually tell you that they can build software. [SOME VENDOR] claims to alleviate some of that, but software development is a team sport and there's a lot around the programming that is expected of software engineers, especially more senior ones.
My second main concern is that it has always come across to me as almost disrespectful of people's time. FAANG companies are awful about this. Many interview processes are already requesting substantial time commitment from people, and to see companies then ask people to do a "take home assignment" or a test boggles the mind. Automatic does an interesting twist on this in that they basically pay people up front and take them on in a contracting capacity before hiring.
As a hiring manager, my objective is to determine whether somebody can build software. I will typically try to find a way without some form of coding exercise that's tailored to each candidate, for example:
-
If they're on GitHub and have activity, I'll look at open source contributions. In some cases that's sufficient, because I can see how they respond to code review, interact with others, and structure their code in a real world scenario (commit messages too!). I enjoy discussing pull request reviews with these candidates too.
-
If they don't have public activity, I will look at their resume for items which mention "design and implementation" and then we'll do more of a "code architecture" interview where I discuss that system with them and ask questions about how they structure their code, create modules, test, etc.
-
If they are simply too junior or for whatever reason they don't have anything above, then what I'll do is a "debugging interview" rather than a coding interview. Where we start with something pre-existing and debug it to make it work, refactoring along the way. In these interviews I'm typically using a bit of our production code, rather than something that's contrived.
Interviewing is hard and imprecise to say the least. Writing code is an important part of a software engineering role, but we rarely do it as performance art, making the coding interview an awkward and flawed means of assessing skill.
An HR leader I once worked with told my team and I to "find reasons to hire [the candidate]" rather than finding reasons they weren't good enough. That dramatically changed my approach to hiring. Coding interviews, like any "tests" during the interview process are finding reasons to bounce the candidate from the funnel. By taking a more personalized approach to each candidate, I believe an organization can still make really strong hires with a more respectful and collaborative interview process that results in better outcomes for everybody involved.