Why coding interviews aren't all that bad - Eli Bendersky's website

Coding interviews have never been popular in the programming community; I mean,they are prevalent, since many companies still use them to filtercandidates, but they are vastly unpopular in the community because people findthem too hard, too unfair, too unrepresentative of reality and so on. There areviral stories all around - like when the creator of Homebrew failed Google'sinterviews[1].

In this post I want to make the case that coding interviews aren't all that bad.They're certainly not a perfect way to filter candidates to SWE positions, butthey are among the best tools we've got. I've been interviewing folks for SWEpositions for almost 20 years now, and I regularly review hiring packets inwhich all of the candidate's interviews are laid out with their results andrecommendations.

First, what do I mean by "coding interviews"? Typically, writing some moderateamount of code (in the order of 50 lines) throughout the interview, involvingnothing more than simple and fundamental data structures. Linked lists, graphs,arrays, binary search trees at most. Many interviews will also examine one ormore horizontal aspects like recursion, parsing simple data, and discussing theruntime and storage complexity and performance of simple algorithms.

To reiterate, the best coding interviews are relatively simple questions thatdon't require deep familiarity with graduate-level data structures, but dorequire a good understanding of programming fundamentals. I don't ask candidatesto invert binary trees,but whoever does ask this question most likely doesn't ask it because it isrelevant to their work projects; rather, they ask it because it probesthe candidate's understanding of recursion, basic data structures, debugging andcareful treatment of pointers or references (depending on the language).

The reason I prefer asking coding questions is because I firmly believe theyare the most objective way to evaluate candidates. Solving a coding questionremoves so many subjective factors, especially related to the candidate'sdemographics and background, and the majority of the commoninterview biases.

A good way to think about this is to consider one of the alternatives commonlyproposed to coding interviews: just talk to the candidate, ask about theirbackground, their past job, the problems they were solving, etc. I actually havean educational story related to this, from my own experience.

Many years ago in a company far away, I was just starting to interview full-timecandidates (before that I only had experience interviewing interns). In thatcompany, we would do 90-minute interviews in pairs, and I waspaired with an experienced engineer. The candidate was amazing at talkingabout themselves and after 20 minutes I was convinced they should be accepted;my experienced partner, however, calmly proceeded to asking a relatively simpletechnical question (this was a HW design interview and the question had to dowith designing a basic low-pass filter). The candidate was immediately lostand fumbled for an hour. I remember feeling shocked; how is it possible thatsomeone obviously so good can't do something so basic?

I keep encountering a variation of this scenario all the time, to this day, butI'm rarely surprised any more. I learned that just talking to candidates isa sure way to get an extremely biased view of their skills. I do think that ina slate of 4-5 interviews it's important for one of them to be more personalwhere the interviewer gets to know the candidate and tries to assess if theyare pleasant to work with. But the majority of the interviews have to objectiveand technical, IMO.

Another commonly mentioned alternative to coding interviews is take-homeprojects, where the candidates get a sizable assignment to complete at home;this assignment can take on the order of 2-20 hours and is meant to evaluatethe candidate on a much more realistic project than a 45-min coding interview.

There are at least three major challenges with this approach.

First of all, candidates don't like these - since they may take a long time tofinish, and this doesn't scale well when you're applying to multiple jobs. Manystrong candidates will be put off by the requirement to spend multiple hours ona programming assignment; since finding strong candidates is one of the biggestchallenges companies face, this is an important factor.

Second, these assignments are a burden on the hiring team as well, since theytake a long time to prepare and evaluate. While this may not be a problem for"one off" hiring quests, anyone who's familiar with the plight of SWEs whohave to spend lots of time on interviews and hiring while also doing theirdaily jobs because the company is in a growth spurt, will recognize this issue.

Third and most important - these assignments are very vulnerable to cheating,and cheating is absolutely rampant in the industry. These days it's easy toencounter cheating even on mainstream, open platforms like Reddit,not to mention dedicated services like LeetCode or "code for hire" serviceswhere candidates can buy solutions for money. This isn't a new problem, either.When I was toying with RentACoder 15 years agothe majority of projects I ended up doing were either homework or "do my workfor me" assignments.

Now, coding questions are vulnerable to a kind of "cheating" as well - forexample, you can probably find 95% of the questions Google asks on LeetCodethese days, but this is very different IMHO. Sure, you can engorge yourself byreading hundreds of questions & answers on LeetCode, and come to the interviewready. But in my experience, when you're faced with an interview you're still onyour own and the interviewer can typically ask tangential questions that willexpose someone who just memorized the answers. Enforcement is much harderwith take-home exercises.

Lately I've seen a lot of discussion about how the way interviews are currentlydone is bad for diversity. The issue of diversity is very important for theindustry, for sure. I agree that companies should be seeking ways to diversifytheir work force - and how to do this properly is a genuinely hard question thatis an active area of academic research.

That said, IMHO coding interviews are a significantly moreobjective way to evaluate candidates from the diversity standpoint.The "tell me about yourself" style of interviews is extremely subjective andopen to bias. What better way to activate the automatic rapport people feelfor someone with background similar to theirs, and the ingrained lizard-brainantagonism to anyone different?

"Take-home projects" are much more subjective too, because guess what - thecheating is much more available for someone with the money already. As recentexposésdemonstrate, when important life-long goals are in play, people will do whateverin their power to get ahead. Folks from a poor background looking for theirfirst high-paying job will not be in a position to pop a $1,000 for someoff-shore programmer to solve their take-home question, but someone else would.

Hopefully this post clarifies why I think that coding interviews, while notperfect, are an important objective evaluation technique for hiring SWEs. I'mnot saying that coding interviews should be the only criterion, only that theyare an important signal that should not be dropped from any hiring process.

To paraphrase a well-worn Churchill quote:

Indeed it has been said that a coding interview is the worst form ofinterview except for all those other forms that have been tried fromtime to time

All of this is IMHO, of course, and I only speak for myself here.

本文章由 flowerss 抓取自RSS，版权归源站点所有。

查看原文：Why coding interviews aren't all that bad - Eli Bendersky's website