The Non-Technical Technical Screen

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 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 your client is going to be asking them to do. If somebody’s been building backend integrations for a VOIP firm, they can probably bang out your client’s 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 neckbeard? 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.

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

Bored? Talk about your client’s 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 pass them on to your client or not, you want them to leave ready to move forward if the opportunity 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.

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.1

So, what sorts of questions should you ask?

Below are some examples, in rough conversational order:

  • Where are you working these days? Do you like it? What you’re looking for: An in. This question has less to do with how they’ll fit in, but much more to do with how you can get them in. You’re looking for contrast points with what your client has to offer. What are their pain points and what can you sell to them. Alternatively, if they’re not complaining at all, you might have to do a lot more work later. That said: Even the happiest developer will complain about something if you give them a window. Use that later.

  • What do they have you working on? How are you building that? What you’re looking for: A bit of the above — job dissatisfaction, but also a segue into later questions. Also look for connections, thematically or otherwise, with the work you have in mind for them. They don’t have to be connected, but if they are, that can be a handy indicator that they can do the job you’re hiring for — because they’re already kinda doing it.

  • What’s your favorite language? Why? What you’re looking for: You don’t necessarily need your client’s programming language to be the favorite2. Look more for the energy behind this question. They should be excited to talk about languages and should have enough knowledge of their favorite and others to give good reasons for liking it. The actual content of the answer doesn’t matter nearly as much as those factors: are they excited when they talk about languages, and do they seem somewhat familiar with more than one?

  • Anything on the side? What you’re looking for: Ideally something. Side projects are another important indicator. The great developers are always exploring, fiddling and screwing around with experiments outside their day job. What that side project(s) consists of can also give you a glimpse at what they truly care about.

  • Any experience with X? What you’re looking for: X in this case is some specific requirement or nice-to-have your client has in mind. If they say no, be prepared to explain what it is you’re talking about to see if they at least get it conceptually.

  • What do you do for fun? What you’re looking for: This one can go two ways. If the answer is “more programming,” that’s a good sign (see the Anything on the side question above). But it’s not a negative if that’s not the answer. After all, your client like wants to hire interesting people who like to explore. You want to get a sense of that. As an aside: It’s been my experience that home brewing beer is a popular answer to this, at least among the best developers I’ve known or hired.

  • What’s the nastiest problem you’ve run across? What you’re looking for: Almost every developer has a horror story or two. You want to hear how they thought through the problem and how it turned out.

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

  2. Unless language knowledge is a hard requirement of your client’s. And I’d argue to them that it shouldn’t be.

comments powered by Disqus