Anyone who’s interviewed for a large tech company knows the deal. You show up at the office, you’re ushered into a conference room with a whiteboard, and your interviewer walks in, looking a little weary. They probably know your name, but it’s unlikely they’ve taken so much as a glance at your resume. If they ask you anything about your past experience — or any question about yourself at all — it’s just for show. Before a minute or two is up, they ask you their Question.
Chances are they use the same question with every job candidate. It has some kind of contrived setup, a narrative about flight schedules between different cities, or hamsters bred to have a particular color. Sometimes it’s a board game involving a grid of squares, sometimes just a list of numbers you need to process in a certain way. But it’s always a puzzle, and your job is to write a solution to the puzzle on the whiteboard, in forty-five minutes or less.
Usually, if you toss out the window-dressing about flights and hamsters, you find that underneath it’s a binary tree problem. Or a graph problem, or a sliding window problem, or a sorting problem. And you remember the algorithms you’ve studied about graphs and trees and sliding windows, and which ones are O(n log n) and which ones are O(n squared). And you write out a solution as best you can, and hope it’s a reasonable one. At the end the interviewer will invite you to ask questions, but they’re not really paying attention to what you say at that point. Most of what’s in their notes will be about whether you could solve the puzzle, and how fast.
You might have a degree from the most prestigious university in the country, or years of experience at a rigorous company. You still have to do the puzzles, and hope that you remember how.
I don’t know anyone who really likes doing these. I’ve known people who stayed at tech jobs for years, reluctant to try for a better job at a different company, because the thought of doing interviews was so daunting. Since the day-to-day of an ordinary programming job rarely involves problems like these, everyone seems to agree that over the years they get more difficult instead of easier.
Still, sometimes I wonder if their artificiality, their disconnection from that day-to-day, makes them fairer than other kinds of interviews. An interview asking about past experience has everything to do with whether you can make it sound impressive; “getting to know you” and “finding a fit” chats can be cultural minefields, testing your familiarity with unwritten social mores and measuring against undisclosed expectations. Take-home projects are labor-intensive and ambiguous; “find the bugs in this code” problems, without enough context, can be deeply unfair.
The programming puzzles, however, don’t change. They’ll always be some variation on binary trees, graphs, sorted lists. Resources for preparation are abundant and free and easy to find, and the evaluation, while not entirely objective, is at least transparent. It is just such. a fucking. miserable. slog. to try to remember how and why to write a depth-first search program when you haven’t needed to write one since Algorithms 101 fifteen years ago.
What’s fairer? A transparent, available, generally unchanging and unambiguous standard, only somewhat related to the day-to-day work, that takes weeks of study and preparation to be able to meet? Or what’s more typical in other industries — an evaluation of experience and presentation and references and talking the talk, that someone seasoned and competent and likable should be able to sail through, if they know how to play the game?
As part of my job, I used to conduct puzzle-style interviews with prospective candidates, and now I sit on a committee where I look at the notes for interviews that others have conducted. And so many candidates still aren’t sure how to play the game: they waste time on trivial parts of the problem, they don’t listen to hints that the interviewer is trying to give them. Or perhaps their code solves the problem but also contains a bunch of unnecessary complications. When we denounce the unfairness of standardized testing, is this the kind of thing we’re thinking of — not just the miserable hours of prep with textbooks and a coach, but the understanding of the game?
No matter how closely we try to get at pure intelligence, there’s always a set of insider rules to learn.
When I give advice to people about to embark on a round of technical interviews, I tell them to make a music playlist of energetic, you-can-do-it tunes they can listen to the morning of. The last time I had to do interviews, my playlist included “I Have Confidence” from The Sound of Music and “Rose’s Turn” from Gypsy. So little else, besides hours of studying, can really help. A comfort and a curse.