4 ms·

I feel like I'm pretty good at these things, but I'd 100% have an off-by-one error in my first attempt at binary search. I can get it right quickly if I'm able

I feel like I'm pretty good at these things, but I'd 100% have an off-by-one error in my first attempt at binary search. I can get it right quickly if I'm able to test the code, or very slowly if I have to work through several test cases by hand on the whiteboard. There's a lot of room in between "couldn't implement it" and "can do it in 5 seconds" and "wrote a buggy version of it".

quietbritishjim 5y ago
I agree it's very easy to make an off-by-one mistake in binary search. (Related article: [1]) But an interview candidate showing something that is almost right and then has enough self-awareness to say "but I'm sure there's an off by one error in there somewhere" has given a really good overall answer in my books. I think there's still value in asking the question because that sort of answer constrasts against candidates who flounder completely (which is more common than you'd imagine). A common counter argument is that a bad interviewer wouldn't accept an answer that has minor bugs in it like that. But I don't buy that counter argument, because a bad interviewer could misjudge candidates regardless of the interview format. [1] https://reprog.wordpress.com/2010/04/19/are-you-one-of-the-10-percent/ https://reprog.wordpress.com/2010/04/19/are-you-one-of-the-1...
sgtnoodle 5y ago
One of the best things you could do in a whiteboard interview is just start writing effective unit test cases without being prompted into it. When I joined my current company, it was still tiny and sketchy and I got shanghaied into a surprise full day interview by the promise of an informal two hour tour. A two hour tour... At one point I was given 1.5 hours to write an implementation of a very core library that most software engineers take for granted every day. Trying to have fun with it, I spent about 20 minutes writing a design document, about 30 minutes coding the implementation, and then the last 40 minutes writing a dozen or so unit test cases (as well as a simple standalone unit test framework). When I ran out of time, only maybe 2/3rds of my test cases passed, and I had just narrowed the problem down to a flaw in one of the assumptions I had enumerated in my design document. All the interviewers seemed pretty impressed by the documentation and test coverage, and didn't really care about the implementation, mostly because it was relatively boring by design.

quietbritishjim 5y ago

I agree it's very easy to make an off-by-one mistake in binary search. (Related article: [1]) But an interview candidate showing something that is almost right and then has enough self-awareness to say "but I'm sure there's an off by one error in there somewhere" has given a really good overall answer in my books. I think there's still value in asking the question because that sort of answer constrasts against candidates who flounder completely (which is more common than you'd imagine). A common counter argument is that a bad interviewer wouldn't accept an answer that has minor bugs in it like that. But I don't buy that counter argument, because a bad interviewer could misjudge candidates regardless of the interview format. [1] https://reprog.wordpress.com/2010/04/19/are-you-one-of-the-10-percent/ https://reprog.wordpress.com/2010/04/19/are-you-one-of-the-1...

sgtnoodle 5y ago

One of the best things you could do in a whiteboard interview is just start writing effective unit test cases without being prompted into it. When I joined my current company, it was still tiny and sketchy and I got shanghaied into a surprise full day interview by the promise of an informal two hour tour. A two hour tour... At one point I was given 1.5 hours to write an implementation of a very core library that most software engineers take for granted every day. Trying to have fun with it, I spent about 20 minutes writing a design document, about 30 minutes coding the implementation, and then the last 40 minutes writing a dozen or so unit test cases (as well as a simple standalone unit test framework). When I ran out of time, only maybe 2/3rds of my test cases passed, and I had just narrowed the problem down to a flaw in one of the assumptions I had enumerated in my design document. All the interviewers seemed pretty impressed by the documentation and test coverage, and didn't really care about the implementation, mostly because it was relatively boring by design.