I Detest The Live Phone Coding Challenge Phenomenon

I believe that it’s not able to accurately create a picture of someone’s coding ability, and it’s also not how problems get solved in the real world.

Yet it’s become a staple of interviewing for a job in Silicon Valley. I’ve no statistics, but I would guess that these types of interviews are now used at a majority of companies in order to assess candidates.

Believe me, I appreciate how it weeds out beginners and plagiarists. It also demonstrates how people can explain their thinking out loud and reason about a problem, solve those problems under time constraints or with limited tools at one’s disposal, and it’s a good test that one can meet a baseline level of programming ability which is required for a job. I trust that recruiting specialists who know what they’re doing probably have some convoluted justifications for why they think this particular method is effective.

The first time I had to do one of these, it was back in 2011, and the company was Facebook. I had used Linux since 1998 and worked a lot with the shell and scripting languages (Perl, Bash, PHP), casually hosting domains and mail servers and helping my more highly-skilled friends create games etc. but in truth I hadn’t been keeping up with technology closely during the 2000s and I was only just starting to think there might be a possibility of a professional occupation in it. I hadn’t done any studying or preparation.

It was a total disaster. The guy on the phone threw a problem at me (forget what it was) which I loaded up in my browser, and I spent the entire hour mumbling about how I don’t know how to do something, trying to ask him clarifying questions, making Google searches, and explaining how I’m not strong at complicated math and wasn’t familiar with some of the concepts within the prompt. In the end I generated close to zero useful lines of code. I actually think my answer was just a shebang.

These days, I know how to do basically everything an entry-level engineer should know how to do in Python, and so most of the time I can safely pass these types of challenges and be asked to advance to the next step. I’ve interviewed with many companies and have become familiar with a lot of the common prompts; I would guess that I’ve done between 10 and 20 such screenings. I understand that companies have limited time to spend on evaluating me, but I’ve grown to resent being asked to do these. I have opinions about the process itself; it’s stupid.

I think there are MANY scenarios where a candidate meeting all of the qualifications based upon past experience, someone who would doubtlessly be an absolute success if hired, will be rejected based on the feedback from the interview. This is probably happening to people every day, hundreds or thousands of times per day. It’s hard to control for all of the possible things which could go wrong.

Situations vary widely, but many companies have explicit rules against referring to documentation, and disallow you from using search engines like StackOverflow, or running one’s script in an interpreter to check the syntax for that matter. You’re expected to know that your efforts are correct. In the extreme, such strictures could be unreasonable. In any event, Coderpad and similar sites will alert your interviewer if the tab you’re working within loses focus. I can obviously sympathize with the perspective that views such assistance as cheating, so these aren’t my main gripes with the whole phenomenon.

Companies treat this screening, often the first one, as a first hoop one must jump through. If you don’t pass it; there’s a strong chance you’ll never meet with them face-to-face.

The sad part is that these silly problems, at least in my experience, seem to prevent potential employers from obtaining an accurate sense of my skillset.

Here’s the mind-blowing thing: your initial job interview is probably the only time in that role or at that company when you’ll be prevented from referring to documentation.

Let’s assume the employer has one intent: to make sure you can code. Pretty simple, right? Assuming that’s your goal it would be much more efficient to speak to my references. What would be closer to the mark? I’ll offer my GitHub username and point you to code samples and commits. A take-home challenge, where what you turn in is as good as possible.

Often, if you don’t complete the problem, then you fail the interview. If I had told my interviewer “I’m not feeling this question, would you mind showing me the next one?” I would be judged as having failed. Sometimes the person on the other line would castigate and encourage me to continue, even offering significant help and advice. Yet in actuality I just demonstrated a crucial skill which managers should want to see in a team member — being honest about one’s ability, not acting like you can handle something you can’t.

The utility of these interviews is even more questionable IMO when viewed from the standpoint of SRE. When your job means quashing alerts and debugging and troubleshooting systems on the fly, that nearly always entails access to outside resources. And this is true for people on the “Dev” side of the ops spectrum too. Practically no one develops software without referring to manpages and docs and using dependent libraries. The smarter companies out there have already tailored their questions to the department or specialty.

Ultimately, being asked to do these when you’ve been programming for 25 years is somewhat insulting.