Working with early stage developers

By Ben Summers

30 January 2017

At Haplo, we’ve built a really strong team of developers by hiring people who are early on in their career, and helping them learn within an environment which is deliberately set up to support them.

We’ve chosen to focus on early stage developers for two main reasons.

Firstly, we want to attract and retain the best developers, and we do this by offering something special that’s hard to find elsewhere: the best possible start to their career, in a team that will help them realise their potential.

And secondly, there’s a joy to working with people who continuously learn new things and push each other to be the best they can, and we want to work with those people.

However, it’s not as easy as just deciding to hire more “junior developers” . We build complex and high quality products for our clients, and to achieve that with people new to the profession requires deliberate action and care in everything you do.


We’ve designed a hiring process which tries to be blind to everything other than ability and empathy.

We test ability though a coding challenge which can be completed in a few hours, yet provides a lot of insight into the way the candidate thinks about coding, as it can be completed in many different ways. Our face-to-face interview then builds on this through an in-depth code review, and discussing in detail all the alternative ways it could have been written.

Empathy is more difficult. We’re looking for people who can imagine themselves in the place of everyone around them, whether that’s their users, their colleagues, or the wider community around our work. Often candidates show this by being excited about the potential of software to improve working lives, or a concern about diversity in the industry.


We emphasise the team’s achievements over individual contributions, and we consider mistakes to be mistakes made by the team as a whole.

This is to make sure we work in a completely blame-free environment, where bugs and mistakes are seen as a failure of process, and an opportunity to build tools and processes so they never happen again. It’s hard to learn if you’re defensive and afraid of getting things wrong.

That’s not to say we don’t value individual contributions, but we do that by acknowledging the impact of people’s work, and freely giving responsibility to those who want to lead.


We avoid rules and processes, as they tend to get in the way, and prevent us from experimenting with better ways of doing things.

The one process we really like is the code review. This serves two purposes. Firstly, it’s our main mechanism for allowing us to learn in safety, by picking up mistakes before they get to production, and we tweak our review guidance in response to anything we miss.

The second purpose is to teach software design through discussion. Our code reviews don’t just look for problems, they’re starting points for sharing and exploring ideas about writing software.


When you work with early stage developers, you have to be realistic about levels of experience, so your tooling should do everything it can to guide your team. If something needs to be done, and a computer could check it has been done, then the tools should perform that check.

The example I’m most excited about is our HTML templating language, HSVT. We deal with sensitive information, so security is very much a priority. Rather than rely on code reviews and testing, we created a language where all the common security flaws are syntax errors, and won’t even execute.


We arrange our work to make sure that everyone has exposure to every part of our products, and every part of the software development process.

This maximises the opportunities to learn. The best possible developers are generalist developers who know enough to work on anything, and have deep expertise in one particular area. When we identify an area where someone has a particular interest, we try and allocate work so they can develop this part of their knowledge alongside their generalist skills.

We make sure that everyone is doing interesting and meaningful work. When a new colleague joins, they get one day to re-write their interview coding challenge on our platform using our tools. On the next day, they’re straight into working on real and important projects, supported by their more experienced colleagues.


Software development is a marathon, not a sprint, and a workplace needs to be run thoughtfully to enable high quality work, consistently, over years.

Rather unusually, we have a fairly strict working day of 09:00 to 17:30 with a solid hour for lunch**. This is the easiest way we’ve found to make sure people don’t work too much. Burn out is a real danger, especially with people who have a real enthusiasm for their work.

Speaking of lunch, we generally eat lunch together. The company provides bread from our local baker, and we try and switch off and talk about things other than work.


Probably the most important thing we do is our “demo day”. After lunch on Friday afternoons, we all sit down and discuss our work. Usually, everyone brings at least one thing to demo day, and shows it on our big projector. This might be:

  • a cool thing you’ve made, to get some feedback,
  • some code you’ve written, which you think could be better and would like some ideas,
  • a mistake you’ve made, and you’d like to help others avoid it in the future,
  • some ideas on how we could work together better,
  • or a demonstration, perhaps of a new component that can save development time.

This is time consuming, and expensive, but totally worth it. There’s no better way to share ideas and improve your craft than to discuss your work with your peers.

One of my proudest moments at Haplo was a demo day where the majority of items were mistakes that had been made. A workplace where people are totally comfortable showing things they didn’t do well to the entire company, and get supportive and useful ideas on how we could avoid it as a team, is a healthy place to spend your day.


We’ve totally committed to building a learning environment as a fundamental part of our company strategy. This isn’t just because we want to hire people early in their development careers. The benefits extend beyond that, by creating a good place to work that produces quality code.

And yes, we’re hiring.

Ben Summers
Technical Director, Haplo

* I use the description “early stage developer” as I’m uncomfortable with the “junior developer” job title. We’re all mature professionals who’ve put a lot of effort into getting into this industry. My compromise is to use it on job adverts to prevent people filtering themselves out unnecessarily, but once you’ve joined, your job title is “Developer”.

** Obviously we’re flexible for the odd times when your train is late or you’ve got an errand to run. We’d just like everyone to keep roughly the same schedule.