How to hire a developer: Part 1 – Hiring for the future

In the first of a four-part series, Mike Ritchie offers some tips for anyone about to hire a developer.

See also:

• How to hire a developer: Part 2 – Why screen candidates?
• How to hire a software developer: Part 3 – Online tech tests and alternatives
• How to hire a developer: Part 4 – Why in-person technical interviews still matter

I do talks and workshops on software development careers and technical interview preparation for students at universities, colleges and code academies.

It occurred to me recently that I’m very tardy in having those same conversations with employers. Technical interviewing is a skill that’s often left to chance in organisations.

This four-part series aims to give some advice to individuals and companies who are involved in hiring developers. It’s not exhaustive, but hopefully you’ll take away some ideas you can apply in your own organisation.

I’m going to nail my colours to the mast here: I’m a techy, and this is written from the perspective of a developer (and occasional technical manager…) interviewing and hiring other developers, not from an HR, talent or recruitment perspective. I hope and expect that there’s a significant overlap between these perspectives, though.

Let’s warm up with a lively jog around some of the principles that we’ll build on in the next couple of posts.

Hire for trajectory

There’s a quote by author and programmer Kevlin Henney in a preface to Pete Goodliffe’s book, “Becoming a Better Programmer”. I often share this quote in talks, because it captures perfectly what I’m looking for when I’m building teams:

“In the long term, what matters is less where on the distribution someone is than where they are headed. If you want to divide programmers into two groups, there are programmers who get better and programmers who don’t. You care about the first group.”

What you’re seeing when you run technical interviews is a snapshot of someone’s abilities and knowledge, frozen at a point in time. But where did they start, how far have they come, and where are they headed?

The challenge in technical hiring is to spot these self-actualising, self-improving developers that Kevlin talks about, not just by looking at what they can do, but by looking at their journey, their attitude, the signs that they have improved, and continue to improve. We’ll talk more about this in later posts.

• Hire people for where they’re going to be, not for where they are now.

Hire for diversity

I’ve worked in software development for 30 years. I’ve seen some progress on diversity over that time, but the pace is still painfully slow. On gender equality, we have a long way to go. We all have a responsibility to fix this situation in tech for fundamental reasons of fairness, quite apart from the benefits that diverse teams bring.

But benefits there most certainly are. Diverse teams are good teams. Any developer will tell you about the value of a different mindset and a different perspective when solving problems.

To help counter unconscious bias in hiring, use the existing diversity in your team help you get to the next level. Get as diverse a pool of technical interviewers involved in your hiring process as you can, and give them a real voice in the hiring decision, not just tagging along for the ride.

Actively coach people in your team in technical interviewing – it’s a skill like any other, and it needs practice. If it remains something that senior managers do, you’re not going to make progress.

Some interview styles favour male candidates, in particular those candidates who are confident, assertive and sell themselves effectively. Bragging isn’t a uniquely male trait, but it’s certainly more prevalent.

If you structure your technical hiring around these formats, and factor in the unconscious bias that hiring managers have favouring candidates seen as “ambitious”, you’ve got a toxic combination on your hands.

In some of the interview styles we’re going to look at, there are positive benefits for diverse hiring. We’ll favour approaches that focus on collaborative traits, and give a more holistic view of how someone would fare in a team setting.

• Make diversity in your tech hiring an explicit goal, not an afterthought.
• Use interviewing approaches that favour collaborative problem-solving, rather than just giving a stage for confident and assertive candidates to be confident and assertive.
• Don’t use “ninja developer” and “rockstar developer” cliches: this is a gung-ho vocabulary that exacerbates bias. Also, developers will laugh at you behind your back.
• Mitigate the effects of unconscious bias by having diversity in your pool of technical interviewers.
• Coach everyone in your team on technical interviewing, and give them practice. It’s difficult to get right.

Hire across the experience range

It’s a tough, competitive market to be hiring in. I see companies looking to fill the same roles month after month. The pool of highly experienced developers is finite, and none of them are sitting on the bench waiting for your call.

Accept that you’re going to hire less experienced people, and be prepared to invest in them. Actually, scratch that – don’t accept it, celebrate it. Helping out the next generation of developers is a great thing – for your company, for your experienced developers who get to mentor them, and of course for those next-generation developers too.

Start looking into apprenticeships, coding academies, and new graduate entrants. I’ve seen new graduate entrants to development roles make astounding progress over 1-2 years from a standing start, given the right access to technical mentors.

As you do this, I recommend you take a good, hard look at your organisation and culture, and think about what you need to do to make it a supportive learning environment for teams with mixed levels of experience.

The best support for learning is through Communities Of Practice. This is a self-organising model that lets groups of people working in the same field share experience, support their colleagues, learn new things, and to form a view on what approaches work for their field or technology. Again, trust them, don’t manage them.

If you’re a technical manager, you should communicate that you support learning and mentoring in your organisation, and back those words with real commitment by building learning time into the working week. If the team isn’t already practicing pair programming, help them to start. It’s one of the most effective ways for new developers to get up to speed.

None of these things need to be part of a formal performance process, and none of them need any kind of coordination by a central learning team. They should happen spontaneously, continuously and organically in teams. Don’t kill the vibe by trying to manage it, but give people the time, space and support to learn.

For many organisations, these approaches represent a significant cultural shift, but it’s a good shift. If these ideas are new to you, think of them as the first step towards the culture of trust, empowerment and autonomy your company needs to thrive in the digital era.

• Hire developers at the start of their careers, and mentor and support them.
• Build a culture of learning in your organisation.
• Support this culture through dedicated learning time, and Communities of Practice.
• Trust people to learn in their teams and communities.

Your funnel’s broken

Most organisations implement something like this model in their hiring process, in an effort to reduce the pool of candidates by multiple stages of screening and selection. Typically, each of these steps is a binary outcome for each candidate: proceed, or don’t.

It’s quite industrialised, and a little impersonal…but I understand what drives it. You might see hiring as a time-consuming activity, and that it takes developers away from their “day jobs” to help with technical interviewing. A cost. An overhead. A burden.

But if the thing that’s preventing you from meeting your organisational goals is not having the right people, then this really is the problem you need to focus on. It takes time to select the right people to come and work in your team, but if you get the right approach, and get your developers interviewing candidates, it can scale up pretty well.

One final thought on this before we revisit in the next instalment. We tend to think of this funnel in a positive light: “we’re going forward with the candidates we’re most confident in”. What we think about a lot less is this fact: the vast majority of decisions we make about candidates are made when we know the least about them.

When we get to the second instalment in this series, we’ll cover screening techniques, and how we can keep the process as lean as possible, but also avoid missing out on potentially great candidates.

• Hiring the right people is going to take time, but there’s nothing more important for your organisation than the people you choose.
• Screen to keep the process moving, but take an holistic, balanced view of the candidate.

Communicate, but don’t specify

You don’t have to look far for terrible job specifications, and I won’t inflict any on you here. Most job specifications for developer roles are endless laundry-lists of technologies, frameworks, languages and platforms. They’re low-level specifications for machines, not people.

But some companies get this very right. Here’s an example of a recent open role from FanDuel for an entry-level mobile developer. Right at the head of the page, there’s this statement:

“We don’t want employees, we want player coaches – empowered to make their own decisions, learn from mistakes and execute what works.”

Excellent: an organisation that expects people to act, learn and adapt. They go on to describe the organisation, all good background. Next, they describe the role. I’ve chosen my words carefully here: they describe the role, they don’t specify it.

“What does an Entry Level Mobile Engineer do

You’ll learn to add features, change interactions, and fix bugs in our award winning apps. You will be working with your mentor, other engineers, designers and product owners, learning about and contributing at every stage of the of the product lifecycle, from research and discovery to iterative development, rollout and long-term maintenance.”

This is great. It gives a sense of the role, but also of the people and the overall team focus. And then, oh wow, this:

What you can expect

• A six-month training programme, tailored to your needs, to get you shipping code in our mobile apps.
• A mentor to help you find your way.
• An introduction to unit testing, pair programming, and tools such as Git.
• A supportive, trusting, and open work environment.
• Work on a variety of projects (though not all at the same time).
• Learn from others, and be a coach and mentor to other developers, irrespective of experience.
• 10% time to dedicate to personal projects.
• Regular hack days.
• A personal development budget for training and events and support and encouragement to submit talks if you want to.

Reader, I’m almost crying tears of joy at this point. They’ve managed to communicate their values and culture, as well as the specific ways that people are supported.

There’s more on that job page, but the message is very loud and very clear: “We are good people, making good things. We will support you, and you will help us to make great products. Come and work with us.”

You’re hiring in a tough market, and you need to communicate your understanding that this is a two-way street, and isn’t just about your requirements for what the candidate should have.

• Detailed job specifications are constraining, unappealing, and unrealistic things.
• Focus on describing what people do in your teams, what you make, your organisation, and its culture and values.
• Make it clear that you’ll do things to support the successful candidate, and that it’s not one-way traffic.

Plan ahead

Think up front about how you’re going to screen and interview. If you don’t, you’ll end up with candidates sitting pensively in reception, while you scrabble around upstairs trying to figure out how to run a tech interview. This is not a good look. You’ll give the impression of being lazy and amateurish, and that impression will be accurate.

The biggest risk in being unprepared is that time pressure forces you to use a last resort interview format. In most organisations, the last resort is a dog-eared, coffee-stained, grubby and mildewed handful of A4 sheets. Yes, it’s the “Technical Interview Question List”, and it’s probably older than some of your colleagues. Every organisation has one.

This is usually a museum exhibit of technical minutiae, corner cases and trick questions, deprecated APIs and obsolete “best practices”…and Q&A is one of the least effective ways to run a technical interview to begin with.

You’re better than that.

Make sure that you tell candidates what the process is. The format of technical interviews should never be a surprise to people. They shouldn’t even need to ask. Make it clear on your website, restate in any email communication, and invite people to email or call you if they need clarification on any part of the process.

Remember also that proportionality is important, and that you need to get technical interviewing right for the experience level of the candidate. If you’re specifically hiring early careers candidates for a role, putting these candidates into the exact same process you use for experienced candidates is not going to give you a fair view of their ability and potential.

You need to calibrate the difficulty level of challenges, and consider skipping or replacing some steps.

• Decide in advance what the right mix of interviews and screens is right for the role.
• Communicate to every candidate what these formats are. Invite questions.
• Make it proportionate for entry-level roles. A single, fixed process is not going to be appropriate across all levels.

Read Part 2

Most organisations find that they need to have some kind of screening stage. In the next instalment, we’re going to look different tech screening tools and techniques, and figure out how to get the best out of them, for both you and the candidate – now read Part 2.

Further Reading

I’ve referenced a few books in this post. I highly recommend Pete Goodliffe’s “Becoming a Better Programmer: A Handbook for People Who Care About Code” both to developers starting out, and also to experienced developers who are mentoring less experienced developers.

Emily Webber has written a great, concise book on “Building Successful Communities Of Practice” in organisations. She’s also a regular speaker on this subject, so don’t miss an opportunity to hear her talking.

Sandro Mancuso covers hiring in his excellent book “The Software Craftsman“. There’s much more to his book than hiring, though and I recommend it to everyone working in software development.

Mike Ritchie is a developer and technical coach. He helps teams with hands-on development, and builds technical capability through coaching. Find him on LinkedIn.

See also:

• How to hire a developer: Part 2 – Why screen candidates?
• How to hire a software developer: Part 3 – Online tech tests and alternatives
• How to hire a developer: Part 4 – Why in-person technical interviews still matter

Sign-up below to receive email alerts for the next instalment.

[contact-form-7 id=”4354″ title=”Employer blog email registration”]

More

Come to our next Meet your next digital hire event on 2 March in Edinburgh.

Follow us on LinkedIn and Twitter for the latest blog updates.

Find out more about becoming an employer partner with CodeClan.