In my extremely limited experience in hiring (very few people), I made multiple mistakes. One of the thing I discovered (we were hiring a junior and both of us

In my extremely limited experience in hiring (very few people), I made multiple mistakes. One of the thing I discovered (we were hiring a junior and both of us gave approval) was that you can find a person who can solve problems but can't actually code (there were a lot of red flags that we ignored on purpose I guess). It isn't until I read your answer that I realized this: we were both convinced because the guy was smart, clearly, however he didn't know enough of the technology we were using to develop anything meaningful with it. While when hiring a senior developer, it's possible that they can pick-up a new language or framework very fast, this is highly unlikely with a junior (this is not something I have in numbers, just thought). The real side of the problem is that is very hard to figure out if someone will be good with everything that's not "oh, you can code". It's not well defined in the industry, so there is no objective methodology to evaluate the skills of a person. As a developer, you can usually recognize if someone can code, but determining if they are sloppy, care for design, that's a totally different thing: you need to work with them to figure that out, this is probably why an interview is not enough.