We're Hiring!

How we interview and hire

Don’t be normal

We do not use recruitment firms. In our opinion recruitment is an ideal marketplace to be thoroughly disrupted by software. There, we said it, and possibly made a couple of enemies in doing so.

Joking aside, hiring is a game of relationships and reputation. The best recommendations come from your existing network. After that, they come serendipitously; a meeting at a conference, a chance friend-of-a-friend encounter, or someone you meet unexpectedly. The point is that usually, the best hires come from places you do not expect.

When recruiting, we cover a very large area: Western Europe, Western Russia, North and South America. This enables us to recruit from a large talent pool. We then make sure that teams are comprised of members in overlapping time zones. As a result, tasks where team members need to collaborate are not negatively impacted, helping with team morale and velocity.

If you only look for someone at the exact moment you need them, you are confining yourself to a very narrow time slot and only the people who are looking for work right now. You must then concede to traditional methods of recruitment like paid job ads and recruiters.

So, our approach is to always be open to new hires. We are not always able to hire, but we try and be pragmatic about it and try to treat hiring in the same we treat looking for customers - as an ongoing process.

The larger your exposure, the larger the chance you bump into a good hire. Conferences, events, talks, and meetup groups are all great network multipliers. Also, a common mistake is to try and scope these just to the tech industry. As is the way with serendipity, you may meet the next great hire at a photography meetup rather than a programming meetup.

We try and look for ‘T-shaped people’. It is a silly term - but it basically means people who are great at one thing but also familiar and experienced with a whole bunch of other stuff.

In practical terms that means developers who are also well versed in all the other areas our business extends into.

Interviewing Engineers

Our hiring and interview process for engineers can be broken down into 6 steps:

  1. CV, portfolio and presence evaluation
  2. Initial exploration emails
  3. Phone call & coding project task
  4. Video conference technical interview
  5. References and checks
  6. Founders interview

We spread responsibility for each step over several team members, and use a fixed scoring method at each step to build an overall candidate score. We try to keep our pipeline somewhat asynchronous, so steps may happen in different orders or even overlap.

If a candidate is looking strong then we try to get them to interact with our teams as much as possible as they go through the later steps.

1) CV, portfolio and presence evaluation

We evaluate all applicants in the following key 4 areas, scoring each internal quality from 0-2:


Weighting Quality
2 Candidate writes in a clear and concise way
1 Demonstrable spoken English (online videos)

Disqualifying features:

  • Too energy consuming to read
  • Likely that they could not interact with a customer or other team members fluently
  • Spelling and grammar issues


Weighting Quality
1 Level of seniority achieved in their field
1 Active contributor on sites like Stackoverflow
1 Github sample codes (Open source or otherwise)
2 Quality of company apps
1 Quality of personal apps
2 Prior companies worked at techincal standing

Disqualifying features:

  • No relevant experience
  • Only worked on their own project(s)
  • Code samples are low quality, or poorly documented
  • Apps are low quality

Education & Skills

Weighting Quality
2 Quality of academic institutions
1 Progressive approach to learning new skills

Disqualifying features:

  • Technical skills only acquired after attending a coding workshop

Leadership & team

Weighting Quality
2 Teaching experience
1 Talks at conferences
1 Created online courses
1 Actively maintains a blog (or similar)
1 Trained others in previous roles
1 Time spent leading a team
1 Contributes to open source projects

Disqualifying features:

  • None

These metrics are all recorded in a spreadsheet. A final score out of 100 is automatically calculated taking into account the various weightings. If any of the ‘disqualifying features’ are present then the candidate isn’t scored.

2) Initial exploration emails

We always have a set of criteria we are looking for at a high level. Correct level of experience, salary expectations, location, availability, and interpersonal skills all rank highly. These vary in importance depending upon the position. We don’t measure this step in the same score driven way we do the first step - we go largely on gut and how interactions go.

3) Phone call & coding project task

For each language and position, we have designed a small coding test that should take around one hour to complete. These are very lightly specified, and designed to test several things:

  • Interpretation of requests and specifications
  • Overall approach to a problem
  • Quality and readability of code
  • Consideration of potential future issues or requirements

We always accompany these tests with a quick phone call so the candidate can ask any questions, and to give a quick reassurance that getting to this point means they are in consideration for the position. These calls generally only last a few minutes.

4) Video conference interview

These are highly informal in their flow and generally last less than 45 minutes. There will usually be 2-3 relevant people passively listening in and evaluating, with one person leading.

The first part of the interview follows a set of questions constructed around building a very simple theoretical application. The questions are not technically difficult at all and many candidates are surprised at how ‘programmatically simple’ this step interview can be.

However, we are really trying to assess how the candidate approaches the questions in terms of rational thinking and key skills. It is surprising how many experienced programmers will overlook very simple fundamentals when answering these questions.

The second part of the interview moves onto more general knowledge. This tests more computer science theory if relevant, and takes a broader language-agnostic approach.

The third part deals with tooling and team workflow.

The final part of the interview focuses on coding problems and algorithms.

We assess how they respond to being challenged and to being pushed to explain their answer to a seemingly very simple question in greater and greater detail. This reveals the depth of their knowledge and understanding. This process involves asking ‘but why’ over and over when starting with a seemingly simple answer.

Depending on the specific role, and how the candidate is doing various steps may be extended or skipped.

5) References and checks

We use a third-party service to check key details of applications such as references, employment history and education.

6) Founders interview

The final step of every hire is an informal chat with the Purepoint founders. This is mainly to get to know the candidate, evaluate cultural fit and talk through expectations, questions, and reservations openly.

‘Developing’ is only a part of the job engineers do daily. Time management, planning, team interactions, balancing priorities and managing customer relations are all hugely important. So, we try to get a good feel for all those qualities during this final step.

The candidate will get a final score out of 20. We do not simply pick the candidate with the highest score. We also evaluate notes and talk through the hire with everyone involved.

When we have selected a candidate, we present them an offer. We also reply to all other candidates with an explanation of exactly why they did not get hired. We give more detailed feedback depending on how far along the process they got. We think this is an incredibly important step as it reflects on your attitudes towards staff as a company and often the people who narrowly did not make the position may in fact be ideal for another position further down the line.

Interviewing other positions

When recruiting positions outside of engineering the flow looks very similar to the engineering flow. We just change out parts of the process.  Because we hire outside of engineering less frequently we tend to design each process per-hire and then vary it from role to role.

QCon London

QCon London is a conference for senior software engineers and architects on the patterns, practices, and use cases leveraged by the world’s most innovative.

March 4-6, 2019 Find out more