My Google interview in 2008, one guy asked me to write a binary tree structure and implementations of depth and breadth-first search (maybe also balanced insert?) on the whiteboard in C, which I blew through in no time. He then immediately said it was wrong and let me wither for a few minutes trying to figure out what the problem was before pointing out I forgot a semicolon.

I hated seeing that kind of crap when I was on the hiring committee, and I think that it's less likely that you'd run into it today.

Thanks, it does sound like things have changed. I probably would have been a better hire back then than today though. I was younger, cheaper, and had an almost OCD drive to learn everything CS since I had a complex about getting into the game a little late. Today I feel like I wouldn't be able to maintain my current lifestyle with a wife, two kids, two dogs in the bay area. Occasionally I think about it though...

I was given a brain teaser puzzle during my D.E. Shaw interview process in 2006. One of my interviewers told me that my answer was completely wrong just to see how I would take the criticism.

I guess calmly evaluating my conclusions and approaching the problem with a third algorithm (I had already devised two and compared the answers) and then calmly asserting that my answer was in fact correct was the right move.

> One of my interviewers told me that my answer was completely wrong just to see how I would take the criticism.

I do this sometimes. A strong developer would have a good mix of defending the design decisions made and the acceptance of the errors made. This test should bring this characteristic to the forefront.

I think that lying to a candidate is unethical and unfair.

You can get similar results without crossing that line by asking questions like "can this be made faster?" and "is this correct?", soliciting proofs of lower bounds on asymptotic complexity and loop invariants (respectively). But you shouldn't tell a candidate that their code is broken when it isn't. Interviewing is stressful and scary -- don't make it worse just because you can.

> soliciting proofs of lower bounds on asymptotic complexity

A mathematical proof on the lower bound? is that a common request and something I should prepare for in an interview?

If I ask you whether your sort can be made faster, and you can make a credible case that it's O(n log n), so no, I'm happy.

Wow, you are just an asshole then. There's plenty of ways of having someone defend their design decision without resorting to such unethical behavior. What are you a 4 year old? What a bunch of crap. I hope that comes back to you.

You could've played their game to make a point.

"Ah, no wonder it didn't work!"

Then draw out an IDE around the code with a big [Compile] button.

Maybe even Clippy in the corner of the whiteboard. "It looks like you're trying to get a job..."

First of all, the interviewer might not be doing it consciously. Code just looks better in an IDE, the same way a guy in a suit makes a better first impression than a guy with sneakers and ripped jeans who smells like pee.

But that said, if you were interviewing someone and they did all of their algorithmic boxes and lines on the whiteboard but switched to the laptop to write the code, would you ding them for that?

Beats me. I've never worked at a company that would allow a candidate to fire up a laptop during an interview.

I was once asked to set up the interviewers laptop.

When I used to interview contractors (more leeway in the interview process) I would put them in front of a computer with Visual Studio and a web browser, because that's how people actually work. I didn't get enough samples to tell if success at that correlates to success on the job, though.

Actually, I prefer whiteboard because I prefer drawing a lot. As far as code quality is concerned, I'd have the interviewee to work on a small challenge and submit the challenge in two days. Nothing majorly difficult, just some hackathon-kind of app challenge. If the candidate has a public code profile I'd check those out.