Imagine that you’re a principal at a small K-8 school who’s looking to hire a new teacher. As you have less than 20 teachers, you have to ensure that each person you hire can teach any of the grades. Adding to the complications, you’ve recently lost one of your best teachers, someone with 15 years of experience, and a mentor to many of the more junior teachers. How can you replace her?
After some thought, you craft what you think is a creative approach to interviewing. When the candidates show up, you will ask them to teach a lesson drawn from the K-8 curriculum. As you want to ensure that the candidate is well-rounded, you’ll hold off telling them about which lesson you want taught until the beginning of the interview. If they nail this, you infer that they’ll be able to easily teach anything, as they’ve clearly performed well under pressure, on a randomly selected topic.
You put notice out that you’re hiring, and some truly remarkable candidates apply. For the first test of this new approach, however, you plan to try it out on a referral, a teacher that one of your staff has worked with in the past and claims was the star of the school. You marvel at your luck that she even applied, and think that she’ll be the perfect test for your new interview process. You reach out to her to arrange an interview date, and tell her about this new technique you’re using, to allow her some chance to prepare.
Then the interview day arrives, and your candidate shows up at the school. You can sense that she’s a bit nervous, which is strange because she’s an experienced candidate with an impeccable resume. You decide not to dwell on that, and instead usher her into one of your classrooms to begin the interview. “I’d like you to teach me a lesson on Number Theory”. At that point her face sinks, because unbeknownst to you, she hasn’t taught 8th grade in more than 10 years. But always the professional, she goes to the board and starts the lesson. She talks about factors of numbers, and how to determine if a given number is divisible by 2, 5 and 10, but she’s struggling. When you ask about GCF and LCM, she needs clarification about the acronyms, which you interpret as a bad sign. You explain that you’re referring to “greatest common factor” and “least common multiple”, but at this point you can tell that her confidence is shot, and you pick a tinge of annoyance in her voice.
At the end of the hour she’s stumbled through the highlights of Number Theory, but hasn’t at all filled you with a sense of confidence that she could nail this lesson in front of a group of misbehaving 8th graders. She performs very well on several other behaviour-based interviews, but you can’t shake this feeling that maybe she’s not the best in-room teacher. After some deliberation, you decide to pass on her, and hire a much less experienced teacher who excelled on the “lesson test”.
While this may seem like a completely contrived example, and a strange way to interview a teaching applicant, it is precisely the method used to interview software engineers. While I’m not here to ague that coding interviews are entirely broken (though others have), I strongly believe that they have no place when interviewing senior engineers.
Why? Simply put, senior engineers are different, and the typical coding interview puts them at a disadvantage for a number of reasons:
- They take a ton of prep time to nail — As coding interviews draw from the entire domain of software development, they’re very difficult to prepare for exhaustively. This problem is amplified for senior engineers in a couple of ways. First of all, by definition, they’re further removed from their schooling, which may be the last time they encountered some of the more esoteric aspects of software development (dynamic programming, red-black trees, or even recursion). Refreshing their memory on a wide array of algorithms and data structure can take a significant amount of prep time. Add to this, the fact that senior engineers are more pressed for time (they have demanding jobs, and often have significant personal responsibilities) and this becomes a perfect storm. I know of several cases where senior engineers have inquired about the interview process at a given employer, and on hearing that there was a coding interview, have declined to interview.
- They push senior engineers to work differently — Senior engineers are far removed from the bare-bones development environments that are used in coding interviews. They typically have highly tuned environments, refined over many years, and designed to free them from the unnecessary burdens of coding. To take that away from them, at a time where artificial time constraints are imposed no less, puts them at a significant disadvantage. Furthermore, they may have spent the last few years working with the proprietary libraries (memory management, error checking, tracing) of their existing employer. A coding interview abruptly pulls them out of their comfort zone, back into the world of standard libraries and simple text editors.
- https://extranet.who.int/icfrevision/Uploads/d/dede-6784134.pdf
https://extranet.who.int/icfrevision/Uploads/d/dede-743772.pdf
https://extranet.who.int/icfrevision/Uploads/d/movies-5415973.pdf
https://extranet.who.int/icfrevision/Uploads/d/movies-7309880.pdf
https://extranet.who.int/icfrevision/Uploads/d/movies-6044351.pdf
https://extranet.who.int/icfrevision/Uploads/d/Box-Full-Movie-free-7354077.pdf
https://extranet.who.int/icfrevision/Uploads/d/Box-Full-Movie-free-1788477.pdf
https://navarrocollege.instructure.com/courses/28149/pages/123movies-watch-honest-thief-2020-full-movies-online-free
https://www.klusster.com/portfolios/maxio/contents/73433?code=2b84e920-febb-4e47-8b52-63956c72b928 - Perhaps the most egregious aspect of using coding interviews with senior engineers is that they only test a small aspect what you’re hiring them to do. Senior engineers typically make 3–5x (or more) than new grads. Expecting them to produce 3–5x more code than a new grad is obviously not reasonable — there just aren’t enough hours in the day. Instead, you’re looking for them to enable teams of junior engineers, mentor those people, identify systemic problems, debug the most complex of issues, and when coding, understand complex systems and the intricate work required to code within them. None of these aspects are tested in a coding interview, and it’s one of the main reasons why senior engineers hate them.
- They send a bad message — Just as you know that you’re not principally hiring a senior engineer to code, they know it too. But when you stress coding interviews in your hiring process, you make senior engineers second guess the role for which you’re hiring. “Are they just going to want me to be a code monkey?” “Will I be wasting my talents here?” “Is this a step forwards, or a step backwards?” The last thing you want is for a talented engineer to have doubts about the role, or your company, in the interview process. Asking them coding interview questions does just that.
Sum all of these factors up, and it’s no surprise that senior engineers hate coding interviews. If you’re looking to attract the best senior engineers and reduce the interview friction in this especially tight labour market, I’d suggest you stop asking them coding interview questions.
But, you may be thinking, how will I know if they can code? If you’re leery about hiring a senior engineer without any sense for their coding abilities, I’d suggest you provide a very short take-home assignment (which takes no more than an hour or two to complete). Most senior engineers should be able to find a small amount of time to complete such an assignment, especially since doing so eliminates the prep work required with a coding interview, and can be broken up into smaller time slices that better fit into their busy schedules. A take-home assignment also allows them to work in their native IDE (if they so choose) and spend any time necessary to reacquaint themselves with standard libraries.
As an added benefit, the fact that the applicant can devote as little or as much time as they want to this exercise, allows you to gain insight into what makes them tick. Are they thoughtful with comments? Do think comprehensively about testing? Have they structured their code in a reasonable and understandable way? Do they care deeply about the quality of the work they’re submitting? Put another way, you’ll know not only if they can code, but if they can code well, and in a more realistic setting.
Senior engineers are the lifeblood of any software organization. They are the most desired, most expensive, and most difficult to attract. And especially in an historically tight labour market, your hiring process needs to be tailored to their specific needs, as you need them much more than they need you.
Senior engineers hate coding interviews, and if you’re looking to attract the best, you should hate them too.
