What follows is part of a Chapter in my forthcoming book “The DIY Recruiting Guide.” Said book will be coming out later this year (I’m working on a smaller book/email course on hiring and managing outside development firms first), but I wanted to give a quick sneak peek since this topic has come up in conversation lately.

Assuming you’ve done your research ahead of time, the traditional interview process becomes burdensome and largely unnecessary.

After all, a lot of the traditional interview process is about vetting a candidate. But you’ve largely already done that. You’ve looked at his or her work, you’ve read their writing, you might have even been following them on Twitter or the like for quite a while.

As the amount of research in hand grows, that vetting burden, especially technical, continues to shrink. At some point, you already know, by the work your candidate has already done, that they can do the work you’re going to be asking them to do. If somebody’s been building backend integrations for a VOIP firm, they can probably bang out your dinky web sites without breaking much of a sweat.

My approach to an interview is largely breaks into these categories:

  1. Do I like the candidate? This one’s pretty simple, are they a douchebag? Are they a bro-grammer? A neck-beard? Basically, are they someone I think I won’t get laughed at when I bring them in front of the team later?

  2. Are all of my researching findings accurate? People are much less likely to lie on GitHub (or even Twitter) than a resume, but it’s still a great idea to backstop your earlier assumptions. Ask about the work they’ve done. Ask about the process of building it. Ask about what they still need to change. We’ll get into a bunch more questions in a little bit, but few things get a developer more at ease than talking about their work — especially work they’re proud of (or still carry scars from).

  3. Selling the job. This last bit has little to do with the candidate. I essentially do my absolute best to sell the position we’re filling. Since I’ve researched ahead of time, I likely know a fair bit about their current work environment — whether they’re overworked, underpaid (you can tell from Twitter most times), bored, worried. Take any all of those and contrast them with the fresh shiny that is your position.

    </li> </ol>

    If they’re overworked, mention work-life balance*.

    Bored? Talk about your most-exciting work. Remind them of how bored they are by talking more about their day-to-day.

    Worried? Play up the stability.

    Underpaid? Yeah, save that one for later.

    Whether you leave this interview ready to hire them or not, you want them to leave ready to accept an offer if it comes (and, ideally, obsessively checking email).

    The other thing I suggest with this first interview is to do so outside of the office. One of my favorites is to spring for lunch.

    I don’t like conducting interviews in the office for a couple of reasons:

    1. It doesn’t let me take chances. Occasionally, I’ll catch lunch with someone who I immediately know is a very bad fit. If it’s just me involved, no worries — I at least get lunch of it.

      Had I done the more-formal interview thing, he or she would have been brought through the office, introduced to everyone and the interview will expose my mistake to a whole bunch of people.

      An off-site lunch allows me to expand the possibilities.

    2. It ratchets up the stress level. When people are stressed, they do funny things. In an interview situation, they sweat, they stumble, they lie. Especially at initial contact, I want a candidate to make the best-possible impression on me that they can.

      I also want them to be relaxed enough to talk freely, without worry of screwing something up.

      And the same goes for me.

    The lunch technique works especially well for already-employed candidates — after all, everybody has to get lunch and occasionally they have lunch with friends, family, other. Lunch doesn’t raise any alarm bells with their current employer, it’s easy for them to get out for it, and it creates a relaxed environment for the interview.

    The other technique is to never call it an interview. It's lunch, a chat, a conversation. In fact, when you set it up, think about not mentioning the job opening at all.

    “DM @developer Can I buy you lunch sometime?”

    That’s all it takes most times. You can embellish that more from there, but at its core that’s the pitch: we chat, you get a free lunch.

    And make it just you and the developer. Adding more people ups the stress level. Remember: this is not an interview.**

     

    * - This is more a topic for a different book, but don’t be one of those guys who thinks in terms of 60-80 hour weeks. Programming is a creative endeavor much like writing. You want developers happy, clear-thinking and unburdened as much as possible. Get them out of the office on time and you’ll be rewarded.

    Mostly by not having to go through this process again in nine months or less.

    ** - Yeah. It totally is. But you don’t want to make it obvious.