Interviewing is one of the most important aspects of any developer's job. Your employer and colleagues decided to put their trust in your ability to identify their next hire, taking into account not only their technical skills and knowledge, but also their soft skills, their eagerness to help and to learn, and their fit within the existing organisation.

I have been on both sides of the desk, had great interviews and not so great ones, and I like to think I got pretty good at it. For this reason, if you are just starting out interviewing developers, or maybe you've been doing that for a while but would like new inputs, I decided to share some of what I learned.

Why would you listen to me? I've been interviewing developers since 2013, talking to dozens of candidates at companies such as King, Foxglove and Yager, writing job specs for various roles, and providing hiring decisions. At one point I helped King open their Berlin office, interviewing potential members of their initial dev team.

Understand how the candidate approaches problems

Engineering is a varied and ever changing sector. The tools you're using today may be out of date and forgotten in just a few years.

Rather than focusing on the specific knowledge of the relevant tech or engine you're currently using, you want to ask questions that reveal how the candidate solves problems, how they find relevant information and clear ambiguity, and how they learn and apply new skills and stay up to date.

The best engineers are the ones that are able to work with other disciplines (such as designers, production and QA), are curious and not afraid to learn and get their handy dirty with new tools and tech, and are confident enough to reply to your questions with "I don't know, but I can figure it out".

A good example for an open and interesting question would be:

Your team is working on an online shooter that is just entering production. The Game Director has asked you to define the backend and infrastructure architecture that will support the game throughout development and live release. On a high level, without needing to pick specific products, how would you design it and what paradigms would you follow?

Here, the candidate will likely come back with some questions to delve deeper into the scenario, such as whether there is a persistent world or short matches, or maybe they will ask how many players are expected in a single match, or whether there is a budget that would allow using Dedicated Servers. Maybe they will ask if the game is on a single platform or is expected to be on various consoles, if cross-play is expected, or if the company has infrastructure on-site or prefers to be in the cloud. All of these are valid questions that already highlights the candidate's ability to critically dissect a problem into its smaller components.

It's important to note there are no right or wrong answers here. Will they go with microservices, serverless, or maybe a monolith? Will they store the user data in a SQL or NoSQL database? Are they building the backend themselves, or using a BaaS? How secure is their solution? Will they push updates to the clients via a websocket? All of these approaches have their pro and cons, and the key aspect here will be the candidate's ability to explain their reasoning and compare the different options available.

To keep things interesting, you can expand the scenario further as the candidate works through it, adding more details and constraints to see how they adapt their proposal to the requirements.

Here's another example:

"You are the Lead engineer on a live game that's just been released. Things have been fairly stable and the infrastructure is holding off so far. On the first weekend, during your on-call shift, an alert is triggered and players are unable to login to the game. How would you approach this?"

This scenario based question covers various different aspects of working on a live game, including investigating common infrastructure scaling concepts, communicating with other team members, and keeping calm and working under time pressure on a game that's experiencing an outage.

One of the possible observations would be that during the weekend the CCU counter would be higher, as more people have time to play, so some components of the infrastructure may not be scaling as expected. Maybe the database needs one or more Read replicas? Is the backend autoscaling based on a metric? Are we hitting some quota limits on a specific service?

Avoid Trivia questions

At its core, engineering is about solving problems and figuring new things out. Asking very specific questions is not going to tell much of value about the candidate, except for their ability to memorise facts and stats.

Even the most experienced developer won't know everything, and by focusing on generic pieces of information the interview turns into a game of luck, rather than a deep dive into the candidate's experience and drive.

Some examples of trivia questions to avoid would be:

When using DynamoDB's Point-in-time recovery, what is the maximum time period in days that you can restore your table to? (35 days)

In AWS, what is the default quota of VPCs per Region? (5)

When using PlayFab, how many inventory requests per second are allowed per title user?

Put the candidate at ease

Attending an interview is not easy, and can be scary. Candidates will likely be stressed and under pressure, and there may a lot at stake for them.

As the interviewer, it is essential to maintain a friendly and comfortable atmosphere, to put them at ease and allow them to perform at their best. When the interview starts, introduce yourself, and invite them to do the same. Be friendly and smile.

Do not be harsh if they provide a wrong answer, or no answer. Very few candidates will be able to answer all the questions you throw at them correctly, and setting the wrong tone will likely worsen the outcome going forward.

End the interview with some lighter topics, such as discussing the project they would be working on (if possible), and allow some time for them to ask questions. Make sure to share details on the next steps, including when they can expect to hear back from the recruiting team.

Validate what you see on the CV

Some candidates will unfortunately lie about their experience and skillset. This happens rarely, and luckily it's fairly easy to spot by asking a few targeted questions here and there. There is no need to cover every piece of tech and tools mentioned in their CV, a small selection of those should suffice.

Here are a few examples:

You mention in your CV extensive experience with Terraform, could you briefly explain what the Terraform State is?

You seem to have extensive experience with C# and DotNet, could you explain what the Garbage collector is?

You are probably thinking those questions are too easy, and I would agree with you. On the other hand, they helped me detect more than one candidate that claimed to have multiple years of experience in those technologies, but were unable to answer them.

Go beyond technical aspects

Engineering is a social endeavour, which requires working in teams and collaborating with peers and other disciplines. For this reason, a significant part of the interview should be assessing Team and Culture fit.

Remember that, if everything goes well, you will be working with this person for the foreseeable future, and there is no amount of skill and knowledge that will replace being able to effectively communicate and collaborate within a team.

To assess this, you may want to ask about their experience mentoring other engineers (if applicable), or present a few scenarios where a problem is not inherently technical.

An example could be:

The project you're currently on is getting close to the first Beta test, and you've just finished implementing an important game system, the Skill Tree. During the following Playtesting session, the game designer is unimpressed with the current state, mentioning missing features. How would you approach this?

The candidate will need to delve deeper into what may have caused this misalignment. Was there a GDD in place? Was it kept up to date? Was there a joint Kick-off session before feature development started? Did the development team have frequent syncs with the design team to give status updates and iterate on it? All of these questions will allow them to pinpoint where the issue originated, and plan the necessary measures and safeguards to prevent this from happening again.

Respect their time

Tech tests are a large and often controversial topic that would warrant their own blog post. Whether or not you think they are necessary, asking your candidates to spend multiple days on a project will filter out those that already have a job, or with little spare time due to other commitments.

If you believe a test is necessary, make sure to keep it brief and focused, taking a few hours at most, and review the result together with the candidate to allow them to explain their approach and to understand their thinking.

In a similar way, avoid having an excessive amount of steps in your hiring process. Wearing out your candidate with a long string of interviews that often revolve around similar topics is a sure way to have them lose interest and drop out of the process. Instead, keep it concise, make sure the candidate meets team members from multiple disciplines, and avoid long intervals between each step.

Finally, ensure you share feedback in a timely manner between steps and at the end of the process, even when things did not turn out as they hoped.

I hope you have learned something valuable from this article, and will apply these tips in your next interview.

Please feel free to share feedback on this, and if you have any other suggestions I would love to hear them.