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.
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.
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.
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).
#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;
}
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.
Why is a web developer implementing a DFS by hand every day? I would not hire that person.
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.
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.