[chadhietala]

As someone that just went through a whole slew of interviews I would say I agree with this to some extent. I'm a frontend developer and while CS principals are important, asking questions that are not practical to everyday development, are counter-productive and do not give you a view into how that person tackles a real problem.

Things like "write a function that performs merge sort", are bullshit because you would never do this in real life, largely because languages have sort methods that are already extremely performant. Plus a lot of languages will already be using some variant of merge sort and exposing it as a "sort" method.

If you are given a problem like "create a tabbed news component" or you're asked to do a small project (nothing longer than an hour), I think you can still get a good understanding of how people solve problems. This is less stressful, less "gotcha" mentality, and a fair approach.

[mark-r]

Merge sort is a bad example - it can actually be useful in real life, because the library sort functions are limited to what will fit in memory while merge sort is not. It's also simple enough to keep in your head without needing to look it up. I've had to code it up on the job more than once.