It does not work at all when trying to recruit a senior. I am still clueless about that. I have at least two recent cases in mind of a senior hire that lead to catastrophic results. People that new how to present well at a superficial level but did really poorly once they had non trivial stuff to do.
I mean it's not about writing "hello world". If the person is not dumb, you won't find out in an interview if someone can really code. (repos are much better for that, but can be deceiving)
"We have a 3 month probation period and if something is really not true it will have consequences. I'm crystal clear about that."
I mean we are all humans, but there is also a contract with money involved. I have to look out for the company and it has to be fair for all the other team mates/colleagues too. If you hire some "faker", without consequences it will destroy the whole team balance. (Additionally there is a "meet the team" to address the consent process). From my experience, technical people have a low tolerance for people which can only talk...(in a technical team).
So it does not mean you are safe if you can make it through the inverviews with tricks. (it may seem a bit hard, but I don't like the general acceptance of "lying" or superbeautify ^^ in the application process)
And then I talk about what we are working on and how we are structured. So the interviewee also gets an impression what the day to day work will look like.
What I really want to see, is the ability to solve problems. Because this is our real job. We are solving problems(with code). So I ask questions you can not solve in 5 minutes, but you see how someone approaches a problem. Is the person collecting intel about conditions and constraints or is he/she immediatly starting to code etc. ... For that I generally take real problems we had and we already found a solution. And sure I tell them, that it is not possible to find a solution now, because many interviewees are "conditioned" (or used to) to give you immediate solutions. Else they would panic or getting frustrated.
In general ask a question: Why should I want to barbecue(or embarass) a possible colleague?
You also have to take into account, that there are people which don't know everything yet from the specifics you need. But in the right environment with support of colleagues, they become really great. It's more about the mindset & willingness to learn and also the support of the team members.
The above is more for a general developer.
For an expert with 7y+ (whatever..) experience in a specific topic. I would really ask very specific questions and maybe a "homework". Because I hire an expert for specific experience in a topic. Also the risk of losing money & time is much higher. Because it's experts work...it's hard to judge if the person is not capable or if it really just needs some extra time.. ;-) You won't believe how many people have a lot of years of experience and made only basic stuff during that time. So on paper they should be an expert, but in reality they are not.
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.
