This is a tough subject. I don't believe deep understanding of algorithms and data structures is necessary for the vast majority of engineering tasks. Most (almost all) engineers can get by understanding complexity notation and a matrix comparing time/space complexity for various algorithms and data stuctures, no memorization required. And even that is overkill, as most of time the "natural" one suggested by a problem will suffice. For example, "I need to map keys to value, so I'll use the Python dict class" will get the job done with acceptable performance almost every time.
Whiteboard interviewing based on these things isn't useful unless the candidate is being considered for a position in which knowing these things is fundamentally necessary (e.g. they'll be responsible for developing new algorithms or squeezing out the last 10% of optimization available).
On the other hand, substituting requirements for having public code profiles, and the assortment of take-home projects, in-office projects, pair programming to solve a problem the company is facing (especially if unpaid) is just as bad, for different reasons.
And certainly not asking technical questions is problematic.
I just don't know what the solution is. It's one of those things where I know a bad interview when I see it.
Whiteboard interviewing based on these things isn't useful unless the candidate is being considered for a position in which knowing these things is fundamentally necessary (e.g. they'll be responsible for developing new algorithms or squeezing out the last 10% of optimization available).
On the other hand, substituting requirements for having public code profiles, and the assortment of take-home projects, in-office projects, pair programming to solve a problem the company is facing (especially if unpaid) is just as bad, for different reasons.
And certainly not asking technical questions is problematic.
I just don't know what the solution is. It's one of those things where I know a bad interview when I see it.