Doing something theoretically difficult in code during an interview is one thing - but having a compiler in front of you to help you get through that difficulty

Doing something theoretically difficult in code during an interview is one thing - but having a compiler in front of you to help you get through that difficulty is another thing entirely. The point is to determine whether you are a programmer because you think like one, or if you are a programmer because your compiler thinks like one, for you. Surely, if you rely on your edit-compile-test-hack-edit.. loop to get you through the problem, thats okay: most programmers work like this. But the really good programmers, ones that are valuable to all sorts of conditions of development, can work out a problem pretty rapidly without needing the workflow-loop to get to the conclusion. These sorts of tests, outside the 'normal environment' in which programmers usually operate, don't really point out the programming-efficiency of the person, but do point out how much they depend on tools to be the programmer they are .. Myself, I also thought of 3 different ways to reverse the list before I sat down to write any code. And even now, with my compiler in front of me, I'm not entirely sure there isn't some brilliant one-liner to solve the problem. I am, however, sure that once I've compiled a solution, and run it, and seen that it does indeed work, I can walk away from the problem satisfied that I at least got something working, even if it wasn't the best solution. The degree of effectiveness of my approach and my process is what is being measured, here, I would imagine, by the interviewer ..