Hacker News Reader

Comment by 13of40 | Hacker News Reader

> You don’t get to use to your own IDE, you have an absurdly limited amount of time and you’re in an incredibly high-pressure environment.

Here's a good interview tip that's helped me out with my last two job moves: Whiteboard code almost always comes out looking like crap because once you've fleshed out the idea, you can't easily insert lines. The solution is to bring a laptop with the IDE of your choice ready and say "Hey, I'm not really good at whiteboard coding. Do you mind if I write the code on my laptop here?"

View on HN

If your interviewer really dings you for the appearance of your scrawled code on the wall, they're being self-defeatingly stupid and you'd probably be happier working with other people.

I do lots of tech interviews, and I always make it clear that I don't care how pretty the ink looks. I stick with the whiteboard because it's the best way for candidates to explain their analyses and algorithms before they write the code.

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.

Reply on news.ycombinator.com