Tuesday, January 31, 2012

"Can you solve this problem for me on the whiteboard?"

Jim is a great chef. He's too modest to say that about himself, but he's worked either as head chef or assistant head chef at a number of restaurants. Everywhere he's worked he's been dependent and reliable, prepared great food, worked well with the other chefs, and is generally a fun guy to have in the kitchen. Unfortunately, due to the poor economy and some bad decisions by management, Jim's restaurant is about to close, so Jim is out of work and looking for a new job.

There's a new restaurant opening, a fancy place with many well-to-do investors. In Jim's world, chefs are hard to find, so Jim assumes he's a shoo-in for the job. Jim arrives at the interview at a Mexican restaurant, which feels like a great fit for Jim because Mexican food is his specialty. Jim calls up the restaurant on the phone and chats with the manager about a chef position, and the manager likes what he hears enough to schedule a job interview for Jim.

Jim arrives at the interview and talks to the manager a bit. Things seem to be going well, Jim is in his element at a Mexican restaurant. The initial meeting goes well: Jim talks his job history, how much he cares about having a fresh house salsa, and how good his Baja sauce is. "Look up the Yelp reviews of my Baja sauce!" remarks Jim. "It's the #1 reason people came to the last restaurant I worked at." The manager smiles and nods, and informs Jim he looks great on paper, however the remainder of the interview will be conducted by all of the other chefs in the kitchen. "Awesome!" Jim thinks, "I have a rapport with other chefs. This should go smoothly."

The first chef walks in, sits down at the table, and coldly stares at Jim's resume. "Can you write down a recipe for me?" he asks Jim, "There's a whiteboard over there, can you write down your preferred recipe for crème brûlée?"

Jim is a bit dumbfounded, both by the request and being asked to demonstrate his cooking ability on a whiteboard. "I'm sorry," he says, "I don't know how to make crème brûlée. I thought this was a Mexican restaurant. Would you like to know my favorite recipe for Flan?"

"No, that won't do," the assistant chef says. "Please write down how you would prepare crème brûlée"

Jim is a bit taken aback, first because he's a specialist in Mexican food, and second because instead of being asked to cook, he's being asked to write stuff on a whiteboard. "I honestly don't know how to make crème brûlée," Jim says. "Perhaps you could let me google the recipe and I could actually try to prepare it for you, instead of just demonstrating a rote ability to memorize recipes and write them down on a whiteboard."

"No, that won't do," says the interviewer, who jots down "lack of confectionary skills" in his notes. "Can you at least attempt to write down how you would prepare crème brûlée?"

Jim feels embarrassed and lost. He's being asked to do something he would never have to do in a professional capacity, and worse, rather than actually doing it, he's being asked to describe how he would do it on a whiteboard. Perhaps this is a test of Jim's ability to think on his feet, but given the position he's being asked to interview for and the question he's been presented, it's certainly an unfair one. Jim picks up the black marker and thinks hard about what the possible ingredients of crème brûlée would be.

"Well," says Jim, "I'll need cream." Jim pulls the cap off the marker and attempts to write "1. Cream", however the marker is dry and the whiteboard is on wheels that roll back when Jim attempts to write. Jim only succeeds in making a long, barely perceptible mark on the whiteboard. Having made a messy mark on the whitebard, Jim looks for an eraser but there isn't one.

"Yes," says the interviewer sarcastically, rolling his eyes, "obviously you need cream for crème brûlée. Try a different marker." Jim picks up the red marker and tries to write with that to the same result, it's dried out and won't work. Frustrated, Jim puts it down and tries the green marker, which works fine, however the board swivels vertically as he tries to write. Jim grabs the board in the upper right corner and finally manages to jot down "1. Cream"

"Okay, we have the most obvious ingredient down," says the assistant chef. "Can you think of any other ingredients that would go into crème brûlée?"

"Sugar," says Jim. The assistant chef nods, and Jim writes down sugar. "What else?"

"Milk," says Jim, and he begins to write it down before he comes to the realization that the cream and milk are redundant. Jim doesn't often cook with cream. The interviewer shakes his head in exasperation and pinches the bridge of his nose as Jim looks dumbfounded. "It's not milk brûlée," he says. Unfortunately, there's no eraser, so Jim tries to erase "3. Milk" with his hand, smearing green ink all over the board and his hand before asking "do you have an eraser?" The interviewer looks around unenthusiastically before shrugging no. Jim continues smearing the marker's ink across the surface of the board with his fingertips in a desperate attempt to compensate for the absence of an eraser.

"Can you think of any other ingredients that might go in crème brûlée?" asks the interviewer, clearly bored.

"Eggs?" asks Jim. The interviewer nods. Jim writes down "eggs". "What else?" the interviewer asks. Jim stares at what he's written down: cream, sugar, eggs. "Well," says Jim, "I assume some kind of flavoring. Chocolate perhaps?"

"Wrong," says the interviewer. "Please write vanilla." Jim looks confused for a second and jots down vanilla as asked. The interviewer jots down "trouble with basic recipes" before asking "What other ingredients can you think of?"

Jim stares at the ingredients so far: cream, sugar, eggs, vanilla. "Perhaps some water?" Jim guesses. The interviewer nods, and Jim writes down water. "Now, what are you missing?" asks the interviewer.

Jim stares at the list: cream, sugar, eggs, vanilla, water. Those seem like they should be the basic ingredients, and the interviewer rejected additional flavoring that wasn't vanilla. Jim is stupefied... he can't think of anything else. Taking a stab in the dark, Jim suggests "Salt?"

The assistant chef does a facepalm and sighs, before looking up at Jim and stating the obvious solution: "the units. Your recipe is lacking units." The ambiguity of the interviewer's question has caught Jim off guard, especially when he professed no idea of what the recipe was to being with, and worse, he has absolutely no idea what the units should be. He stares at the whiteboard for awhile before asking "how much crème brûlée are we making?"

"That's up to you," says the interviewer, "how many servings would you like to prepare?"

Jim has absolutely no clue. He's not a confectioner, but he doesn't want to completely bomb the interview, so he ventures a guess. "I'd like to prepare 2 servings. Let's try a cup of cream, a teaspoon of vanilla, two tablespoons of sugar, 4 eggs, and a cup of water."

"Those aren't the right proportions," say the interviewer. "You should use a quart of cream, two quarts water, a teaspoon of vanilla extract, a cup of sugar, and six eggs to produce six servings. Let's move on to the recipe. Can you write it down on the whiteboard for me?"

Now Jim is completely lost. The ingredients of a recipe he has no clue about are something he can guess at, but how is he supposed to guess the recipe itself? He takes his best shot.

"Break the eggs into a bowl and whisk them with the cream and sugar," guesses Jim.

"Wrong," says the interviewer.

"Whisk them with the cream and vanilla?" asks Jim.

"Still wrong," says the interviewer, "but you were closer the first time."

"Do you want me to keep guessing?" asks Jim. The interviewer sighs, writes down "completely incompetent", stands up, and says "Thank you for your time. I'll go get the next person."

Jim stands by the whiteboard and feels confused and out of place. He wonders what crème brûlée has to do with preparing Mexican food. He sits down at the table and googles for crème brûlée on his phone, quickly scanning over the recipe and thinking "that doesn't look too hard at all, I could probably make a great crème brûlée if I had a little practice." The recipe for crème brûlée is in fact quite similar to Flan, and Jim can make great Flan, but unfortunately, the interviewer won't even know as he hasn't asked Jim to cook anything. The next interviewer comes into the room.

He sits down at the table and scans over Jim's résumé, making a few grunts after scrutinizing various items. "You didn't go to culinary school?"

"No," says Jim, "but I've loved cooking since I was a little kid. I used to cook dinner with my mom every night. I've been working professionally as a chef all my life, and I can prepare great food. Why don't you just take me to the kitchen and let me show you?"

"That won't be necessary," says the interviewer. "Now, can you please write on the whiteboard how you would prepare a cheese danish?" Unfortunately, Jim is not a pastry chef either.

.   .   .

The manager has returned to conclude the interview. "Well Jim," he says, "we've discussed the issue, and we don't think you'd be a good fit here."

At this point Jim is entirely expecting this response. Jim is most comfortable in a kitchen, preparing food hands on. He feels out of place trying to explain the theoretical act of preparing food with a whiteboard. Jim loves food so much that whenever he went out for a smoke break with his fellow chefs, he continued to talk about food even when they were on break. Unfortunately, during the interview he didn't get the opportunity to discuss food in this sort of context. Instead he was asked only pointed questions about food items he didn't know how to prepare.

"I see," says Jim. "Can I ask you one question before I go?"

"Okay," says the manager.

"Throughout this interview," Jim asked, "I was asked about preparing confections and pastries, but not once was I asked about preparing Mexican food. I thought this was a Mexican restaurant. Do you serve confections and pastries here?"

"No, we don't prepare confections or pastries," said the manager, "however we're all classically-trained pastry chefs. Some of the people you talked to are actually pretty new to Mexican food. But they've all gone through culinary school and have impeccable cooking skills because of it."

"Have you considered asking your candidates to actually cook instead of explain how they would theoretically prepare something on a whiteboard?"

"It's a lot easier for us to just use the whiteboard," he says, "and we want candidates who are as knowledgable about the theory of cooking as the act of cooking."

Jim is extremely frustrated. It's not that he isn't knowledgable about the theory of cooking, but he hasn't memorized the recipe to every foodstuff on earth. Confectionaries and pastries are two areas that Jim knows very little about.

.   .   .


Jim arrives for another interview at another popular Mexican restaurant. On his way in he notes the health inspector's grade on the certificate displayed on the window: a 100%! Jim doesn't think he's actually seen a 100% score before. Jim walks in and the manager is actually there to greet him for his interview. Jim's actually pretty close with the manager, having seen him around at various farmers markets, concerts, and other events, and Jim wonders why he went to see those crazy pastry chefs before coming here.


"Hey Jim," the manager says, "I ate at your restaurant a few times. The food there was delicious!"


"Did you try the baja sauce?" asks Jim, "because I made that myself."


"Yes!" exclaims the manager, "the Baja sauce was so orgasmically delicious! Now I hope you don't mind, but we have a little test prepared. Come with me, please."


The manager leads Jim into their state of the art kitchen. It's hopping on a busy night, with people everywhere preparing the various menu items the restaurant has to offer. The order management system is fully automated using LCD displays which are mounted on the ceiling, tracking which items have been ordered, prepared, and served. The kitchen looks extremely clean and modern and the workflow seems highly efficient. The manager continues leading Jim around and shows him a prep area in the back of the kitchen which is unused. "You can work here," he says, "come with me and you can get your ingredients."


The manager continues leading Jim back to their refrigerator, where Jim notices an LCD display showing a realtime graph of the refrigerator's temperature, with bars for "too hot" and "too cold". Jim also notes in the visible history the temperature has remained within the guidelines the display is showing with very little alteration.


The manager pulls the latch to the door on the refrigerator and Jim feels a whoosh of cold air. Inside Jim finds a cornucopia of ingredients. Jim grasps some cilantro and inhales it, and the smell is deliciously fresh.  Jim darts about the refrigerator taking inventory, and discovers all the requisite ingredients are in place to concoct his own trademark Baja sauce.


"I know you can make awesome food," says the manager, "but you need to convince the owners you're a good chef. You have an hour," says the manager, "Your goal is to make delicious Mexican food."


.   .   .


58 minutes later the two co-owners of the restaurant have arrived along with the manager and have come to the back of the kitchen where Jim has been spending his time. He introduces himself and shows them the food he's prepared.


Jim has prepared some Baja fish tacos made of battered and fried red snapper, topped with Jim's own Baja sauce freshly made on-the-spot using only ingredients from the restaurant's well-stocked refrigerator. "I'm sorry it took so long," Jim says, "but really I spent 40 minutes making the sauce, and 10 minutes actually making the tacos"


The owners and the manager each grab one of Jim's tacos and bite in. They're unbelievably delicious, and it's all thanks to Jim's baja sauce. In his moment of triumph, Jim thought back to the first restaurant where he interviewed, and wondered why they were so caught up on their pastry-making ways. Clearly it takes a different kind of chef to make fish tacos than to make pastries, and perhaps Jim wasn't cut out for being a pastry chef. But when it came to making Mexican food, Jim was in his element. It seemed really weird that former pastry chefs-turned-owners of a Mexican restaurant would expect him to be a competent pastry chef, but perhaps that's what they're used to.

.   .   .

If you haven't already seen through the thinly-veiled allegory, I'm describing an interview process that based on my experience has become incredibly common in the Silicon Valley. I'm not going to name names, first and foremost because I've signed NDAs, but to those of you who have a rigorously whiteboard-driven interview process, I can't comprehend what you're doing. At the very least, if you're asking me to write on a whiteboard, make sure you have good markers and good erasers. That said...

Programmers use computers. It's what we do and where we spend our time. If you can't at least give me a text editor and the toolchain for the language(s) you're interested in me using, you're wasting both our time. While I'm not afraid of using a whiteboard to help illustrate general problems, if you're asking me to write code on a whiteboard and judging me based on that, you're taking me out of my element and I'm not giving you a representative picture of who I am or how I code.

Don't get me wrong, whiteboards can be a great interview tool. Some of the best questions I've been asked have been presented to me on a whiteboard, but a whiteboard was used to explain the concept,  the interviewer wrote down what I said and used that to help frame a solution to the problem. It was a very different situation than "write code for me on the whiteboard."

Want to do better? Give a programmer a computer. Programmers like computers. Install common editors like vim, Emacs, and TextMate and let someone choose what they're most familiar with. Better yet, give them Internet access, or even let them use their own laptop. If you're looking over their shoulder the entire time, they can't "cheat" on the interview, and maybe you'll learn something new about their workflow and how they develop software. Who knows, maybe they have a better programming workflow than you which you can only discover by watching how they work on their computer. Limiting potential programming hires to a medium like a whiteboard is a degrading experience, and one that doesn't give you an indication of a person's potential.

Last but not least, treat your potential hires like people, because they are people. Take the time to get to know your potential hires before their interview. If they've developed open source software and gained some notoriety for it, that should be a major factor in your decision, more so than what you can distill from a cursory whiteboard interview. Bottom line, if you're interviewing someone for a software engineering position, and they have a Github, and you haven't spent at least 10 minutes familiarizing yourself with what's on their Github account before you even talk to them, you're doing yourself and your company a disservice.

My worst experience (still not naming names, but you know who you are) was a company specializing in Ruby who, not to beat around the bush, was the inspiration for this whole blog post. My first in-person conversation with someone technical at the company was a nonstop wall of coding questions on a whiteboard, with no preliminary discussion of what kind of people we are or what wavelength we're on. The entire interview was conducted in an interrogation of "solve my problems or I won't give you the job." This style is completely degrading to the person being interviewed. It's computer science trivia where the prize is a job. I'm sorry, but winning a computer science trivia contest isn't a good way to gauge potential employees.

Call it sour grapes if you want, but if you're the company I interviewed with and you're reading this, and remember who I am, and remember interviewing me, I think you missed out. And I think it's your fault, which is bad because I wanted to believe in your company. I hope you're not surprised if you never heard a word back from me.

My attitude is if I'm a good Ruby programmer, and you're trying to hire me when the supply for Ruby programmers is low and demand is high, that before you even talk to me you've spent at least 10 minutes Googling for my name, looking at my code, and figuring out who I am, rather than spending an hour subjecting me to a series of ad hoc programming questions in areas I may or may not specialize in. That 10 minutes of Google will tell you a lot more than asking me to come in and scribble stuff on a whiteboard.

I think this process has left me a bit more discerning about the companies I'll actually interview with. When you're trying to hire talented developers in a scarce market, please do your due diligence and don't insult somebody skilled by asking them to do a degrading whiteboard interview instead of looking at code they have freely available on the Internet or just looking over their shoulder as they code on a computer, preferably their own, at least the first time you get to know them. You may even learn something.

24 comments:

Satya said...

Awesome stuff.. Really like your article. Its everywhere, not just the valley. i guess people are just used to conducting such chores (interviews). Probably shows some lack of commitment to find the best candidate too.

J.B. said...

This is a well-written and completely understandable (as well as completely reasonable from the writer's POV) rant. I'd like to point out, however, that the market for good Ruby programmers being tight offers the applicant the leverage to make these demands of the interviewers. However, that market being tight *also* means that hiring managers are at times flooded with resumes put together by overeager and underscrupulous recruiters, often for candidates who think that having read a book on Ruby and wearing hipster glasses means they are, in fact 'good Ruby programmers.' Sure, I'd love to have spent 10 to 20 minutes surfing your code and 'getting to know you' prior to the interview. Unfortunately for you, your recruiter has sent me 15 resumes, of which maybe 2 are in fact 'good Ruby programmers', and I don't have time to do that due diligence on all of them.

I'm being a bit mendacious, as I hire DevOps engineers rather than Ruby coders, but some of the same bits apply (esp. since we're using a ruby-based config mgmt system).

Furthermore, you're quite right that maybe I shouldn't ask you to write elegant code on a whiteboard. I am, however, going to ask you to at least plan out code based on a requirement I'm going to give you which may be something you've never posted public code for - and I'm going to ask you to spell it out for me the same way I'd ask you to communicate in our planning meetings/brainstorming sessions which (surprise) involves using a whiteboard (well, the window of the conference room, maybe, but whatever).

I take your point about the interviewer asking appropriate questions for the interview. But it sounds to me like you're telling me your skills as a coder don't extend to making your ideas and plans understood without handing someone actual finished Ruby code, written on a laptop. If that's the case, then I can't work with you.

Unknown said...

I'm a big fan of allegory, and I think you've crafted a great one here. Having interviewed more times that I care to recall, this one really nailed it. Thanks.

Evan said...

In the first paragraph, I think you want to s/dependent/dependable. I mention it because this is a great article, and I don't want people to stop reading at the typo. ^_^

aemadrid said...

I always thought that whiteboard interviews were meant to put you in a rough spot and see how you react and not as much as the code you produced. If you are trying to see how I react in a hostile environment I can see the value. If you are truly after the beauty of my code you failed. As you mentioned there are much better ways to learn about what I can do and github is a much better tool for that.

Jim said...

I once worked for a large database vendor. The VP over the part of dev I was in used to like to ask candidates to go to the whiteboard and, "Write a string copy function in C." 99% of them would jump up and write the canonical one-line strcpy clone everyone learns at some point to show how sharp they were ("I answered him with ONE LINE of code - I must be good, right?").

The answer he was REALLY looking for was, "What do you mean? Is the string null-terminated or counted? Is it ASCII or Unicode or in some other encoding? Internationalized? I can't write code with a one-line 'spec!' And why not just use the standard strcpy function instead?"

Too many programmers want to immediately jump to the blinking cursor and start "solving the problem." However, often the right approach is to ask for more clarification. Maybe there isn't a problem at all. Why not just use strcpy, indeed? What I like to do is ask questions like that in an interview and see if someone "gets it" enough to push back and ask for more info, instead of just blindly jumping to giving me a "solution."

wkdown said...

I've experienced the white board test as well. The most irritating part is when they ask very rudimentary questions, as if they didn't read (or believe) your resume. As a front-end web developer, I have been asked to whiteboard such gems as how to clear a float, how to change a string variable to an integer, and what image alt attributes are for.

If that is your criteria, stop wasting both of our time and hire an intern.

Josh said...

Really nice article. Challenging as well since I have a different perspective.

I've been to numerous interviews where nothing technical was really talked about at all, and I've been to some that were all lame trivia like you mentioned.

However, one of the best interviews I had involved "coding" on a whiteboard. It wasn't about sorting algorithms or any nonsense like that. It was a Roman Numeral converter.

I eventually learned that they really didn't care about the correctness of the problem. They just wanted to see if I could articulate what the problem was, and how I went about solving it. I appreciated the approach because, while difficult, it set the bar just high enough that flaky programmers would be reduced to mush during the interview.

Again, the problem wasn't about memorizing algorithms, or even having a compiling solution. But they did want to know that I had at least some modicum of technical knowledge coupled with the ability to solve a new problem. It was tough, but not overbearing or demeaning... nor was it meant to be.

I think it all comes down to motive. Are you trying to vet a candidate, or prove to them how smart you are? More often than not it is the later.

Ian Douglas said...

This story was really well written, especially since I've been doing dozens of interviews for my current employer, plus have a brother in law who is a chef. Well done. I don't recall the last time I actually had someone write code on a whiteboard to evaluate. But I recall several big companies who loved seeing whiteboard code.

Our HR manager does an initial phone screen to determine basic skills, why you're looking for work, etc., then schedules an in-person interview in one of our offices. Before you even make it to your first interview, we've already looked at Github, twitter, stack overflow, blogs, etc., to see what you're capable of, and try our best to conform our initial interview around who we believe you to be based on what you say/do online.

During that first round, we'll ask you to sketch out a system you've worked on, and explain as much of it in detail as you're able (or allowed, under NDA), to determine your communication skills and see what you really know. Then we throw in elements of troubleshooting and more "creative problem solving" to weed out anyone who obviously has no idea what they're talking about. At the end of the first round, we generally tell you to code a small web app on your own time for whichever logic puzzle we asked you to solve, and give you up to a week to complete it. You use whichever language you feel most comfortable in, implement it however you want, we just ask that you "wow" us with something that you're especially good at.

A second round interview means we were impressed enough by your code to have you come back. If we didn't like your code, we try to tell you why so you can improve. When you show up, we plug your laptop into a big-screen TV and ask you to go through your code to explain your design process. We give you a list of bugs or features with fictional business importance to see how you weigh business needs versus simplicity of implementation, etc., and watch you code for 30-45 minutes.

If we like what we see there, we invite you back for a third round interview, basically a "culture" interview, where we take you out to lunch with the entire team to see how well you get along with everyone, who you connect with best, etc., and then make offers based on all of what we've seen you do. Which team you end up on depends on your strengths.

So far, that approach has netted us several amazing developers, and we continue to interview for more engineering positions.

willy said...

Programming is done - at least - 95% in your head, not on the editor.

It's like saying that Stephen King cannot write a good paragraph with pen and paper because daily, he writes using a Mac.

Cooking is not done by thinking, it's done by cooking. Programming is a thinking task.

The whiteboard is a vehicle to show what's inside your head.

Tim M said...

My interview script starts with 2 big disclaimers that I ask people to read:

1. "These are my questions, so of course I know all the answers. This doesn't make me smarter than you, it just means I wrote the quiz. If it was your quiz, you'd know the answers."

2. "These are not right/wrong questions, there are no 'trick' questions, and you don't get a score at the end. The questions are designed to provoke a conversation, please bear that in mind."

And at the end, the last question on the paper reads:

"This interview sucks. This is no way to hire people... what would you do to interview people?"

In part of the interview I ask people to write some simple code with pen and paper, not a keyboard, as otherwise they think they're going to be marked on comments and variable names etc. With pen and paper it's easier for me to say it's not about syntax or names or comments, but I want to hear them explain what they're thinking as they write some simple code. There are subtle points you can pick up this way, despite some discomfort for the interviewee.

I've honed this interview over the last 10 or 15 years, and it reliably produces excellent results, but it has to be used with care.

Treat your candidates with respect, give them a chance to shine, provoke them in discussion, and you can find great people.

Restuta said...

I'm pretty have the same opinion as Uncle Bob here (he wrote about you, man) http://blog.8thlight.com/uncle-bob/2012/01/31/The-Ruby-Colored-Box.html

@Llewellyn Falco said...

--Interview goes both ways --
1) I'd like to point out that the restaurants in your story are actually doing you a favor. It is quite clear that you should be working at the 2nd one, and NOT at the 1st.

-- Feedback is part of programming --
2) @Willy said "95% in your head, not on the editor".
I would agree with this, unless you do TDD. Then I would very much DISAGREE with this. Feedback is an important part of programming, and a whiteboard doesn't offer any.

I believe a good mexican chef should be able to produce an edible creme-bluree if able to mess around in a kitchen. but not just on paper.

The key element here is, make the person "do" what they would actually "do" in the job.

there are many comments that seem to say "whine whine, they made you do work" but actually the second restaurant actually had them do more work.

I've actually been in an interview where they didn't want to take notes, so they keep making me rewrite on the board to be easier to photograph.

You heard me right, as a programmer, I was graded on my handwriting.

-- time is time --
3) @Jim said "I don't have time to do that due diligence on all of them"
This statement confuses me.
It either means
a) I'm interviewing everyone, because I don't have 10 minutes to google them (which would imply the interview process is LESS than 10 minutes, or there is a loss of time)
or
b) I am using some other method to reject resumes.
I am curious as to what that method would be? I have found VERY little honest and useful information in resumes (I have read 1,000's of them). A github search would be MUCH more productive.

Jamie Hale said...

Good interviewers use a whiteboard so weak programmers can't lean on a toolchain to help them solve a problem. They don't want to see a solution - they want to see how you think about solving a problem.

Good interviewers don't rely on a Google search or GitHub account because they want to know what you're actually capable of doing on your own right now - not what some website claims you can do or have done in the past. They want to see what you can actually write when you are faced with a problem - not what you have cobbled together at your leisure, at some point in history, potentially copying bits from other sources.

Good interviewers are not interested in whether or not you know some piece of "computer science trivia". They want you to show at least some basic understanding of the (art and) science of computer programming.

"Specialization is for insects." -- Lazarus Long

Duane said...

I've been on the receiving end of this, but I'm also responsible for hiring developers. If you have a large stack of resumes one approach is to ask applicants to do a brief (and I do mean brief) coding quiz. This happens after you have filtered resumes and before you conduct in-person sessions. In this way the developer can use tools of their choice.

When we meet in person I like to solve a real pertinent problem that we are working through. Naturally the scope has to be narrow, but these aren't hard to find. I learn a lot more about the candidate by designing a solution than I could any other way I've tried. The candidates who embrace this are usually the ones who will enjoy solving problems together when hired.

Marcel H. said...

I don't understand how some people are even trying to defend the whiteboard-interview idea. It's ludicrous. It isn't efficient, it isn't elegant, it leads to numerous problems that a simple "computer" would fix.

When I program, I have intellisense and code-completion setup to my liking. I have shortcuts that inject repetitive things like XML-formed comment tags. I use tons of shortcuts for bash commands.

What you want me to write on a whiteboard would take me ten minutes. In a horrible handwriting probably, because it's an awkward position to write in anyway.

There's no backspace, there's no undo, there is nothing even remotely basic that would save both of us a ton of time.

To all people defending the whiteboard practice: You are inefficient mammoths that refuse to innovate. There is no benefit to whiteboard-programming other than to see how the interviewee handles stressful and awkward situations.

If you want to hire great programmers, let them program. Tell them to bring their own laptop. Send them a tarball with a program in it. Tell them to compile and debug it. See how they go about it.

You'll know more in 5 minutes of watching over his shoulder (or connect it to a beamer and project it on your precious whiteboard) than 1 hour of awkwardly writing with dried out markers.

Or not, whatever. The good programmers end up at the company I work for. Our interview process is relevant and pleasant.

Patrick Laplante said...

I once had an interview for a software position. When I got there, they walked me to someone's small office. In that office there were 8 interviewers sitting in circle with an empty chair in the middle.

I didn't have to use a white board but that was not a fun interview at all!!!

James Hall said...

I liked your article. Though, I have to say, I don't think the whiteboard is to blame. The point that I think you got to is that theoretical exercises are useless. A proper exercise for a chef with a whiteboard would be to ask him give you a recipe for his favorite dish that he has prepared in a restaurant. Why was it his favorite? Was it successful? How would he make it faster? Cheaper? Better? Then ask the opposite. What was the least favorite recipe that he has prepared and ask the same questions. And then ask him to describe positive and negative experiences from kitchens he has worked at before. Because, I will argue this... having a chef prepare you a meal doesn't tell you anything about how he handles stress, how he can communicate directions to others, how he makes decisions, how he follows direction, how he treats others.

A brilliant coder who can't collaborate is as useless as bad programmer with excellent people skills. When interviewing, you want to uncover both behavior and aptitude, and you want to stick to concrete and relevant discussions and exercises. You want folks who can teach, learn, affect change, and have a genuine interest in the work that they do.

Good article. Keep writing!

mtbkrdave said...

This is on Blogger, a Google property - why can't I +1 it? Why can't I +1,000,000 it, for that matter?!

Daiphyer.com said...

Whiteboard works for certain positions. It is a great mean of doing interviews.
The issue is, some people are using wrong tool for the job.

Webjai said...

Whiteboard does help interviewers gauge accuracy and speed of a coder. It weeds out those who rely on Google for basics. Looking at your code on google doesn't tell me how long the project took you or if you are an expert, hack, or somewhere in between. That said, a short task that you could code in an ide during your interview without the aid of the web would be more relevant.

Word of advise on this article: take out all the personal stuff. It detracts from the credibility, making you sound like a jaded reject rather than an intellegent point-maker (which you are).

Jim G said...

You expect hiring managers to Google your name to find your Github account? Why isn't that already on your resume or LinkedIn profile?

cwrn said...

I love this article... I think it was part of the inspiration for job_interview, a gem @micahjgates and I created during last RailsConf.

https://github.com/ruby-jokes/job_interview

We actually did a lightening talk as well, but the video's not up yet. Anyway, thanks for the post, hope you enjoy the gem.

hoi poi said...

"Daiphyer.com said...
Whiteboard works for certain positions. It is a great mean of doing interviews.
The issue is, some people are using wrong tool for the job.
February 1, 2012 at 10:09 PM "

...

Daiphyer, try using correct English next time - maybe, practice it on a whiteboard...that will show your skill in terms of diction, expressiveness and spelling.