It's not integer overflow that makes the problem difficult. It's off-by-one errors in the predicates (< vs. <=) and indexing operations (n/2 vs (n+1)/2).
Not arguing with you as that gets many good people during interviews. But I'm going to provide some anecdotal evidence to the contrary ...
In binary search this problem comes from the length of an array, which is either odd or even, and then you're doing a division by 2, which should trigger alarms in your head all over. And just as when you were taught in your first CS class (either high-school or college) you pick 2 simple examples for both cases, and test with pen and paper (tools provided during any interview).
When I did interviews from the employer's side -- the people not doing this were either totally unprepared, failing most other questions, or brilliant (and lazy) people that considered the problem too easy to bother checking the implementation.
Surely, put into context it can provide a valuable filter, but it's not saying much about the top X% of the talent pool, which my post was about.
Not arguing with you as that gets many good people during interviews. But I'm going to provide some anecdotal evidence to the contrary ...
In binary search this problem comes from the length of an array, which is either odd or even, and then you're doing a division by 2, which should trigger alarms in your head all over. And just as when you were taught in your first CS class (either high-school or college) you pick 2 simple examples for both cases, and test with pen and paper (tools provided during any interview).
When I did interviews from the employer's side -- the people not doing this were either totally unprepared, failing most other questions, or brilliant (and lazy) people that considered the problem too easy to bother checking the implementation.
Surely, put into context it can provide a valuable filter, but it's not saying much about the top X% of the talent pool, which my post was about.