On Programming Interviews

[7 minute read]

Interviewing. Bleh. Everyone hates it. Doesn’t matter which side of the table you’re on, it’s not fun. For a while my previous employer - let’s call them SuperMega Financial, Inc* - had me assessing candidates’ VBA/Excel skills. I didn’t choose who would be brought in, but my thumbs down meant No Hire. It was an eye-opening experience. Even though I still have very limited experience on the interviewer side of things, I’m going to go ahead and posit that it’s ever-so-slightly worse to be the interviewee. I’d much prefer to be the Decider of Your Fate than put My Fate in Your Hands. I’m betting you would too.

True to SuperMega’s modus operandi, I never got more than five or ten minutes notice before it was my turn to interview a candidate. Out of the blue, I’d get a call from my boss who worked on the next floor.

“Hey.”

“Can you come to my desk please?”

“Okay.”

Sometimes he mentioned he had a candidate waiting, but not always. As soon as I got to his desk, he’d hand me a resume, allow maybe five minutes to review it, then toss me in the room with the candidate like a parent dropping their kid off at college. Good luck! The first time this happened it was a tad awkward because (a) I had never interviewed anyone before and (b) I was completely unprepared. Even an hour’s notice would have been helpful, but, eh, the entire group I worked for was particularly bad at, you know, planning stuff. The candidate looked up at me with eager eyes, clearly nervous, and I thought Heh. This guy has no idea that I’m at least as nervous as he is. I shot the breeze with him for a few minutes about his previous work experiences, asked a few basic programming questions, but in the end I wasn’t terribly impressed. I no longer remember what specifically disappointed me, but what I do remember is feeling bad about it. I could tell he really wanted the job and I, having been bestowed with the Power to Decide His Future, had a hard time saying no. I was actually surprised by the strength of the urge to give in and be this guy’s savior. But my boss, well accustomed to the process, simplified matters greatly. He didn’t want details. He didn’t want explanations, justifications, or rationalizations. All he wanted was a yes or no. I hesitated for a moment and imagined how quickly my magnanimity would erode into pure frustration after working with this guy for a few weeks. I said no. Then I went back to my desk to prepare questions for the next interview. I asked for at least an hours’ notice next time, but knew I wouldn’t get it.

My own interview with SuperMega Financial was the first time I was asked to write code on paper. I was immediately uncomfortable. Code? On paper? But… but… okay. In retrospect, I’m really glad they had me do that. Writing code without the help of IntelliSense in a stressful situation like an interview isn’t exactly fun, but it is pretty much standard fare for programming interviews and practice is good. As with most things, it’s a skill you have to learn. The irony was that of my four interviewers, it turned out only one knew enough VBA to tell if I was actually writing legitimate code or just bullshitting. I guess they assumed if I didn’t know what I was talking about I would just stare at them like a frightened bunny instead of getting started. Certainly not a tactic I would consider foolproof, but I suppose that’s why they started having me do the programming assessments after a few months on the job.

Some of the reactions I received upon handing candidates a piece of paper and a pencil and asking them to write code were interesting. Few were confident and unfazed. Most got this look in their eyes like I had pulled out a butcher knife and demanded their spouse’s head on a plate. Really, the questions I asked were not hard. A typical question would be like write a function that takes a range as a parameter, copies the contents to a new range offset by ten columns, fills the new cells red, and the original ones yellow. One lady—who incidentally had a resume five miles long—got so nervous that her hands shook uncontrollably. She could barely write. Another guy sounded so awesome (like, awesome-awesome) while describing his previous projects that I felt myself start to swoon a bit. But when I asked him to write code he went from Captain Confidence to Sally Sadface in about a second and a half. After I slid the paper and pencil in front of him, he actually pushed it back and muttered some meek objection. I apologized and emphasized that I hated writing code on paper at least as much as he did, but we needed SOME demonstration that he could code. He eventually did write something, but it was complete garbage. He couldn’t even declare a function correctly. It’s possible he really was an awesome programmer who just got devastated by nervousness—I’ve certainly bonked out from nervousness before—but the gulf between what he said he could do and what he could show me he could do left me fearful that he was a bullshit artist, so No Hire.

Since I’ve been doing a lot of interview prep lately, I’ve come across quite a few blogs that make the same complaint I just did about the quality of software development candidates. Many take a melodramatic tone: “Why can’t programmers program!? Oh god, WHY!!!” Well, maybe they can. Maybe your candidates are just nervous and bonking out. Once, when I was interviewing for a very Excel-centric position about three years ago, I bonked out on a VLookup question. It was horrible. VLookup has to be one the five most commonly used functions in Excel. This isn’t advanced stuff; this is I-could-teach-my-mother stuff. My brain was screaming YOU KNOW THIS, YOU IDIOT! WTF IS WRONG WITH YOU?! But I was slightly intimidated by my surroundings, had already put my foot in my mouth earlier in the interview, and just went completely blank like a TV station going off the air. The rest of the interview went, well, pretty much like Homer falling down the cliff. And, of course, the very instant I left the interview, I remembered with perfect clarity how to use VLookup. (If you’re wondering, no, I was not offered the job.) But barring the Nervousness Theory, it may seem a bit confounding that so many people fail fizzbuzz type tests. But me, I’m not really all that surprised. Consider the following:

Exhibit A: The software development industry is relatively accepting of autodidacts.

Exhibit B: The software development industry is one beset by training materials claiming to teach you pretty complicated stuff in stupidly short amounts of time. “Learn C++ in 21 days!” Riiiiight.

Exhibit C: People are, well… here, watch this, Tommy Lee Jones says it best. (When I say it I sound like a jerk.)

So, you take A + B + C and what do you get? A number of candidates whose assessment of their own programming skills isn’t quite in line with reality. Frustrating, maybe, but no big surprise. Better to be disappointed by incompetence at the interview stage than after the hiring process is complete. And it’s definitely better than being He (or She) Who Is At Your Hiring Mercy. But I have to say, I’m pretty thankful to have at least some appreciation of the thought process on both sides of the equation. Conducting interviews myself is probably some of the best interview prep I’ve ever gotten, even if I had to disappoint a few people along the way.


*Not their real name. :)