Company treats engineering applicants like human beings... you won't believe what happens next!

(spoilers: you build a talented, diverse team that works well together and all with a fun hiring process)

‍

Hiring is hard for any role, but there are certain jobs that are particularly tricky - software developers and engineers are definitely one of those groups (for a host of reasons!). At Applied we know how to hire and we build a tech product so… we’re pretty great at hiring developers. Here's how we do it:

Stage 0 - the philosophy behind it

Applied is based around the assessments that are shown to best predict workplace ability: work sample tests and structured interviews. If you haven't heard of work sample questions, they're exactly what it says on the tin - testing what candidates would do in real job situations. And so that makes total sense for developers.

It all starts with the skills that are important as a developer - at Applied we think these are:

Problem solving, Attention to detail, Collaboration, Technical architecture design and Empathy

Like this.... but with Hiring managers only wanting developers with great skills.

You might be thinking "but yeah so surely they need skills in Javascript, Node.js, React, Vue, AWS, SQL, Docker... (the list of things in our tech stack could go on but...). And don't get me wrong, those things are important but we don't believe they're the only thing core to a developer's job.

Stage 1 - work sample questions

We ask candidates to the engineering team 5 questions, each with a word limit on the answers of 250 words. Heres some of the things we ask (and more important why!):

One of the team has fallen behind and you think you’re going to miss a deadline…. What do you do?

‍With this question we want to understand how people collaborate and communicate - it’s a place where developers often cite standup or similar as a mechanism by which the whole team would know the progress of the work and then talk about updating the product owner (or any other stakeholders that would need to know). Some talk about rescoping or changing future plans to accommodate this.

It’s late on a Friday, you have these 5 tasks to do but you only have time for 2, which 2 and why?

‍Prioritisation is super important. We’re a company of 25 people (4 developers) supporting a large app and customer base, the list of things we want to do is vast and waaaaayyyyy longer than the time we actually have to do things (fun!). Seeing how people justify their choices is super interesting, understanding people's bias to action and focus on customers.

Here’s a broken function - fix it and then make changes such that you’d be happy to merge it

‍We don’t want to burden developers with a huge technical task at an early stage in the process (and also, getting someone to build an endpoint or a list with filtering in React doesn’t really tell us much) so we give them a small, but super useful one. It has layers of things that need sorting: fixing the code for a start, readability (it uses nested for loops with an if statement and pushes responses into an array), nomenclature and scoping.

As well as two other questions about passion for continuous learning in tech and motivation for working for us.

Now some of this is stuff I could get from a CV/covering letter (passion for learning and motivation... kind of), some I could try and infer (oh... they worked as a developer for 5 years, they can probably write code) but some of this I wouldn’t get to see until interview (if ever!) in a traditional hiring process. I'd also get a load of really bad things from a CV, years of experience and educational background are shown to only weakly correlate with actual job performance! Understanding how someone will work in the team and how they will react to very real situations is important.

All these answers and then chunked and randomised and then anonymously reviewed by a set of reviewers (you can read more about that process here). And this gives us a ranking we can work with. Here at Applied we tend to take the top 3-5 candidates through to interview…

Stage 2 - Interview

For devs we have a single interview stage (albeit consisting of a couple of interviews).

‍

Technical design - For this we take a task we’ve worked on recently or need to work on soon (most recently we used generating pdf reports for customers) and as a whole team, with the candidate, we design a solution together. Again this is about reflecting a real-world situation - we don’t make devs design solutions on whiteboards while the rest of the team stares at them stony faced so like… don’t make candidates do that! We encourage candidates to google things, to ask questions and together we explore things that are important in the tech design process (scalability, resilience, logging, testing etc etc).

Pair programming - So the review process gives us a good understanding of coding ability but it’s super important to understand how developers work together and how they approach a problem so we do a short pairing exercise (it’s important to add that every candidate should do the same exercise! Pull a branch down when you design the pairing task and use that one as a starting point).

Team skills - Continuing the theme of developers being way more than just machines for producing code we have a final, often super informal, interview step where candidates meet our founders, Rich and Kate, and delve slightly deeper into motivations (why do you want to work at Applied and why now), growth (what would you like to learn while at Applied) and other bits of values alignment. Then we have a section for questions - we give time for questions at each part of the interview but in this final bit we encourage candidates to grill us about the role, the company… whatever they want to know.

So... what does all this get you...

Well a team like this for a start...

‍

The process helps to uncover hidden talent, 60% of the people hired with Applied wouldn't have got a look in with an old-fashioned CV process (none of the developers here are Applied studied Computer science, nearly all of us have switched into development from other careers).

Higher success at interview round. In the last study we ran, companies needed to interview 1/3 as many candidates to hire compared to their old, CV-based process. Here at Applied we often have the really annoying situation where we end up hiring two people because they're both so talented (oh woe is us!).

A fair and inclusive process from end to end. This is what Applied was built for, every step of the way a bunch of biases are stripped out to help hiring managers concentrate on the stuff that matters (how well someone can do the job!). What does that mean? It means building teams with diversity in gender, ethnicity, background and experience.

A FUN (and informative) process! Candidates we reject tell us they had fun, they enjoyed the process, that they learned things and that the feedback they received from the platform has helped them in future job applications. We think that is pretty cool, on a more practical level it means the developer brand of the company improves (which means more people wanting to work with you!).

Want to know more about how Applied could help you build your Engineering team? Contact us here.