Does one good developer equal 3 mediocre ones? No.

Does one good developer equal 3 mediocre ones? No.

Great developers are far more valuable. Know how to identify real talent and you'll reap the rewards long term. 

 

As the head of a talented software engineering team, part of my job is hiring (and firing) developers. After many years and many mistakes, I feel like I can now confidently spot people who will make a positive contribution to our team. Knowing how to spot this talent, and having the patience to wait until you do is vital to building a strong development team.

A bad hire can have a massive detrimental effect on the quality of work your team produces and leave you cleaning up the mess months or years after they're gone - the impact isn't immediately obvious but can be disastrous. Conversely, having a great developer on the team increases trust in a successful outcome, builds confidence that things will be done right, and makes day-to-day work a far more positive experience.

So how can you make sure that you hire the right people?

Test them

Let's get core skills out of the way first - a new hire needs to be competent in the skill-sets you require. Don't even talk to them until they have passed a sit-at-home test or provided some sample code that amply demonstrates their ability and that they are proud of. Get team members to review that code. CVs are far less useful than a good code sample at this stage.

Test them again

Arrange a pair programming test with a developer on your team; something that should demonstrate that they can think on their feet in a real world scenario. Let them look stuff up and work as they would if they were really building something. Ideally this should be done face-to-face, but if they are remote, there are some great tools to enable virtual pair programming (https://c9.io/).

Interview them in person

Providing they pass both previous stages with flying colours, and their code-writing competence is assured, it's vital to ascertain some key information about the candidate face to face.

  • Are they actually smart? Hopefully this has already been answered in the code tests, but good code doesn't always equal a smart approach to work. Does the candidate come across as clever? Hopefully very clever. Ideally a lot cleverer than you are.
  • Are they a specialist? Does the candidate code for fun? Do they go to hackathons, do online courses, keep up to date with the technology? Good candidates should live and breathe code. Is their career aspiration to become the best developer they can be? If they tell you that in 5 years they hope to move into management, the interview should be over. Great developers need to code; it's in their DNA.
  • Are they proactive? Will they go and fix something because they can see it needs fixing, before being told to do it? Great developers can't sleep at night because they are thinking about something that needs to be fixed. More often than not they'll pull out a laptop and fix it at 3am because it's bugging them so much.
  • Are they pragmatic? Do they understand that sometimes the business case for a feature is more important than designing a purist developer-centric solution? Can they justify doing something "Good enough for now" to meet a business need, while fighting for it to be improved in the future, when appropriate?
  • Are they collaborative? Great developers realize they are stronger in a team - individuals who can churn out amazing code but can't work with others are not great developers; they may have their uses in some circumstances, but they will never get a place in my team. Every hire has to make the team stronger and more cohesive. 

When you end the interview, you should be confident enough that you would hire them on the spot. If in any doubt, about ANY of the points above, it should be a no. This process takes time; great developers are pretty rare, but it is worth the effort to keep on testing, interviewing and rejecting until you find someone who stands out.

Finally, think long and hard about hiring juniors and training them up if you are trying to grow a core team to increase output quickly. Unless your organisation has the spare capacity to factor in mentoring by seniors, and has short term 'throw away' projects you can let juniors cut their teeth on, in general it's dangerous to think you can increase output cheaply by hiring junior developers without much business experience. The reality is you'll probably achieve less for a long time, as experienced resource is sapped by training, code reviews, rewriting their code so it scales properly or is secure enough, etc.

The bottom line is a single great developer will output more, and at better quality, than any number of mediocre developers, and this long term consideration of your product development is far more important than pushing out a load of buggy code to meet the need for new features which haven't been properly considered, fail under load, cause your clients to complain, and inevitably have to be rewritten.

To view or add a comment, sign in

More articles by 👥 Ian M.

  • I don’t believe in a work life balance.

    You’ll hear it everywhere: companies telling you how they encourage it, or blogs by successful people talking about how…

    1 Comment
  • Overcoming Manager Imposter syndrome

    Your team is doing well - you’re hitting deadlines, you’re proud of your team, they are churning out the work, working…

  • Avoiding the Roadmap Triangle of Shame

    All too often software engineering roadmaps are ill-conceived and badly planned, yet still get treated like gospel…

    4 Comments

Others also viewed

Explore content categories