[skybrian]

Well, for example, I have an interview question where it's not just about knowing what a stack or a tree is, but rather realizing that a stack or a tree might be useful to solve a particular problem. (You could use either one.) And then writing out code to do it.

So, no esoteric data structures, but you really do have to know how to use the standard ones. It tends to trip up people who might have some book knowledge of CS but don't know how to apply what they learned. There's also a difference between knowing that a tree might be useful and being able to actually write some code to build a tree.

But the thing is, the next interviewer will have different preferences - there's no standardization here.

[Retric]

I have had many people with 3-5 years of 'experience' developing not know how to find the smallest element in an array. Initially I was thinking it would be a quick check to see if people thought about null values, but apparently this is a hard problem...

Now they might have been useful for something, but I suspect they are just playing the numbers game and showing up to a lot of interviews until they get in. So even if say 5% of coders are useless that 5% is vastly over inflated in the interview process.

[arghnoname]

I think it is interview paralysis. They can't believe an interview answer is ever supposed to be O(n). I've had it happen to me where I get tripped up on relatively easy problems because the initial easy solution I came up with wasn't sufficiently clever and magically log n or some such thing.

[new299]

I can't believe it's just interview paralysis to be honest. I've had people try and solve problems like that with 3 nested loops. Completely failing to come up with a working solution after 20 minutes.

I've been in situations where those kind of people have been hired too. Their code tends to be quite bad...

[Retric]

Any suggestions for dealing with this? I try and keep things as relaxed as possible to start with and make it clear that trivia and syntax is not what I am going after.

I would walk out of the room, but I am happy to walk someone though most of a problem they are not getting. The goal is going from an understood problem to actual code.

[cwilkes]

In addition to the obvious have the person walk you through what they are going to do try rewording it slightly. In this case ask for the max value.

Maybe they are nervous and focused too much on the minimum part of this that they lose sight of what they are trying to solve for. But be careful not to spoon feed it to them.

[lawnchair_larry]

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.

[xiaoma]

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.

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

[berntb]

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.