The key to a lot of the techniques I’m recommending you follow in hiring is to know the developer you’re going to hire before you ever approach each other.

Knowing ahead of time what drives your potential hire - negative and positive - and what their inherent skills are ahead of time eliminates a host of typical hiring bullshit.

More than that, it gives you a leg up when it comes time to get them hired.

There’s few things more powerful to a typical human than feeling wanted, and saying to the candidate you like and want to hire, “I’ve been following you for a while now, and I’m talking with you because I feel you would be a great fit at our company,” does absolute wonders to get a initially hesitant candidate in the door.

So, let’s talk about how to do the research you need.

Follow your candidates, even when you don’t have an opening

The thing with hiring is that it can happen at almost any time, and typically when you are least prepared.

For instance: A new project landed on my department’s desk this week, at a time when we have all backend resources tied up in other projects. We can’t outsource it for political reasons, so I suddenly find myself needing someone to handle this new project (and then stay on as our workload keeps increasing).

Oh, and I need the guy or gal to start as soon as humanly possible. Throw in a standard two-week notice and this backend resource is going to be coming into the project late and will have some catching up to do right away.

If you run into this sort of situation from a cold start - with no leads, no ideas, no possibilities - you’re pretty screwed. Your only real options - before timelines start getting away from you - are either contract/freelance or call in the recruiters.

As soon as you get the go-ahead to hire, you should already be in a position where you can pick up the phone (so to speak) and call someone right away to set up an initial interview or contact.

And the way you get there is to always be in a hiring mode. This process never stops, because when it stops will be the exact moment you need to hire someone (see: Murphy’s Law).

The best time to get back into hiring mode if you’ve been out of it for a while is right after making a hire. There are always candidates you liked but weren’t ready, or that you simply didn’t get to connect with. Even better: often you’ll find candidates that aren’t a good fit for the position, but are perfect for another role on your team or in your company.

Make a list of these folks and then follow them on Twitter, their blog, their GitHub, what have you. You want to keep an eye on them for a while - so you can confirm all those initial thoughts and be prepared for that hire-on-a-dime situation I mentioned earlier. Essentially, now’s the time to do all the research you need so you can make a confident hire later.

The other trick to always being in a hiring mindset is that you have your eyes open enough to spot potential candidates when you’re off-cycle. When you see a local developer building something interesting, make a note of it. When you see a developer complaining about their job, make a bigger note of it.

See, what you’re trying to do is the greatly increase the surface area of your later search. Trying to tease out these kind of details in a two-week window when you’re under the gun to make a hire is an exercise in futility. There’s simply no time. But if you start that period already knowing that this guy feels underappreciated and knows exactly the programming language you need, you’re already golden.

You can make your list something official-like - an Excel sheet, Google Doc or the like - if that’s your style. Or you can just keep all this in your head. I typically do the latter, but to each their own.

One final note: One of the other advantages to the Uninterview I talked about a while back, is that they’re freeform enough that you can do them at almost any time. In other words: You can stockpile “interviews” well before you get an opportunity to hire.

What to watch for

So, as we’re following all these developers long-term, there are certain behaviors/references you want to pay special attention to so you know a) which pressure points to use later, b) whether they would eventually be a good fit for your team, c) whether they can hack it.

Displeasure with their current job

People love to bitch about their job. It comes naturally and if you follow someone on Twitter or the like long enough, you’ll start to notice patterns that can come in handy later.

One important note: Complaining about your job is not a character defect. Everybody does it, and your current employees - no matter how well you think you treat them - probably do it, too. No job is perfect … some are just more perfect than others.

Now: If their entire social presence is complaining and whining, that’s another story. But the occasional complaint is common, and useful when you get to later hiring stages.

The biggest ones to watch for are signs of boredom. As Rands says, “bored people quit”. Someone who’s bored at their current job is somebody who’s ready to move - and is likely already starting to absent-mindedly surf job boards.

The other things to watch for are what particular pain points come up frequently, especially those that are direct opposition to how your own company operates:

  • Bureaucracy: Do they complain about things like vacation policies, timesheets, bad management, projects that get killed?
  • Work-life balance: Are they complaining about having to be at the office until late at night, or tweeting about work over the weekend? Most importantly: Is this a one-time thing? Or is it happening constantly?
  • Feedback: Do they complain about a lack of feedback on their job?

Side projects

One of the other key things you want to look for is if they have development projects outside of their job.

Why does this matter?

Because, from my experience, you want to find inquisitive developers to hire. You want them to be willing to explore and learn. And side projects are one of the best possible indicators of that.

More than that, a developer with a side project likely has to be in a position where they need to think of the holistic product. They aren’t in a position to just think about pure code, but they might also need to think about things like marketing, user experience and the like.

And that’s the type of developer you want to hire: Someone who can contribute more than code to your company.

A developer that does more than right code can 10x their impact on your company right away. Adding a developer with this mindset into the creative process can reap dividends and any marketing experience points to new avenues to explore.

References to multiple programming languages

Much like side projects, multiple languages suggests a preferred level of inquisitiveness.

More so, it can foretell a pragmatic, rather than dogmatic, approach to the work.

In business, dogma can be an absolute killer. Whether you’re lean, agile, or some more traditional management philosophy, the last thing you want to do is waste cycles and time trying to fit square pegs in round holes. And when a developer has more tools in their toolbox, your chances of that happening become much less likely.

You want to hire flexible, pragmatic and curious developers that want to learn and grow with your company.

It helps if you already see evidence of that.

When you hire, you want to find a developer that knows (or can learn) your preferred language, but if they run across a problem that’s better solved in some other language, you’re going to be better off.

Do they feel like a somebody you could hang out with?

Ultimately, who you hire will be someone you’re going to end up spending a hell of a lot of time with - sometimes more than your immediate family.

So, it makes sense to make sure that the person you hire is somebody you can stand.

Here it gets down to more abstract things:

  • Similar interests: In an ideal world, the folks you hire have a similar mindset to you. You don’t want it to be exact, because then you get a boring staff that all think the same. However, you do want to find overlaps and common touch points. For instance, initial contact with one of our current employees was made after they made a reference to “Fear and Loathing in Las Vegas.” It wasn’t a big factor in the ultimate hire, but it was enough to pique my interest.
  • General demeanor: We touched on this in the earlier Displeasure with their current job section, but you can glean a lot about a candidate’s personality from the social media footprint. Do they complain an inordinate amount? Are they friendly with lots of folks? Are they helpful?
  • Likeability: Check your favorites list. Do you see a single name popping up over and over? Make a note of it.