This post on the 37signals blog struck a chord with me.
Interviewing programmers by requiring them to tackle problems on a white board is a lousy way to find successful developers, yet this practice has existed for years.
I’ve experienced it myself a few times, and each time I failed. Badly.
On one occasion I was interviewed by four separate people during a single day, all of whom expected me to answer on a white board. None of them asked any questions about previous experience. One of them hadn’t even read my résumé prior to the interview.
I’ve also been asked to tackle problems way outside my area of expertise. Perhaps the silliest was when I was expected to answer a problem which required knowledge of graphic chip architecture even though I was being interviewed for a front-end programming position that had nothing to do with graphics.
Yes, despite the fact that I’ve written several very successful programs, I wasn’t asked back for a second interview because I suck at answering irrelevant technical problems on a white board.
I agree with 37signals that the best way to gauge the potential success of a programmer is to see what they’ve already done, even if it’s just side projects they worked on in college. Interviewing via a white board is like deciding how good a musician is by asking them to write tablature instead of listening to them play.
I’m going to disagree somewhat. While I don’t really want an interviewee to write large swaths of code on the whiteboard, I’d really like to see someone draw up a database schema for a blog. Or show a high-level architecture diagram for a monitoring/subscription/altering subsystem. I want developers to be able to express their ideas in writing so they can be sold to higher-ups and what-not. But code is highly unnecessary.
I’m going to disagree with your disagreement. It’s lazy and it misses a lot of people who like to think about problems before diving in.
For someone right out of college, okay, I can see there aren’t a lot good ways to evaluate them. But for someone who’s been around longer, it’s dumb. It’s also rather demeaning.
It also sets the interviewer up to look for a particular solution. I once had a valid whiteboard solution rejected, and thus lost the job offer. When I found out that was the reason, I coded it up and it worked perfectly.
Also had an interviewer ask me to define http status codes for them. “Um, I can google that for you if you want”
Nick – I’m curious how you handle the situation where someone doesn’t have publicly available work for you to investigate.
I suspect this might be more common in large corporate hiring situations than in smaller companies. Lots of internal projects, or things you can’t really talk about.
I don’t think the whiteboard is necessarily the problem. While I will also look at the developer’s past experience, the white board is one more tool in the belt, for evaluating someone. The problem you experienced was that the prospective employer thought it was the only tool. I use the white board to see how someone thinks on their feet. I’m not always looking for a correct answer, but it is handy to get someone to start thinking about a problem and how to solve it. Even if they are way off of what I thought the solution might be, I can sometimes see sparks of genius in how they approach the problem. And if I throw someone a problem on the whiteboard and they freeze, I tend to give them some suggestions of where to start just in case the nerves get to them or they may not be used to white boarding a problem.
If you think it’s demeaning, then maybe they didn’t properly explain to you what they were evaluating, or maybe you have a developer ego to get over. I don’t care if you are fresh out of school or 30 years experience, I know a lot of “experienced” developers I wouldn’t hire, so years in the field, don’t preclude you from the hiring process.
Where I work we use white boards regularly to brainstorm and work through dev problems. Again it’s just one of many tools.
If an employer judges you solely by how you perform on a whiteboard problem, then you probably didn’t want to work for them anyways.
I totally agree with you Nick, these kind of tests penalise certain personality types without being a reliable indication of skill. Basically you are just testing whether someone can think out loud, not whether what they come up with is any good.
In answer to Mike’s point above, 30 years in the field should get you a different hiring process. The idiotic little gotcha questions (hint: try XOR) are more suitable for the recent college grad. I find them absurd in other situations.
Okay, if you can truly not think of any other way to evaluate someone’s skills, then fine. In my experience, engineers will jump first to the stupid tests rather than actually looking up someone’s public projects or reading their resume.
Now for me, the situation is different. I’m a consultant with a pretty deep well of experience. When I encounter this sort of thing it’s because someone isn’t paying attention. I’ll halt the process, remind them of why they’re talking to me, and then gently nudge them into explaining what it is they wanted me to do in the first place. Not everyone has this luxury.
The real reason I hate these sorts of tests is that I’ve had former employees get tripped up by them. I’ve seen other, less competent former employees sail through. Usually because they’re the sort of novelty loving idiots who test really well.
So, not impressed. Love to see this trend die a well deserved death.
I don’t mind that sort of problem, as long as you’re not expecting compilable code, and you’re more interested in seeing how they approach the problem than the solution they come up with.
In one of my interviews, I was asked a question where the “right” answer involved recursion. I came up with an iterative solution that used less space. Luckily the interviewer was smart enough to understand my answer. (I got the one he was looking for on my second try.)
I try to ask open ended questions that have more than one “right” answer, and see how many they get. Occasionally, I get one that I haven’t thought of. That’s a good thing.
I had one web developer interview where the interviewer wanted me to solve story problems [having nothing whatsoever to do with programming] so he could see how well I employ raw logic. While I admit to being an adject failure all my life in solving story problems, I had come to the interview completely prepared to defend my developer credentials and never got the chance.
On other occassions I have been asked to create ERD models and the required CRUD stored procedures on a white board. Upon completion of these exercises I always left suspecting that the employer was “idea shopping” for free.
I am against it because I have been in interview situations where I felt like they were just trying to get other points of view on an issue they had and no real intention of hiring. My suspicion became reality when I was told they “decided not to fill the position.” I bring a portfolio for design and code samples that I can easily walk the interviewer through to prove I know the code.
Oh, and I drop Nick Bradbury’s name. ;)