The other night, I was remembering what might have been my most impressive performance in the interview process. What makes this performance particularly interesting, however, is not how well Idid, but rather how I did well. And the how left me feeling unsatisfied with myself and with the process.
I was interviewing for a software development position, and this particular organization’s interview process was (1) phone interview, (2) programming exercise, (3) in-person interview. The phone interview went pretty well, and the recruiter had told me that the company was excited about me – a mildly good sign, for whatever it was worth.
![]()
However accurate the recruiter’s assessment may or may not have been, the company’s feelings were positive enough to give me the programming exercise. This all occurred back when I was in grad school, and, at the time of this particular interview, I was in a class called “Advanced Database Design,” in which we explored persistence options beyond the traditional, relational database. This was a bit of an avant garde class, at the time, because the NoSQL movement had yet to gain a ton of steam.
When they handed me the programming exercise, I had just, in this very class, wrapped up a chapter in which we’d studied using R-Trees to store geographical information. This unit of study included what they were, how they were used, and a bit of pseudocode to really drive the point home. As fate would have it, the R-Tree happened to be an extremely elegant solution to the programming exercise for this interview.
The Anatomy of Winning an Interview
This exercise felt like, as they say, shooting fish in a barrel. I recognized that the thing I had just learned was applicable to my situation, and I, well, applied it. I ran some automated tests on it for verification purposes and then turned the exercise around pretty quickly.
The company was ecstatic, and I didn’t need to try to read their reaction through the recruiter. They reached out directly about flying me out for an interview and told me, point blank, that this was by far the best solution they’d seen submitted to the exercise. I felt as though I were the hero in some really lame Indiana Jones movie, where the ancient gatekeeper had been waiting millennia for someone to come along and solve the programming exercise with an R-Tree.
I wound up passing on the interview, but only because something better came along as I negotiated the details of flying out to meet them. They were clearly disappointed, and they encouraged me to let them know if I changed my mind. I liked the company, and this overture made me feel good.
And yet, I came away from the whole experience feeling strangely empty. As good as it made me feel to have impressed a company so profoundly, there was no denying that this was largely a matter of luck. Had I done the coding exercise a few weeks earlier, I wouldn’t have known about R-Trees. Had I done the exercise a few months later, I might have forgotten about R-Trees altogether as an option. In neither case would I have blown away my interviewers, meaning my ”unprecedented” performance was a happy coincidence rather than a reflection of me being some kind of uber-programmer.
Programmers, Don’t Sweat “Failure”
Have you ever sat for an interview or programming exercise that demanded knowledge you simply didn’t have? Famously, if you ever have occasion to interview for Google, you’ll discover that their initial phone interview is basically like an oral midterm from your undergrad CS program’s senior-year algorithms class. O notation. Sorting algorithms. All that fun stuff. They aren’t alone in that by a long shot, but their interview process is iconic.
To combat being caught off guard, you probably study up before you hit the job market, making sure you can field a wide array of technical questions. After all, you never know what they’ll throw at you. But the thing is, you never know what they’ll ask—or what knowledge you or any of the other candidates have recently acquired that will be perfectly timed for this interview.
You may be up against someone like me who just happens to have read a white paper detailing a solution to the exact problem of which the interviewers are so proud. If that’s what happens, well, you’re just out of luck.
And that’s why you shouldn’t feel bad. The interview process is actually depressingly random and non-scientific. “Failing” an interview doesn’t mean that you’ve actually “failed” at anything. It just means that you haven’t had the good fortune to read the material that would have let you pass.
Companies, Focus on the Right Things
Do you have an interview process like this one? Do you have a process where, all else being equal, you’ll wind up hiring a candidate that just happened to read up on R-Trees? If you do, I’d suggest some introspection to evaluate whether or not that might be a hiring process smell.
In my experience, interviews aim to understand one or more of the following three things: what does this candidate know, what has this candidate done, and what can this candidate do? These are ordered both in usefulness (least to most) and difficulty to evaluate (least to most).
What a candidate knows is probably the least useful, since human beings spend their lives learning and what they know can change easily. But it’s easy to evaluate. Include trivia quizzes and the like as part of your interview process, and you can figure out what they know.
What a candidate has done is a little trickier, but it’s more useful. I mean, sure, they have resumes and anecdotes, but dissembling is always a possibility. You can be more sure that they know what an R-Tree is by quizzing them than you can be sure that they’ve implemented R Trees by hearing them make that assertion. But if they’ve successfully implemented it before, that’s more valuable than them knowing what one is.
But the importance of what they know or what they’ve done pales in comparison to this: “Will this person, confronted with a situation that needs an R-Tree, do the requisite research and translate that into a solution?” That’s what you really want to know. Those last two things are just proxies for trying to know it.
I certainly don’t have any unprecedented insight into the best way to conduct interviews. Evaluating candidates is hard. But I can tell you that the closer you get to creating evaluations for what candidates can do, the more likely you are to have successful hires.
![]()
![]()
