It took me around 20 minutes to write all the extra code and 9 to write the reverse function (including the testing and all).

The problem was not knowing how to solve it but more the pressure of looking at the clock and seeing the time flying away. Because of that, some minor mistakes were done and naturally you start to get nervous and waste more time. In a phone interview I would probably even do more minor mistakes and fail it.

   struct LinkedList {
      LinkedList* next;
      int data;
   }

   void reverseLL(linkedList* ll){
      if (ll==NULL) return NULL;
      LinkedList* newList;
      prev = NULL;
      for (;;) {
         newList = malloc(LinkedList);
         newList->data = ll->data;
         newList->next = prev;
         if (ll->next==NULL) break;
         prev = newList;
         ll = ll->next;
      }
      return newList;
   }

I'm sure you could do it if you took a piece of paper and drew a linked list with boxes.

step two: tell a C compiler how to do it

(although the solution I would write first in LISP isn't actually what I would do in C; in C, I'd start with stack/cons-like linked list and do a slinky-queue shift)

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 ..