Hacker News new | ask | show | jobs
by lawnchair_larry 3548 days ago
It could also be that you only ever have to do this between 0 and 0.00001% of the time in the real world, and many people who could do it just fine if they are given space to think about it or refresh their memory, which usually results in freezing up during a stressful interview. They probably haven't exercised that knowledge because they have been too busy building real things.
3 comments

How would you filter those "many people who could do it just fine if they are given space to think about it or refresh their memory" down to the number you need to hire?

This is a serious question. I hate the way interviewing works at tech companies. Though I've generally done well and it helped me break into the industry as an outsider, it's a really time-consuming and wasteful process on both sides. So far, I'm leaning strongly towards Reid Hoffman's suggestion of weighting references much more strongly than interviews but it's hard to say how far one can safely go with that approach.

That seems like a lousy excuse to me. As a web developer, my entire job revolves around computing trees; and that is (as of now) the most common development environment in the world. My side projects (graphics demos/toys, a multiprocess text editor, various twilio SMS utilities, a high-performance pastebin server) end up using stacks, trees, hashmaps, and bloom hashes as logical responses to the problem descriptions.

Only somebody who doesn't write software for a living would claim that "between 0 and 0.00001% of the time in the real world" should these techniques be readily accessible in working memory.

As for "freezing up during a stressful interview": is that not some indication of what normal workplace stresses will do to your ability to complete technical work? I certainly wouldn't want to work with somebody who is knowledgeable but will wimp out the moment you ask them a tough question on the spot.

> As for "freezing up during a stressful interview": is that not some indication of what normal workplace stresses will do to your ability to complete technical work?

To add to roganartu's very good point about what filtering for that says about your company, you seem to be buying into the pervasive myth that "stress" is some universal and fungible thing. The stress of an interview is not of the same nature as the stress of, say, having a key server go down and take your company down with it. It's a fool's errand to think you can manufacture stressful situations in an interview and get a read on how the candidate would perform in a real situation.

> As for "freezing up during a stressful interview": is that not some indication of what normal workplace stresses will do to your ability to complete technical work? I certainly wouldn't want to work with somebody who is knowledgeable but will wimp out the moment you ask them a tough question on the spot.

I would argue that a workplace that is continuously stressful is not healthy, and optimising your interview process to filter for this is probably not a great idea.

Additionally, I would expect that when asked a "tough question" at work that you would have both the time and resources available to find or determine the answer, things that one likely doesn't have in an interview (and certainly not to the same extent).

Not sure what do you mean by computing trees in this context, but I personally as a web dev for 15+ years have never-ever had to e.g balance a binary tree or do any other low level operation of that kind. It's important to learn it at some point to be able to understand how it all works, but afterwords you just don't write the low level stuff yourself, ever. If given enough time I'm pretty sure I could come up with some solution for reversing a linked-list, probably even the optimal one, the same way I could probably also figure out how to fix my car when broken... but that doesn't make me a mechanic
The solution to reversing a linked list should be self-evident to anyone who makes an attempt.

    #include <stdio.h>
    
    typedef struct Node Node;
    struct Node {
      int data;
      Node * next;
    };
        
    Node * reverse_linked_list (Node * node) {
      Node * prev = NULL;
      Node * next;
      do {
        next = node->next;  
        node->next = prev;   
        prev = node;
      } while ((node = next));
      return prev;
    }
    
    int main () {
      Node * node;
      Node nodes[3];
      nodes[0].data = 0;
      nodes[0].next = &nodes[1];
      nodes[1].data = 1;
      nodes[1].next = &nodes[2];
      nodes[2].data = 2;
      nodes[2].next = NULL;
    
      node = nodes;
      do {
        printf("%d", node->data);
      } while ((node = node->next));
    
      node = reverse_linked_list(nodes);
      do {
        printf("%d", node->data);
      } while ((node = node->next));
    
      return 0;
    }
Or something thereabouts.
I've never had to balance a tree either. But typically it's because the tree represents something essentially tree-shaped and preserving the structure is important. (For example, what would it mean to balance a DOM tree? Nobody would do that.)

On the other hand, I hope you're not saying that the DOM is the only tree you ever use and in 15 years you've never needed to build your own. If so, consider that companies might be interviewing people for programming jobs that aren't like that.

Are you not aware that most languages provide that for free? Note that the question was about implementing, not using. People use them all the time, but they don't reinvent the wheel to do so when it is in the standard library and has nice abstractions already.

Why is a web developer implementing a DFS by hand every day? I would not hire that person.

I'm not sure what you mean. I don't know any languages where you don't have to define your own node if you want to implement a new kind of tree, and write a bit of code to recurse over it. (In JavaScript the most common tree is the DOM, but you should still be able to build another one if you need it.)

Also, in an interview it's perfectly fine to say you'd use a library, if you know one that applies. (They might ask you next how you'd do it without a library, but you still get points for knowing about it.)

The other thing to remember is that everyone is effectively grading on a curve, and with practice you get better at interviews.

On one hand -- sure, I've sadly forgotten most of the math I ever learned.

But on the other hand, no. I can bounce around modelling with basic data structures (hashes, arrays, structs/objects etc) in my head like a good juggler can treat 3 balls.

I think that is normal for quite a large subset of developer work. I assume there will be some jobs that won't need those data structures, but can't think of any. (Graphics and game developers would remember more math, of course.)

The description in the GP sounds more like the (probably false) stories about the Japanese English education: People with a vocabulary of 40K words that are unable to order coffee or talk about the weather.