This is a lie that everyone tells themselves to make them feel secure and safe.
The best interview is working with the person. Do a few basic interviews for competency, give them a 2 week - month long 1099 contract and put them on guard rails for the contract duration.
Their daily work isn't just about whether they can jump through time-based hoops or answer basic questions. No one is going to know whether it is a mutual match until the person gets into the codebase and start working.
Plenty of great engineers have "performance problems" not because they are bad engineers but because of problems an interview will never expose or detect like a bad teammate or lead match causing disagreements, a bad codebase, poor planning that only builds tech debt, bad business plan, disagreement on business direction, etc.
The idea that an interview can filter good or bad engineers is laughable. The most you can determine from an interview, regardless of how many flaming hoops and balls the candidate bounces off their nose, is whether they know how to code and _probably_ know what you need them to know.
> The most you can determine from an interview, regardless of how many flaming hoops and balls the candidate bounces off their nose, is whether they know how to code
When I interview I don't even mention code or technical stuff (that is for someone else to ask) and I am able to learn quite a bit about a person and if they would be a good fit. Just because you can't doesn't mean other people can't.
This is a lie that everyone tells themselves to make them feel secure and safe.
The best interview is working with the person. Do a few basic interviews for competency, give them a 2 week - month long 1099 contract and put them on guard rails for the contract duration.
Their daily work isn't just about whether they can jump through time-based hoops or answer basic questions. No one is going to know whether it is a mutual match until the person gets into the codebase and start working.
Plenty of great engineers have "performance problems" not because they are bad engineers but because of problems an interview will never expose or detect like a bad teammate or lead match causing disagreements, a bad codebase, poor planning that only builds tech debt, bad business plan, disagreement on business direction, etc.
The idea that an interview can filter good or bad engineers is laughable. The most you can determine from an interview, regardless of how many flaming hoops and balls the candidate bounces off their nose, is whether they know how to code and _probably_ know what you need them to know.