> need to roll their own new solutions in the face of so many well-established libraries

I'm not defending interview quiz-time, but it isn't (or shouldn't be) about rolling your own solution. It's about understanding concepts. Understanding the basics of time/space complexity are pretty fundamental when designing systems.

Developers frequently encounter hashing and (probably less-often) trees, so I don't see an issue with asking something like "Why/how/when is a hash-based lookup faster <in some situation> than a tree-based lookup?" (as one question during an interview). If a person can give a good answer to this, they'll pretty easily be able to understand the performance tradeoffs of hash vs btree indexes when using mysql (and this same tradeoff in a variety of other situations).

> "before you ask me to demonstrate a depth-first search, you had better explain to me why I'm going to need to be doing that instead of just writing an SQL query and tweaking an index"

How I am going to ask you to tweak an index, if you don't know how to browse a tree? Although I would have asked you about B+ and B* trees, the ones used to index a database. There are differences in those trees and you need to know them in order to decide which one is a better option to improve the performance of the queries. Obviously this improvement means nothing for a small startup, but image the impact it has in a company as Google.

I think the point is that a lot of interviewers make those questions because big companies do them. But there is a reason why they do them. Obviously I would prefer the candidate that knows the answer over another one that also does the job but doesn't know the answer.

"Perhaps you won't, but since we don't know yet exactly what you'll be working on, we might know broadly what PA or even project, but we can't know what problems you will encounter or what direction it will take to debug any problems that arise, we want someone with a broad base of skills who can at the very least recognize performance problems and solve them in a simple case. We expect that if you can solve this relatively simple problem in an environment with no resources, that with the aide of documentation, profiling tools, and teammates to lean on, you'll be able to address much more complex issues that arise. On the other hand, if it takes you documentation and teammates to solve this simple case, who knows what kinds of tools it will take you to solve real world problems that arise."

"Correlation does not imply causation" doesn't imply that correlation never implies causation.

> If any company were to quiz me on algorithmic basics, it had better explain to me beforehand why it is among the x% of all hiring companies that actually need to roll their own new solutions in the face of so many well-established libraries.

Please suggest a reasonable alternative then. I need to interview people and see if they are going to be capable of digging through complicated code, of coding things reasonably quickly, or writing scalable, robust code, of potentially digging into things enough to optimize their performance, etc. as reasonably well as I can in an hour. And I need enough concrete evidence that everyone else in the debrief believes me. I would love to change the way I do things, but I am held accountable for the interview, so I can't just show up to the debriefs saying crap like, "He says he can use a library for anything that comes up." And I need to evaluate some other soft skills type stuff, like caring about the customer, communicating well, delivering more if you see something extra that you think should be done, etc.

But the obvious answer to your question would be, "because if everything we do could be solved just by using a library, we'd have interns or offshore people do it for a fraction of the pay."

> Not revealed as a terrible company, perhaps, but as a terrible interviewer.

Some software is HEAVY on data structures and algorithms? But, then hopefully someone not interested in that would not apply...

In fact, it should be explained at the job offer text. With an added bonus that people then can self select in or out of the offer without losing any further time.

Ironically enough I was never asked about DFS during my interview but needed it for the first thing I worked on after getting hired.

> If you work really hard, learn all of this stuff, and do a really good job and save your company a bunch of trouble by knowing all of this, you won't get a dime for it, and that's the problem

I think that is your problem. I don't stay in companies where I don't feel valued. And anyway you are receiving a salary every month for your work. If you think you should get more, ask for more or move to another place.

For some people security is more important, for it is not. Because I believe that in the current society the companies can fall in few years (Nokia, Canon, ...). My security lies in my knowledge and my skills, and that is something I take with me whereever I am. I recall something I read, it was like this: "A bird is not scared of a branch to break, because it lies his confidence in his skills to fly".

The research you have to do is based on your previous knowledge. The less you know the more you need to learn when you are facing a problem you don't know how to solve it. But people is lazy, if they know a way to solve it they will go that way even if it is the worst way possible.

I am not talking about implementing an AVL tree without any help or resource. That is simple stupid, we have internet we must use it and save time. My point is that you need to know that there are balanced trees, know some of them and they characteristics. That knowledge will save you time when you face problems related to trees. You are not going to know all the trees because researches are working on new ones every day, but you should have some knowledge in the area.

If you interviewer drop you because you hesitate in something, maybe it is the interviewer problem and not yours. We are not perfect, we should know people will make mistakes and hesitate. I was rejected of interviews when I hesitate when they asked something about linked lists. I was happy it happened, because I was in shock when I was explanning how I did something with and A* algorithm and a octree and I couldn't believe the next question was about a linked list. I wouldn't be happy in that company.

> No, what would happen is you'd say to yourself "Hmm, looks like I need a self-balancing tree. Haven't thought about those in N years..."

You're attacking a strawman which has little to do with the original post or what the other commenter is saying. There's a lot of developers out there who lack the knowledge to ask the question you pose in the first place, so wouldn't end up doing that searching. The type of interviewing you're criticizing is intended to identify developers lacking the kind of base knowledge needed as a foundation for further inquiry.

Yes, this is what I meant

You sound like you've worked with significantly different code than I have. Your "never once" is my "almost always", and my "X reason" is often because I'm working with an immature, unreleased library developed by another team at my employer.