Data structures and algorithms are just parts, like screws and nails. When you're building a house, you don't need to remember if you should use 2 18-penny nails or 3 16-penny nails, or if you can use screws, and what kinds. What matters is that you know how to go look up the building code, find out what's required, use those parts, know how to verify they're installed correctly, and know the consequences to doing it wrong.

Once you've built a dozen houses you may remember these things implicitly, but you never need to remember them. You do need to know why they matter, how to look them up, and how to adapt them to your particular job.

This is not a good analogy as it seems to go very much into details.

If you're a builder I might expect you to know when to use a steel beam rather than timber even if you don't know by heart what grade and size for any random load (I don't know anything about building but that feels like the right level).

Likewise, if you're a software engineer I expect you to know what's a hash table, a binary tree, a linked list, etc., what are their pros and cons, and when you might want to use each of them. But in general I don't expect you to be able code a tree inversion off the top of your head. Obviously expectation of detailed and specific knowledge has to depend on previous experience and role.

I think we're in agreement. My point is that there's certain questions that certain roles shouldn't be expected to have the expertise to answer, and certain answers that make no difference to the job being hired for.

Say you need a builder for a house that an architect designed with wooden beams. Then you interview the builder, and ask them what kind of beam they should use for a theoretical house, and then ask them all sorts of questions about steel beams. Well they don't have the expertise to answer the first question, and the second question doesn't apply to this job at all!

Of course there's a body of knowledge that needs to be known. But I think we need to better codify what knowledge is needed by which people to do what kinds of work. And then have a way to establish that they know how to 'do the work', versus just having a body of knowledge.

We are still in the early days of the profession, and standard libraries are pretty small. Software sometimes requires fabricating parts that don’t exist, at least not on your platform or for your use case. None of us do it every day, but it’s tough to use people who can’t ever do it.

This! Data structures obviously do matter for software engineering. But memorizing the solutions to a handful of random, difficult, data structure problems isn't very useful for a real job and shouldn't be part of the hiring process.