[microcolonel]

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.

[vonmoltke]

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

[roganartu]

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

[ivanhoe]

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

[microcolonel]

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.

[skybrian]

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.

[lawnchair_larry]

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.

[skybrian]

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.