[user5994461]

Hum. Didn't read the usernames.

Too much theory and not enough actionable advice.

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. =)

[ramblinjan]

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.

[user5994461]

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