Whiteboard Interviews...

[yottabit]

I work in the engineering department of a small company and I can vouch for the fact that when we do whiteboard interviews it is not so much about what you write up there but showing that you can think on your feet (and not choke)

 

[Markbnj]

A candidate MUST write code during the interview. NO Exceptions. Would you hire a chef without tasting, at the very least, a few simple dishes?

Of course not, but are you going to make him cook them in front of you? The equivalent of your scenario would be: you put a stove in the front of a room full of people, then you make the chef cook to order as you call out requirements: cook a soufle! Ok, now make it with salmon! Add chive!

Any good chef would tell you to go screw yourself.

 

[Train]

Of course not, but are you going to make him cook them in front of you? The equivalent of your scenario would be: you put a stove in the front of a room full of people, then you make the chef cook to order as you call out requirements: cook a soufle! Ok, now make it with salmon! Add chive!

Any good chef would tell you to go screw yourself.

Note that I said "A few simple dishes".

And what's with the stove in front a room full of people? Do you interview in front of a room full of people? Of course not. I think you are constructing an absurd scenario to distance yourself from what you don't want to do.

If a candidate can't at least psuedo code their way to recursing over a simple tree, or solving fizzbuzz, they have no business even applying.

 

[Markbnj]

Note that I said "A few simple dishes".

And what's with the stove in front a room full of people? Do you interview in front of a room full of people? Of course not. I think you are constructing an absurd scenario to distance yourself from what you don't want to do.

If a candidate can't at least psuedo code their way to recursing over a simple tree, or solving fizzbuzz, they have no business even applying.

Sure, I have interviewed in front of a "room full of people," if you'll grant that four or five people in a conference room fits that description. I think my analogy is accurate. The programmer equivalent of "tasting a few simple dishes" would require bringing code to the interview, not writing code during the interview. So tell me again why a programmer MUST write code during an interview?

 

[Train]

Sure, I have interviewed in front of a "room full of people," if you'll grant that four or five people in a conference room fits that description. I think my analogy is accurate. The programmer equivalent of "tasting a few simple dishes" would require bringing code to the interview, not writing code during the interview. So tell me again why a programmer MUST write code during an interview?

Because anyone can bring code in that is not theirs?

If spending 5 minutes writting code during an interview is as traumatic as you make it sound, perhaps I wouldn't want the hyper anxious coder either.

You know why else thorough testing is important? Because 90% of the people who take simple programming tests fail at them. Some of them have CS degrees. From the 1st page of Code Complete: "The difference between good and average in computer programming is far greater than that of any engineering discipline". The difference between good and bad is even worse. And guess which end of the spectrum job seekers tend to skew torwards?

Making a bad hire is so insanely expensive to the company it boggles my mind that people are willing to make them.

Read the two articles above by Joel Spolsky, the guy is right, and his insanely profitable and respected company back up his hiring pratices.

I have had people get up and walk out as soon as they were presented with the simplest of starter questions. (Given that Area of a circle is Pi/R^2, write a function, in any language, to return the area of a circle, you may assume Pi is a built in constant) Honestly, if you cant do that, how do you expect to be hired as a professional programmer?
If they walk out, no skin off my back.

Another great read:

http://www.codinghorror.com/blog/2004/09/skill-disparities-in-programming.html

 

[Markbnj]

Because anyone can bring code in that is not theirs?

If spending 5 minutes writting code during an interview is as traumatic as you make it sound, perhaps I wouldn't want the hyper anxious coder either.

The danger of someone bringing in code that they didn't write is way overblown. If you can't tell from questioning them whether they know how to write code then "5 minutes writing code during an interview" isn't going to remove that risk.

You know why else thorough testing is important? Because 90% of the people who take simple programming tests fail at them. Some of them have CS degrees. From the 1st page of Code Complete: "The difference between good and average in computer programming is far greater than that of any engineering discipline"

I agree that thorough testing is important. But "thorough testing" doesn't mean "writing code at a whiteboard." At our company a candidate has to submit samples and make it through 3-4 hours of question and answer with our development staff. People who get through that and get a thumbs-up from all the interviewers not only are able to write code, but they are able to think, and they have demonstrated some personality compatibility as well. So I agree with thorough testing. We just define it differently.

Making a bad hire is so insanely expensive to the company it boggles my mind that people are willing to make them.

Read the two articles above by Joel Spolsky, the guy is right, and his insanely profitable and respected company back up his hiring pratices.

I ran my own tech company and hired 40 or so developers. I did make some poor hires, but far more good ones. I have read Spolsky's opinions, and that of many others as well. Hiring decisions are massively subjective, and one company's successful practices don't necessarily generalize to another context. Furthermore, no regime of testing or screening removes the risk of a poor hire. I am not even sure it significantly reduces that risk, since a "poor hire" can come about from many different issues, regardless of the person's technical competence.

I have had people get up and walk out as soon as they were presented with the simplest of starter questions. (Given that Area of a circle is Pi/R^2, write a function, in any language, to return the area of a circle, you may assume Pi is a built in constant) Honestly, if you cant do that, how do you expect to be hired as a professional programmer?
If they walk out, no skin off my back.

And if they can answer that simple question what does it tell you about them and their ability to do the work? All you're doing is screening out complete frauds, which the first five minutes of technical conversation will do just fine.

 

[KIAman]

Although I agree that whiteboarding is a good thing, coding on a whiteboard might be a stretch.

Bringing in code examples is a great way of showing coding experince. The interviewer simply asks for them to explain and talk through the code. Ask them their thought process as they point out an interesting function.

If they didn't write the code, it will become evident from the fact they have no idea what they are talking about.

I would hope the interviewers have a developed BS filter.

 

[Markbnj]

Although I agree that whiteboarding is a good thing, coding on a whiteboard might be a stretch.

Bringing in code examples is a great way of showing coding experince. The interviewer simply asks for them to explain and talk through the code. Ask them their thought process as they point out an interesting function.

If they didn't write the code, it will become evident from the fact they have no idea what they are talking about.

I would hope the interviewers have a developed BS filter.

Yeah, and in case I haven't been clear, I am not against whiteboards . Well I am, but just because of the dust and the ghosts of old drawings. I am willing to make candidates jump through all sorts of hoops to get a job, just not writing code on command. As an example in one recent interview we had a very detailed conversation about WPF data binding, converters, and templates. We had a similarly detailed discussion of thread pools and wait handles. Do I really need to ask a candidate that can get through that conversation to write me a function to return the area of a circle? It's silly, and frankly disrespectful. I guess maybe if you're interviewing on career day at the local college, but these are professionals with resumes.

 

[veri745]

Yeah, and in case I haven't been clear, I am not against whiteboards . Well I am, but just because of the dust and the ghosts of old drawings. I am willing to make candidates jump through all sorts of hoops to get a job, just not writing code on command. As an example in one recent interview we had a very detailed conversation about WPF data binding, converters, and templates. We had a similarly detailed discussion of thread pools and wait handles. Do I really need to ask a candidate that can get through that conversation to write me a function to return the area of a circle? It's silly, and frankly disrespectful. I guess maybe if you're interviewing on career day at the local college, but these are professionals with resumes.

I've interviewed "professionals with resumes" that look F&#@ing brilliant on paper, but get them in a room and ask them to come up with a simple solution to a simple problem and they choke like a baby eating legos.

I've learned not to pay any attention to resumes if the candidate can't back them up.

 

[Oyster]

I think we're all getting a bit off track. Regardless of what all the folks who oppose whiteboarding think, the fact remains that a majority of the tech/software industry relies on this technique to filter out candidates during interviews. So the OP (or any other potential candidate) must get ready for it.

Ultimately, as I already mentioned numerous times, anyone who's trying to break into this industry would be extremely naive to ignore this trend while they're trying to land their dream job. Sure, there are companies that do not follow this trend, but they're, by and large, in the minority.

And yes, this behavior doesn't change based on how impressive your resume is or how many years of experience you bring to the table. Most pragmatic interviewers who use this technique for interviewing won't hold the candidate to archaic standards like ensuring the presence of of a semi-colon at the end of line number 10.

 

[Markbnj]

I've interviewed "professionals with resumes" that look F&#@ing brilliant on paper, but get them in a room and ask them to come up with a simple solution to a simple problem and they choke like a baby eating legos.

I've learned not to pay any attention to resumes if the candidate can't back them up.

Well, yeah, the point wasn't that the resume alone guaranteed you anything. But if a resume is really so worthless that every person has to stand at a whiteboard and prove they know the rudiments of coding, there is something wrong with your process of gathering resumes and pre-screening candidates.

 

[dinkumthinkum]

I went to an interview where the guy asked me first thing: write the code to produce the powerset of a given set.

I asked him if I could use any language I wanted, and he said yes.

So I took the opportunity to write for him my favorite one-liner in Haskell:

powerset = filterM (const [True, False])

I don't think he was happy about that. I had the luxury of blowing off that interview, thankfully, and having some fun in the process.

In general whiteboard coding is silly, because I don't write code in the same way I write by hand. I shuffle code around in the editor and bounce small snippets off the compiler to see whether they typecheck or run as expected. Maybe someday they'll invent a whiteboard that can do that, I've already heard of whiteboards that can save an image of their content. I still type a lot faster than I hand-write, so I'm not sure if that would be worthwhile anyway.

 

[Aikouka]

If I'm using a whiteboard, it's usually just for conceptualizing things at most... which would be class diagrams, small snippets of code, psuedo code, GUI layouts and/or regular expressions. Last thing I did on a whiteboard was actually a regex for validating a string before passing it into Java's Float.parseFloat(String) function. That was a fun one .

Although, I normally don't even use the whiteboard... I even have one at home that I barely use. I typically will "thought dump" onto a small notepad that I have. It's literally inane dribble to almost anyone but me as stuff is just written or drawn anywhere on the page.

But more onto the topic of interviews... it's odd, but I've never been asked to write code at an interview. When I was looking for a new job, I spoke to a friend about an interview he had. They gave him this interesting problem to solve involving scheduling tables at a restaurant. While telling me about this, I just kind of sat there running through it all in my head... it was actually rather fun, and I think it represents one of the aspects of a good programmer... being able to take a task and break it down into the necessary sub-tasks for the computer to execute. It's especially more interesting when the task is really more of a human's task, so you have to think "okay... what do we do when we do this?", which is almost awkward in itself... we usually don't think about something as we just kind of... do it.

I guess that's why I enjoyed classes like Automata in college.

 

[ivan2]

OP, i think the main reason you choke at the white board is because you are worrying too much about if the code that you wrote with is going to compile or not. they don't care if the code on the white board will actually work, all they care is that you are comfortable to write some code and that you are not totally horrible about it.

i am with the camp that some programming needs to be done in interview given that by the time you start to code, both you and your interviewer will have a clear understanding of the solution. nobody likes to be led on to different direction as they started to code. there are interviews that they would sit people in front of the computer and fires up eclipse with a workspace set and ask to debug a program, i like those, very hands on and practical and great BS detector.

 

[KIAman]

OP, i think the main reason you choke at the white board is because you are worrying too much about if the code that you wrote with is going to compile or not. they don't care if the code on the white board will actually work, all they care is that you are comfortable to write some code and that you are not totally horrible about it.

I don't think you can assume anything. It could very well be that the interviewers are looking for exact code, it wouldn't surprise me.

What does surprise me is that the interviewee is ALLOWED to ask for clarification and shouldn't need to make assumptions like this.

 

[degibson]

I don't think you can assume anything. It could very well be that the interviewers are looking for exact code, it wouldn't surprise me.

Chances are, if they're looking for exact code, you probably don't want to work there anyway.

 

[LokutusofBorg]

I've interviewed quite a few programmers (and other technical positions like QA and IT) over the years and I use the whiteboard to gauge their thinking skills, their ability to ask questions and clarify the problem with me in a conversation.

If a candidate has made it to the actual in-office interviews, then their technical skills should have been vetted by the phone screens and do-at-home coding exercise(s). The in-office interview is to determine if they're a dullard, an anti-social, or they just won't fit in with the team. I actually try to take the opportunity to make them squirm just a little bit and see how they handle the stress. If they get angry, impatient, or display any other trait that comes across as a danger sign then they're tossed. Healthy debate is essential for creative collaboration, and if a team is made up of people who know their shit and they're passionate about it, then a bit of conflict is inevitable. Someone who can't take stress, has too much of an ego to be able to admit they're wrong, or just plain can't communicate ideas without a computer, is not a good fit.

Used wrong, any interviewing technique can suck rocks and make an interview a miserable and frustrating experience. Someone said earlier it comes down to the interviewer more than anything, and I agree. I've learned lots over the years on how *not* to interview, and I am sure I've given more than a few interviews-from-hell. This Matlab interview sounds like an interview-from-hell, to be sure.