From fca01892543dd9b0dc4b57d1f78c58b5a9adf164 Mon Sep 17 00:00:00 2001 From: R Tyler Croy Date: Thu, 2 Feb 2023 16:35:16 -0800 Subject: [PATCH] I had a less angry title in my first draft, but this one is more fun and click-baity --- .../2023-01-27-coding-interviews-are-bad.md | 79 +++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 _posts/2023-01-27-coding-interviews-are-bad.md diff --git a/_posts/2023-01-27-coding-interviews-are-bad.md b/_posts/2023-01-27-coding-interviews-are-bad.md new file mode 100644 index 0000000..497f023 --- /dev/null +++ b/_posts/2023-01-27-coding-interviews-are-bad.md @@ -0,0 +1,79 @@ +--- +layout: post +title: "I think coding interviews categorically suck" +tags: +- software +- leadership +- management +- opinion +--- + +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](https://artiss.blog/2019/03/the-automattic-hiring-process/) 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.