To take a more nuanced view, I think there is an important distinction, frequently lost, between "can't code" -- which is all too common in practice -- and "can't easily code a stream-of-consciousness solution to a synthetic problem unrelated to anything I've ever built". Or its close cousin "can't easily code a toy solution to your toy problem since I've only worked on massively scalable versions of the same problem". Something I keep in mind when interviewing candidates is that there is that good understanding of the general design of algorithms does not imply that they should be able to throw together an
implementation of an arbitrary algorithm with minimal effort unless they've needed to do it in the recent past. Expecting people to spending many days practicing the
implementation of arbitrary and often irrelevant algorithms is unreasonably in my opinion. I am more interested in figuring out if they
could given adequate time.
A valuable practice, which surprisingly few tech companies do, is to ask candidates about diverse and orthogonal problem domains, or alternatively, allow the candidate to pick from a diverse set of problem domains. In the former case, you often find that candidates have difficulty writing even simple solutions for some problems but on others they instantly and fluidly can code up a good solution. Because they've had to do it in recent memory and still have the "muscle memory" from doing it previously. You often see bipolar results across the problem set this way.
For senior engineers with deep domain expertise in an area, there is an additional trap in that they use more sophisticated and often very different algorithms in their day to day lives than are applicable to the toy problem domains. Graph algorithms are a good example of this, and they are popular in interviews. The representations most engineers know (e.g. adjacency list or matrix) don't scale but the extremely high scale algorithms operate on a different set of principles that aren't trivial to code and aren't relevant to non-parallel cases; coding up an adjacency list graph traversal algorithm is going to be very unnatural to a software engineer used to doing the same on trillions of edges in real-time. It would be crazy not to hire an engineer on this basis but I've seen it happen, ironically because their expertise caused them to show poorly on the coding exercise.
Interviewing for technical skills is intrinsically difficult but I think that as an industry we are much worse at it than we could be. For all the claims of companies that they only hire the "top 10%" or whatever of engineers, the interview process is often optimized to the benefit of the median engineer.
A valuable practice, which surprisingly few tech companies do, is to ask candidates about diverse and orthogonal problem domains, or alternatively, allow the candidate to pick from a diverse set of problem domains. In the former case, you often find that candidates have difficulty writing even simple solutions for some problems but on others they instantly and fluidly can code up a good solution. Because they've had to do it in recent memory and still have the "muscle memory" from doing it previously. You often see bipolar results across the problem set this way.
For senior engineers with deep domain expertise in an area, there is an additional trap in that they use more sophisticated and often very different algorithms in their day to day lives than are applicable to the toy problem domains. Graph algorithms are a good example of this, and they are popular in interviews. The representations most engineers know (e.g. adjacency list or matrix) don't scale but the extremely high scale algorithms operate on a different set of principles that aren't trivial to code and aren't relevant to non-parallel cases; coding up an adjacency list graph traversal algorithm is going to be very unnatural to a software engineer used to doing the same on trillions of edges in real-time. It would be crazy not to hire an engineer on this basis but I've seen it happen, ironically because their expertise caused them to show poorly on the coding exercise.
Interviewing for technical skills is intrinsically difficult but I think that as an industry we are much worse at it than we could be. For all the claims of companies that they only hire the "top 10%" or whatever of engineers, the interview process is often optimized to the benefit of the median engineer.