A Whiteboard and a Marker

You already know it— Technical Interviews suck

Walking around Caltech, I can personally guarantee you’ll meet lots of ‘smart’ people. Students who are fast learners— students who know how to (and love to) attack ‘hard’ problems.

But let’s concentrate on Computer Science, and CS Majors for a second, just because I know them best. Zooming in further— let’s think about what they’re all going through at this time of year— piles of technical interviews.

Let’s put a Caltech CS major into a room and ask them a whiteboard question. Here’s a typical one for you, taken straight from the bible of technical questions:

Design a stack such that push, pop, and min_element all operate in constant time.

Entertain this for a second, and don’t read too much further without putting some level of thought into it.

If you know what a stack is, and understand the three operations listed above, you can probably pretty come up with a rough idea of what you should do. Every time you add an element to the stack, keep track of what the minimum is thus far. Even if you take an element out of the stack, you’ll always keep track of the minimum value— everything happens in constant time. Simple enough.

There’s a few things this interview claims to test:

• How well you can think of a solution to a novel problem on the spot that involves some standard algorithm or data structure use. More abstractly: How do you think? What approaches do you try? Where do you get stuck?
• How well you can communicate your solution to an interviewer?
• The quality of syntax— how well you can translate ideas into code, usually written on a whiteboard.

I see some big problems with an interview like this:

There’s a finite set of problems, or problem patterns. Sure, the list may be long, but there’s only so much variability. Said another way: You can practice for a technical interview, and actually memorize a list of questions. More specifically, a good way to increase your odds of passing an interview is to have seen a bunch of similar problems.

Doesn’t that defeat the purpose of these questions? Are we testing memory, or are we testing critical thinking?

Collaboration in interviews is superficially encouraged (“feel free to ask your interviewer clarification questions”), but almost always penalized. I’ve never felt comfortable asking the interviewer for ideas or even for true validation of my approach. Like it or not, if you can’t figure out the basics of a problem and have to ask for help, that’s going to dock you some points. In a real job, you can discuss the problem’s tradeoffs as a team over lunch. You can ping a fellow engineer and figure out how to best implement a solution.*

Even if you have no idea how to do something, you can Google the solution. Does that sound like cheating?

I’ve never seen StackOverflow blocked on a company’s intranet.

The reality of the situation is that engineers often don’t have extremely different challenges from other companies. There are well documented, efficient ways to solve problems, and often times you use all the resources you have.

Have to figure out how to scale or architect a big system? Read a book on it for a couple hours, and you have a start.

Have to figure out how to parse or store a bunch of unordered data in the best way? Google it.

I think interviews fundamentally suck at simulating these scenarios, and those are the most common— and most valuable. Here’s my point:

You want to optimize your interview for those who can learn the quickest, not who can answer the best.

Easier said than done, right? Well, I wouldn’t be so quick to dismiss this as an unsolvable problem. US corporations spend nearly $72 billion each year on a variety of recruiting services.

Recruiting and hiring— the interview process— is not an afterthought. There’s no reason it should be flawed with so much money going into it.

Let’s go to the second thing— communication.

If I can step you through my code line by line, does that really mean I know how to communicate?

Explaining a for loop through an array or how two pointers work in a LinkedList doesn’t tell much about their day-to-day communication.

Maybe I am good at technical explanations— but this is almost never enough. In a workplace environment, I neeed to be able to navigate so much more.

Conflict resolution, collaboration, proper documentation— these are often equally as important as technical explanations, if not more.

And lastly— syntax.

This goes back to my point of simulating the right scenarios. You’re never going to be at a point where you can’t look up the syntax for something. You’re always going to have code-reviews. Above all, people learn over time, and syntax is simply a means to an end. You’re wasting your time reviewing API docs before a whiteboarding interview. They’re testing you on the wrong things.

So what?

I’ll be the first to admit that technical interviews are here to stay. Even with all the flaws— all the things they don’t sucessfully test as they claim— I don’t think anything is changing anytime soon.

Just don’t let a technical interview define how much you know or don’t know.

And, by the way, it’s not all bad—

Khan Academy is picking up project based interviews. Square does real pair programming at their on-site interview.

I wish you luck next time you come face-to-face with a huge, blank whiteboard in a 10' x 10' room.

I know I’ll need a lot more than a marker and some good wishes, but I’ll probably survive.

If you found this blog post at all relevant to you or thought it was cool— or you just hate technical interviews— pressing the “Recommend” button below would mean a lot to me! ☺