[tetsuhamu]

Reasons we test for data structures and algorithms:

- The work sucks because existing employees don't know DSA's

- We want people to re-implement and refactor with better DSA's

- We want to know the candidate studied for the interview (took it seriously)

- We actually do want them to know DSA's when joining the team

- It's the least you can do when applying for a CS job

Most recruiters provide links and resources, the material isn't a mystery.

[AnimalMuppet]

The material is irrelevant, at least for most software engineers. (For a FAANG, not so much. But for most places? Irrelevant.)

I understand the time-space tradeoffs of the various STL collections, and the Java collections. In 35 years, that's been all I have needed. (And, if it does come up, why spend months memorizing what I can spend minutes googleing?) I am not a huge outlier.

Interview for what you need. Anything else is wasteful. Do your people spend most of their time trying to squeeze the absolute most efficiency out of their data structures and algorithms? If so, yes, interview for that. If not, though, then don't interview for that.

Leetcode interviews when that doesn't match the work are just abuse. "Here, take months of your spare time learning to jump through this hoop that's actually irrelevant to the job." That's abuse. The only way that makes any sense is if you need employees that you can continue to abuse after you hire them. And if so, then I don't want to work for your company.

As I said, FAANGs are an exception. They need people who can go from n (log n)^2 to n log n. It makes a huge difference to them. If that's your company, then I'm not talking about you.

[wiseowise]

You're making it sound like only FAANGs operate on such a scale.

[AnimalMuppet]

I didn't mean to do so. But I would say that the large majority of software engineers work on stuff that doesn't operate at that scale.

[Edit: Or perhaps I should say that far more companies interview as if they operated at that scale than actually operate there.]

[jfengel]

It's the least you can do when applying for a CS job

I think that's precisely it: it's the least you can do. Students are taught data structures and algorithms because they don't know anything else. They can sort numbers and munge strings... and that's all.

They don't know any frameworks. They don't know any problem domains. They don't know how to debug, or read an API, or identify code smells.

But they have to write something, and if you want that something to be more than three lines long you have to make them do something complicated with the incredibly limited domain of knowledge they have. Thus, data structures and algorithms.

Nobody ever needs to calculate Fibonacci numbers. But if they can't write a recursive descent compiler, or even handle an HTML parser, they have to learn to write recursive code on something. Thus, they do something trivial.

And then they forget it, because they've applied that knowledge to something more useful. Much as you never do long division by hand, even though you had to learn how to, and you would possibly screw it up if handed one now.

A student getting a BS had better know a lot more than the least of it. Test it if you can't think of anything else that might know, but it's not going to tell you if they know anything that matters.

And the engineer with more experience is even less likely to have used that freshman-year stuff recently. As you say, it can tell you that they cared enough to cram it again... but they're cramming it because they don't actually need it.