I interview a lot of candidates as well, and I agree. My philosophy is that an interview is an opportunity to talk about a problem together and sketch out some code. The only reason we choose to talk about algorithms and data structures is because they're a domain that's pretty similar no matter what sort of programming you've been doing.
"Memorizing" these algorithms isn't the approach I'd use at all. No interview of mine will ever be of the form "implement such-and-such well-known algorithm".
However, my questions do begin with "imagine we're on the x team and we have y technical problem - what should we do?", and it's helpful to have a toolchest of coding techniques that includes hash tables, trees, etc.
I haven't used hashtables or trees since I was in university, 15 years ago. I'd look them up if I needed them, but I never really have. Do people really keep these things in active memory?
If you're coding in a modern dynamic language, you're probably using hashtables every day without realizing it (that's one popular way dictionaries/associative arrays are implemented). As for trees, your code is a tree. Every time you're working with a nested data structure, you're working with a tree. Trees are fundamental to programming and data representation in a way hardly anything else is.
As for trees, your code is a tree. Every time you're working with a nested data structure, you're working with a tree. Trees are fundamental to programming and data representation in a way hardly anything else is.
I haven't really needed to write a program to traverse my code as a tree, but I guess you're right that I must have used trees in C at some point.
Comments
I interview a lot of candidates as well, and I agree. My philosophy is that an interview is an opportunity to talk about a problem together and sketch out some code. The only reason we choose to talk about algorithms and data structures is because they're a domain that's pretty similar no matter what sort of programming you've been doing.
"Memorizing" these algorithms isn't the approach I'd use at all. No interview of mine will ever be of the form "implement such-and-such well-known algorithm".
However, my questions do begin with "imagine we're on the x team and we have y technical problem - what should we do?", and it's helpful to have a toolchest of coding techniques that includes hash tables, trees, etc.
I haven't used hashtables or trees since I was in university, 15 years ago. I'd look them up if I needed them, but I never really have. Do people really keep these things in active memory?
If you're coding in a modern dynamic language, you're probably using hashtables every day without realizing it (that's one popular way dictionaries/associative arrays are implemented). As for trees, your code is a tree. Every time you're working with a nested data structure, you're working with a tree. Trees are fundamental to programming and data representation in a way hardly anything else is.
I see. I don't do that very much.
I haven't really needed to write a program to traverse my code as a tree, but I guess you're right that I must have used trees in C at some point.