Hiring a programmer? Make some tea!

Whilst looking for my next job, I’m finding that the hiring process has become little more than an exercise in matching tags.

A few years ago I responded to a question on Quora, How do I explain to non-programmers how complex, time-consuming, and error-prone software development is?.

The essence of my response was to describe how an apparently simple process of making tea is not as simple as it first seems, and that the thinking behind it contains thousands of details that programmers need to consider.

It was a popular response that resonated with a lot of developers.

A few days ago I tweeted a joke about how we’d hire drivers like we hire programmers. But I am going to keep the tea analogy going and recast it:

If we advertised for someone to make tea like devs.

Required:
- three years of brewing experience
- can boil a kettle
- knowledge of cold water and electricity, particular mains AC
- experience with Yorkshire tea bags, PG tips. Tetley a bonus
- proven and demonstrateable skills chopping tea leaves
- chemistry of oxidation converting polyphenols into
  compounds such as theaflavins and thearubigins
- Bone china cup making 

For developers, a lot of job adverts read that way.

A common thing that comes up is whether the candidate has previously used a particular product like a database or queue. Those tools are big and complicated, and appear in architecture diagrams and are rightfully critical to the system. So, it is natural to ask if the candidate has used them before.

But here’s the thing, from a programmers perspective the specific products are not a big deal. The difference from one database to the next is trivial and has very little impact on what the programmer is doing day to day.

If those systems have a large impact daily, then you have a much bigger problem, your architecture or use of those products is inappropriate, and a good developer will debug it.

Some products have novel features that others don’t, and any developer will learn those features quickly (hours), and apply them to the problem at hand.

It feels like an easy shortcut to match candidates against products and techniques (TDD, ATDD, BDD, OO, FP, etc.), but by doing so you’re missing out on good people which will cost you more in the long run.

Focus on what really matters. Is the candidate passionate about solving problems, building what users need, striving for simplicity, producing bug free systems, and know how to do those things?

Most importantly, can the team have an enjoyable cup of tea with the candidate whilst discussing how the system and processes you’re building could be improved?