> Most standard library implementers couldn't write a correct binay search.

I think that issue with binary sort is not really relevant to interviews. Having a bug with integer overflow is not what an algorithmic question is trying to test.

If you want to test knowledge of undefined behavior show them code with a bug in it and ask them to find it.

Well, if the intent of the interview is just to test algorithms, maybe you don't want to test null pointer checks and off-by-1 errors too?

So much time is wasted in trying to accommodate off-by-one errors (which are a sin in production...just like integer overflows)

> So much time is wasted in trying to accommodate off-by-one errors (which are a sin in production...just like integer overflows)

Off by one is (generally) a much bigger issue. Take for example a buggy binary search which runs infinitely on even length arrays because it gets stuck with the length 2 case. This is a much more likely (in terms of runtime) bug to hit than integer overflow.

Though I generally agree that it isn't too big a deal. I would just mention that there was a bug and only if they couldn't find it would it possibly be an issue. I wouldn't penalize anyone for missing null-pointer checks unless given a valid input (non-null pointers) their algorithm failed because it hit a null pointer.

I think your measure of what is ok and what isn't is just on the basis of what you are comfortable with. Doesn't mean every other programmer is comfortable with the same.

To tell you the truth, I am ok with coding questions. In fact, I demand it. What I'm not ok with is demanding inch-perfect code in 20 mins. The only people who can be perfect are the ones who are doing the exact same problems everyday....not the ones who are doing production work.