If you’re a professional programmer, or hoping to become one, odds are that you have participated in at least one “technical interview”. Just in case we’re not all clear on what I mean, a technical interview is one in which a candidate is asked to solve “challenges” or answer questions by working out solutions on a whiteboard or other similar medium.
As a rule, programmers hate this type of interview question, despite the fact that they are a primary feature in most of the interviews a programmer will ever participate in. There are a lot of reasons for this dislike, and many of them are valid. A few of the big ones are:
- The ability, (or inability) to scribble solutions to a technical problem on a whiteboard with one or more critics looking on silently has absolutely no correlation with actual programming skill.
- Most of the problems presented in a coding interview are trivial and/or contrived, and are not likely to come up during the course of actual work, that is — they have nothing to do with actual programming skill.
- There are alternatives to the traditional whiteboard interview, (such as discussing code that the candidate, (or even another person), has already written — which would be a better indicator of programming skill.
Now, I don’t like technical interviews either. They’re nerve-wracking, in some cases needlessly humiliating, and in the end, as the points above illustrate, they don’t establish much about programming skill — and after all, if you’re hiring a programmer isn’t that what you should care most about?
Well — no. Technical interviews and whiteboard challenges actually have little to nothing to do with programming skill, and I think it would be a mistake for a candidate to go in to a “technical” interview believing that programming skill was the only, (or even the primary), thing they were being judged for.
The fact is that there are better ways to judge skill, and any good interviewer is going to know that. I personally ask for Github accounts for all of my candidates, and barring that, at least that they be willing to share some of their code from other sources with me. During the interview, I get a much better gauge of technical ability based on how conversant the candidate is in common tools and technologies, and their ability to speak intelligently about past work and how they leveraged those tools, than I do from their ability to work out a puzzle on a whiteboard or to remember how Merge Sort works.
So, to be clear, the white boarding that you’re asked to do during a technical interview is not about judging your skill, and the sooner you accept that idea, the sooner you’ll able to breeze through that most-reviled part of the process. But then, if it’s not about judging skill, what is it about? Why do interviewers insist on doing it at all?
If all that mattered for a programmer on the job was the technical skill required to write the code, candidates would never even need to meet their prospective employers before a job offer was made. In reality, your possible future employer wants to know a few other things about you, all of which can be remarkably well-demonstrated by a candidate during the “whiteboard challenge” portion of an in-person interview:
How well do you handle pressure?
It may be true that having a stone-faced, silent reviewer watching you scribble, erase, and re-scribble possible solutions to a trivial problem says nothing about your programming skill. Unfortunately, real code gets written in the real world, and is subject to real world pressure. If you think you’re nervous now, how are you going to feel when it’s 10 o’clock at night, a critical system is down, and everyone from the CEO of the company downward is flooding your inbox with demands to “fix the problem right now”?
Being handed a challenge you’ve never dealt with and having your hands deliberately tied, (by removing conveniences such as a computer or Google), tests your nerve, not your skill. Any good interviewer is going to make allowances for nervousness, but if you completely melt-down in the face of a challenge, you’re probably not going to be a good fit.
How well do you take instruction?
I love my people, but we programmers can sometimes possess a handful of personality quirks that make it difficult for us to handle being told what to do. We tend to make assumptions based upon prior experience without confirming those assumptions, and then when we’re told we’re wrong or did something incorrectly, we’ll argue that our way was better, rather than accepting that we just needed to do what was asked. We tend to get offended when we’re asked to do something we feel is beneath us, (like solving stupid problems on a whiteboard). It’s certainly okay to have a strong opinion and to be willing to express that opinion, but in the end, companies are going to hire the people that will ultimately do what’s asked of them and that have the attention span and concentration necessary to thoroughly understand what they are told.
Are you willing and able to communicate and ask questions?
Related to the idea of taking instruction in the first place is the idea of being able to effectively clarify those instructions. Many whiteboard ”challenges” are left intentionally vague, just to see if the candidate is comfortable communicating with others about the problem. This is an extremely important quality to have, because in real programming situations, requirements are far more complex, and in many cases just as vague, as the kinds of things you’ll see in the interview. If you’re the kind of person that just clams up, fills in blanks with your assumptions and runs off to produce some final result without doing some initial probing, there’s a very good chance that you’ve just wasted a lot of your, (and others), time because you missed something that could have been caught with a bit of back-and-forth.
Are you a fit for the culture?
This question is HUGE…So big that I’m more likely to hire a good culture fit with less hard skill than the genius who just doesn’t quite fit in. This may seem unfair, especially to we analytically-minded programmer types who scoff at the idea that we actually need to get along with our co-workers, but it’s a simple reality of working in a real place with real people. I will grant that this is often less of a concern for candidates interviewing for remote positions, but even in those cases, the concern pops up. Oftentimes, this question expresses itself in the interviewer’s mind as, “Do I like this person?” It may seem unfair, but in many cases, being liked is better than being good.
How To Win
The first step in starting any whiteboard problem is to relax. Remember that you’re not expected to walk up there and slap the solution on the board all in one go. You’re not expected to know the answer already, and you’re not even necessarily expected to come to the right answer at all. Let go of the presumption that not solving the problem is going to lose you the job, because it doesn’t work like that.
Keep talking. Long silences are awkward and tend to ramp the pressure up. Don’t ramble, but stay conversational about your thought process and how you’re considering the problem. Not only will maintaining this dialog help you keep the problem straight in your head, but interviewers will always tell you that they are interested in your “thought process”, so talk out loud! Another thing interviewers often want to hear during these challenges is questions, so phrasing some of your assumptions or thoughts as questions will both leave a positive impression on your interviewer and get you some answers you need.
Beyond that — there’s something to be said for “fake it till you make it”. Even if you’re feeling queasy and sweaty and nervous, try to deliberately project a calm demeanor. You’ll discover that many times “faking it” can lead to the real thing.
Taking Instruction & Asking Questions
Taking instruction and asking questions are all really extensions of the same idea, so I’ll cover them together. The best way to demonstrate an ability to take instruction is to do what your told, and to challenge all of your own assumptions. If you find yourself assuming something about the problem you’ve been given, ask a question to confirm or refute your assumption, and based upon the new information, act accordingly.
Even if you throughly understand what’s being asked of you, don’t embellish your solution with bells and whistles that weren’t asked for. Don’t offer a solution to an alternative problem, i.e., “If the problem were like this, then I would solve it like this”, followed by frantically white boarding something you weren’t actually asked to do. That, by the way, is different from making a comment like, “If only I didn’t have to increment the x variable, I could just call the Y method..” A comment like that demonstrates that you understand one of the difficulties of the problem, and is a Good Thing™. The problem arises only when you decide to ignore what you’ve been asked to do in favor of something you’d rather do for whatever reason.
So, this one is tough, because at first glance, it seems like it’s the most subjective. The idea of missing out on a really great career opportunity, simply because the company offering it just doesn’t feel like you’d fit in there seems really arbitrary and unfair. Unfortunately, it’s probably the single-most important factor in most hiring decisions. You don’t meet the rest of the engineering team so that they can check your technical chops — you meet them to see if they think you fit in with them.
There are two ways to help you ace the “culture fit” portion of the interview. First — do your research! Especially in the tech-world, most companies make a point of highlighting their “culture”. If the ad or the company website screams “Brogrammer”, and that’s just not your jam, pass on the opportunity, no matter how good it looks. If it’s a situation where you think you’d gel perfectly, then great, you should have no problem, just be yourself.
It gets a little tricky when it’s more of a 50/50 proposition. There are a lot of times when you may not object to the culture present at a company, but they just might not be feeling you. In some cases this is insurmountable, and I’m sorry about that. In others though, there are ways that you can tilt things in your favor.
First of all, it comes back to the first bit about handling pressure. Don’t get so caught up in the problems or the questions in the interview that you forget to interact with your interviewers like a human-being. You are not a question-answering machine, and it would be awful to get passed over because of “culture fit” just because your interviewers didn’t have a sense of who you were at all.
Second, when the interviewer brings up culture-related items, (“A lot of us blow of steam on Friday by going to this great sushi bar down the street”), even if it’s not something you’re super-excited about, be willing to express some enthusiasm, (if only for the idea that the team gets together outside of work sometimes), and definitely don’t offer a negative opinion, i.e., don’t respond to, “A lot of the guys kill time on their lunch break by playing Call of Duty on the Playstation in the lounge”, with “I wouldn’t waste my time playing video games, I’d rather read a book on programming…” Even though you might think a comment like that would score some points, (“She’s really committed to her field!”), the truth is that you’ve basically laid a back-handed insult on some of your potential future co-workers, one of which might be the person you’re interviewing with.
Lastly, if the culture-clash is obvious, (they’re a bunch of tie-wearing, pointy-haired-boss’s in the making, and you’re a tattoo-sporting, extreme sports fan that plays heavy-metal guitar), but you’re still willing to make the transition or try to fit the culture, address the elephant in the room. Make it clear that it’s just as obvious to you as it is to them that you’re probably not their usual cup of tea, and ask them if they have any particular concerns. If they’re being honest with you, (and why wouldn’t they since they’re taking the time to actually interview you), they’ll open up, and you’ll have a chance to at least plead your case. It might not help, but it’s better than leaving obvious issues unaddressed and having no rebuttal to their assumptions.
Technical interviews are hard — and no part is harder than having to deal with the nerves and pressure of being asked to demonstrate something on a whiteboard. Still, I hope some of the advice and insight here will help you in your next one, to at least approach it with a little more calm, and a little more understanding of what’s going on on the other side of the table. Good luck, and as always, comments, thoughts, or disagreements are welcome below!