[ummonk]

>Nine times out of ten a candidate scores low because they overlooked an infinite loop or code would crash on boundary conditions and candidate wasn't able to realize that even with hints.

I guess this depends on how you run the interview but one of the things that frustrates me about whiteboard interviews that focus on the coding rather than the design is that I have to step through test cases (especially edge cases) like this manually, which is tedious and not at all how you do things in real life, where you just run the test cases and see what happens instead of having to run your own code on a whiteboard.

[shaftway]

My question is about walking around a data structure. Most candidates choose to represent it with arrays.

I agree with stepping through code being lame. If a candidate has tried to do some sort of boundary condition check and mentions a test that'd catch it, then I'll give them a pass. If a candidate just blows past the code without any attempt whatsoever to check that they're in bounds on an array, then I'll ding them for that. You have no idea how often I see code like...

    Node neighbor = data[x+1][y];

... without any check at all to see if x+1 is in bounds for data.

The infinite loop in my question is fairly obvious (because it involves walking around a data structure iteratively). Candidates either see it right away and handle it as they solve, notice it halfway through and crowbar it awkwardly in, or don't notice it until asked to walk through a specific test case, or don't even notice it while walking through the test case.

Ultimately, if the code looks correct to me, or even close (I mess up occasionally) then I'll just ask what cases they would test.

[blumomo]

There are however cases where

    Node neighbor = data[x+1][y];

does not require an index boundary check when you know that 'x + 1 < length(data)' for any 'x'. This could be due to the iteration of 'data' excluding the last element or any other condition that's always hold.

[seventhtiger]

I'm like you in that I used to code "against the IDE and test cases" by basically rapidly iterating and kind of refining as I go along. Always fast to compile and see what happens.

Learning to write code on paper for exams and on white boards for interviews actually improved my skills a lot. Maybe not everyone coded like I did, "against constraints", but having to slow down and take into account the constraints mentally led to making better code.