Convincing engineers to join your team

It's very free-form and honest, and gives you the potential to dive into things technically.

Do you like C or C++ better? Oh you don't like pointers? How do you avoid them in C++? etc.

No matter how hard I try and how many times I do it, there is ALWAYS some idiotic hiccup that prevents me from paying for the candidate's room, car, etc. up front. I can give those companies all the credit cards and forms in the world, and somebody in the pipeline will screw it up and demand a couple hundred dollar charge from my candidate. It's so bad that I normally show up to meet the candidate in person simply so that I can use my personal card to ride over the hiccup.

If somebody at HN is looking for a startup idea, here's a "grubby" thing that someone could turn into a service that could browbeat the idiotic hotel companies into submission on.

1. An initial call, handled by a principal ("founder"), with the objective of explaining the role and the company and arming the candidate with as much detail about the hiring process as is practicable.

2. A followup in email shortly thereafter confirming interest and locking down schedule.

3. 1-3 work-sample challenges (our current set, for the role we're hiring now, is a short combined AWS/Django security assessment, an automated best-effort-secure deployment of that Django app in a fresh AWS environment we provide, and a short API scanner programming challenge):

3a. Introduction: provide the candidate with advance knowledge of what will be on the challenge and what they'll want to know going in, along with time expectations.

3b. Preparation: offer the candidate books, links to presentations, and a practice version of the challenge to get confident and comfortable with the challenge.

3c. The challenge proper.

3d. Scoring: each challenge has a pre-built scoring rubric, on a 1-5 scale, designed so that anyone on the team can quickly score a submission.

4. Meet in person: after informing the candidate they did well on technical qualification, we do a single round of in-person "interviews"; no whiteboard, no coding, just meet and greet and discuss logistics.

5. Offer.

Missing from this process:

1. Recruiters.

2. Resumes.

3. Telephone interviews.

4. Technical interviews from members of the engineering team.

5. Any significant interruption to the engineering team's work.

6. Interview exercises with a member of our team watching you code.

7. Free pizza and coffee (though I guess if you asked, we'd send you one).

8. 5 of the 6 hours onsite this recommended process includes.

I'm happy to keep repeating this just as a sort of reminder that we're hiring, but this is a streamlined and improved (we didn't have practice challenges at Matasano!) version of the way we've been hiring for coming up on 10 years, and it works spectacularly well for us. People keep telling me why what we're doing can't work, and I keep wondering what I'm doing wrong to make it work.

You should consider cutting way back on interviews --- especially telephone interviews, which I've found to be completely worthless as generators of real insight into candidates --- and replacing them with work-sample challenges. But be serious about it if you do: candidates hate "take-home projects", and when I ask them about it, it always turns out that those projects precede or follow a standard interview loop. Fuck the interview loop. Interviews are a random function. Figure out what skills you need candidates to have on day 1, and then just build something that checks if candidates have those skills.

As a potential interviewee, the specter of ever working at a place that tolerates all day meetings again sends chills up my spine.