We suffered one, he was on a two man team. Reviewing his pull requests took at least a day, which were effectively rewrites by the more experienced dev.
We eventually had to let him go, but the technical debt remains. For example, tests that mock everything so that they didn't actually exercise any of the code!
Isn't my original blog post at least a little bit of evidence that I've put a good bit of time into thinking about that?
I mean, a "bad hire" with the consulting/open source shop where I did a lot of interviewing & hiring was something pretty specific. A bad hire where I am right now is something pretty specific.
You know what. I'm just gonna talk candidates 30 minutes about them, us, me, the company (just talk, not any sort of test). Then I'll ask it to write a program to print number from 1 to 10 (that will be the test). And finally flip a coin before I take a decision (that's the randomness).
I'm pretty sure it follows none of the good practises or advise out there. Yet I'm confident that this is a process that has a low risk of accepting bad hires and a low risk of filtering good hires. =)
It's really really hard to come up with explicit actionable advice when a core part of your argument is that you need to do what is right for your team/company. To extend my TDD analogy, it would be like trying to write tests for someone else's codebase without any context.
If you want some specific feedback for your team, please reach out to me on Twitter. I'm always thrilled to talk to people about process and organizational development. I'd love to chat with you about actionable ideas for your specific need.
I agree to that. The hard part of hiring is that it is a lot of customization for the specific environment of a company.
Hence my message. Talking about his past and future career, mine and the company's plan is the best thing for me to do, because I'm pretty that the other interviewers have not talked much about that, if at all.
And I'm confident that the hardcore technical interviews have been done. They don't need me to make it harder, except for a few select senior candidates. A for loop in a few languages written on the resume is enough (and it's fun for candidates who have "assembly") :D
We eventually had to let him go, but the technical debt remains. For example, tests that mock everything so that they didn't actually exercise any of the code!