But in general, I always assume that the people interviewing me are very good at programming, and very, very, very bad at interviewing.

The ubitquity of whiteboard coding is good evidence of that.

So I always try to move the interview along, by a) talking a lot about my strengths, b) just admitting “I don’t know” or “I haven’t done much of that” about my weaknesses and getting back to my strengths, c) throwing something on the table, like some diagrams or sample code, to distract them.

If it’s an argumentative crew, I challenge them on some subjective technical point & run the clock down. I know if I’ve won if they say, “Darn, we’re out of time, and I had a whiteboard problem I wanted you to do.”

Perhaps such companies deserve the staff they hire. But I see the problem as so many companies using them that they’re impossible to avoid. And the companies shouldn’t use them in the first place.

One critical thing I look for as an interviewee is “Can I TALK to these people?”

If I put code on the whiteboard and they point out all the semi-colons I missed, or start laughing and tearing it down, I usually just coast through the rest of the interview, thankful that I am about to dodge yet another bullet.

As I argued in this post, I agree with a coding test if you’re interviewing a green, no-prior-work-experience individual for a device driver position. But it’s a waste of time if she has 10 years’ development experience writing device drivers for 3Com and Qualcomm. Asking her a couple of probing questions, and doing good reference checks, will tell you 1e+06 more than making her write bit-twiddling code in an artificial environment.

wouldn’t it just be easier for him/her to show you a project they’ve worked on?

I’ve heard that some companies do not allow interviewers to request code from interviees(for legal reasons), but for exacmple’s sake, lets say you can.

some might argue that they worked in a team an didn’t do all the coding….but then again you want them to work well in a team so it’s not that bad.

i just think that there should be a better way to figure out if the person is the right one for the job without having to code on a white board.

Well, that is what I am looking for when I ask coding questions in an interview.

> Nor should they, because a candidate with the “right” answer will be perceived as better than one without, all other things being equal.

If a candidate gets the right answer I would assume that s/he has encountered that question before, so I would ask another.

I do agree that asking a question on reversing a string is useless, but asking someone to write something that shows you know how to manipulate bits for a device driver writer position is reasonable. Also asking an interviewee to evaluate a recursive Fibonacci function is valid.

If they already have work experience, I’m with you: Do a proper background check and ask good interview questions. If you can’t figure them out in 45 minutes to an hour of probing questions plus good reference checking, don’t hire them.

This is perhaps a topic for another post, but I like to ask a mixture of practical and open-ended questions. I’m not a fan of the Microsoft-popularized “intelligence” questions, like, “If your car was full of gas and weighed 3000 lbs., and you drove onto a bridge with a weight limit of 3000 lbs. in its center, would it collapse?”

any other things i could ask would be highly appreciated