Creating a better technical interview for hiring great engineers

As engineers, we know that technical interviews can be nerve-wracking and sometimes feel very detached from real-world scenarios. How many of us have been in an interview thinking "I'd never do this in my day job"? Or perhaps being sat doing a 'pair programming' task, trying desperately to sort a binary tree with an interviewer who hasn't spoken for the past 20 minutes?

These sorts of scenarios are unrealistic, put candidates on edge which affects their performance and really turn interviewing into an inhumane process.

Instead of putting our future colleagues on the spot and making them uncomfortable, we should be doing better. Don't forget, the interview process is as much of a reflection on the company as it is the candidate. No one wants to work somewhere where they will be expected to perform to an unachievable level in unfair circumstances.

So, how can we do better?

Work out what you're actually looking for in a candidate

For some reason, often, when we write job descriptions and interview criteria, the requirements do not reflect what is required of a candidate in the job. Do we really care if they can solve complex equations or intricate Leetcode questions? The answer is probably not.

Here are some values we look for when we're interviewing candidates:

Technically proficient

We look for a baseline level of technical proficiency. This does NOT mean that the candidate is a 10x developer who is able to solve every problem under the sun with no mistakes. What this DOES mean is that they have a great foundational understanding of software engineering and a few years under their belt working with the main language on the job spec or at least similar languages.

Personable and good communication

After we know the candidate can code, the next thing we're looking for is whether they are friendly and can communicate well. This is a massively under-rated quality in the world of engineering. As an engineer, you will likely interface with many different stakeholders from different parts of a business. Building rapport with them and being able to communicate clearly and concisely is extremely helpful to a software team. It will improve the business' trust in the team and encourage open communication between engineering and the rest of the business. We've worked at many companies where this hasn't been the case and it has been a huge detriment to the entire company.

Makes mistakes in public

Someone who can make mistakes, take accountability for them and then move forward is someone we would like to work with. We all make mistakes (raise your hand if you have ever blown up the production environment at work 🙋‍♂️🙋‍♂️🙋‍♂️), however, owning it and raising it will help everyone work towards a resolution faster. Coupled with a blameless culture (no one should be made to feel guilty for making said mistake), teams can recover from disaster more quickly and learn from these issues.

Pragmatic

As much as we'd all like our code to be flawless and apply to every edge case, we also need to be realistic. If 99.99% of our users fit into one use-case, then that should be enough for our MVP. People who can apply nuance to potentially complex situations using the facts available to them are extremely valuable. They will be the people who ensure projects are delivered on time with the right amount of features.

These are just a few of the qualities we look at, but we like to think they provide a good North Star for our teams. It's a good idea to draw these sort of things up into a table or diagram so your team has a joint understanding of what you're looking for.

Use real world examples

When interviewing candidates, it's important to assess their ability to solve practical problems they might encounter in their everyday work. Instead of relying solely on theoretical questions or brain teasers, consider incorporating real-world examples into your interview process. While in some roles computer science knowledge is important, it's essential to strike a balance between theoretical concepts and practical skills. Focusing too heavily on CS questions might intimidate candidates and fail to reflect the actual work they'll be doing.

For instance, rather than asking candidates to explain the intricacies of binary trees or complex sorting algorithms, challenge them to build a small web application using their preferred stack. This approach not only tests their coding skills but also demonstrates their familiarity with popular frameworks and their ability to deliver tangible results

To add a touch of humour, you could even create fictional scenarios involving quirky characters or unusual situations. This not only lightens the mood but also tests the candidate's ability to think creatively and adapt to unexpected circumstances.

Pair program with the candidate

One effective way to assess an engineer's skills is through pair programming during the interview. This approach involves working collaboratively with the candidate on a coding task, allowing you to observe their problem-solving abilities, communication skills, and how they handle teamwork.

During the pair programming session, provide the candidate with a realistic problem or feature to implement. We prefer to use examples where candidates have to interact with a simple API via a frontend they build, with some data manipulation thrown in for good measure.

This is an opportunity for you to test the candidate's experience. However, it should not be seen as an opportunity to test how well they can remember all the obscure APIs across the web platform. Work with them, put them at ease, allow them to use a search engine to figure things out. This is supposed to be a simulation of a real working day, not a memory test.

Ask the candidate to talk you through something they built

Another effective way to gain insight into a engineer's skills and experience is by asking them to talk about a project they have worked on in the past. This approach allows the candidate to showcase their problem-solving abilities, decision-making process, and their overall understanding of the development lifecycle. As well as this, it will put the candidate at ease as they will be describing something that they are comfortable with.

Encourage them to provide a high-level overview as well as dive into specific technical details. This will help you assess their ability to communicate complex concepts clearly and concisely. As they describe their project, pay attention to how they discuss challenges they faced, the technologies they utilised, and the decisions they made during the development process.

Have a fair scoring criteria

To ensure fairness and objectivity in the interview process, establish a clear scoring criteria upfront. This criteria should be based on the skills and qualities you're looking for in an engineer, like the ones we spoke about earlier.

Consider breaking down the assessment into different categories, such as coding skills, problem-solving abilities, communication, and collaboration. Within each category, assign specific criteria and weightings to guide your evaluation process.

In summary, we believe that the key to creating a reliable technical interview is to try and simulate the reality of the actual role as much as possible. You can still challenge candidates technically without asking them to sort binary trees or make them solve other complex algorithms.

In addition to this, remember that technical ability is only one piece of the puzzle - someone who can communicate well and collaborate with others would be a huge asset to a engineering team, even if they require a bit of up-skilling in other areas.