Comment by jeb | Hacker News Reader

Comment by jeb | Hacker News Reader

I can reverse a linked list, but here's what happened on reading this article.

After seeing the problem, I fired up textmate and started writing C pseudo-code to do it. I started off with

    first_item = l.first();
    next_item = first_item.next();

Then I started writing the loop, and somewhere in there, I got confused. And then a wave of panic came over me - shit, maybe you can't do this. I shook off the thought, deleted my code, and restarted. At some point, I realised that I was always pointing at the first element. My stomach sank and I had this dreadful feeling - okay, you kind of suck as a programmer. Then my mind went blank, and I wanted to switch over and see if the answer was there.

And that's with NO PRESSURE AT ALL. With someone watching me, I'd probably not even have been able to get the loop right.

I have never written such a loop, but it's basic stuff, I can do this anytime. But just a little bit of pressure made me royally fuck up.

Programming is thinking - you need to juggle shit in your head - if at the same time you are paying attention to what a HIRER is doing or saying, it will totally smash this ability to do shit in your head.

Your programming exercise probably selects for calm people, not for good programmers.

Staying calm while thinking through a solution is a pretty useful trait to be hiring for - not just for programmers either. What happens when the shit hits the fan and everything is core dumping left and right - do you really want someone whose head is going to explode? Or do you want someone who can stay calm and diagnose the problem and/or get to a workaround quickly.

This. Every so often something blows up at 2 am and we have to troubleshoot an unknown problem while our employer loses $3k/hour and everyone in charge wants to know WTF. Thankfully it's rare, but I don't want us to have to support your code if you aren't up to offering useful help at that moment.

Or it selects for people who do this kind of thing every day.

Funny, I also fired textmate and started solving the problem in C :-)

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.

What extra code? I've got a struct definition, a print_list function, cons, and a really dumb testing driver that builds the list [1 2 3], reversing and printing it a few times throughout its construction. The line count of all that [EDIT: I meant "everything except the testing driver"] is about equal to the line count of my reverse.

That extra code :-) First I wrote everything to manipulate a linked list and test it and then I wrote the reverse function. Since I wrote a insert at front function, the reverse function is small. I must add that I am not a fast typer.

How long is your reverse? Mine is 14 lines (see below), and I doubt I could code the rest in that length.

   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;
   }

The trick is to not fire up your text editor until the very last moment. Big design up front works for (difficult) algorithmic problems, and it's the only way that works.

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

People who run this sort of question usually allow for a bit of partial credit. It's not pass/fail. If you write something that's wrong, but you can at least point out why it's wrong, then that's not a good answer, but it's not always an immediate disqualification.

step one: solve it in LISP

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)

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

Reply on news.ycombinator.com