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.

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.

I'm still floored by how many candidates I've talked to that assert with great confidence that the local variables they declare will still be there with the same values when they call the function recursively.

And most recently, when iterating over a string's characters the underlying string methods KNOW that the string is being iterated and will pick up at the current iteration point. For example, you've got the string "5432112345". And via iteration, you're currently pointing at the first "2" at index 3. The candidate asserted that if you call "indexOf('2')", it would return 6 because "indexOf" knows that it is iterating and should start 1 beyond where it is pointing at.

And my favorite - once had a candidate that misspelled a function name while coding in Ruby. I didn't ding them for it. But I pointed it out because it just bugged me. And the candidate then swore to me that Ruby will automatically call the correct method if there was only 1 candidate based on the misspelling. You know when you do things like "git inti" and it says "did you mean init?". The candidate swore that Ruby would just call "init" for you because it knew what you wanted.

I once passed a whiteboard interview just calling random made-up operations on generic java arrays, like Array.flatten().

I was relatively new to programming and had been practicing in Java but didn't know how to execute a lot of map/filter/reduce operations off the top of my head like that. I did, however, know that my interviewer was a Python programmer that probably didn't know much about Java language features.

This one candidate had been allowed to skip the phone screen, and phone screens would likely have filtered them out. Candidate used Java and claimed to be deeply familiar with it. Obviously this isn't exact, but the result looked something like this:

    public isTheFooBarred(class Node { int[][] positions, int size } node, int x, int y, Set visited = new HashSet(node.size)) {
      // ...
    }

The first parameter to the method had an inlined class definition, and the last parameter was optional. We discussed this and the candidate claimed that this was legal vanilla Java. In the case of the last parameter, the candidate claimed that the compiler generated every possible combination of methods including and excluding each of the optional parameters (so, 2^n methods).

I really tried to give the candidate the benefit of the doubt, and asked if there was some sort of annotation processor or code pre-processor that they were using, but they were adamant that it was plain old vanilla Java. I'm pretty sure that they were using some in-house built thing, but their solution had significant problems, so it wasn't the only reason I was against the hire.

I've had people interview for a Java job who didn't realise strings were immutable.

The question asked was a very short multiple choice; only two of the answers were possible under immutability.

> ... and candidate wasn't able to realize that even with hints.

He said why. Why did you misquote?