On the importance of a good Interviewing Philosophy

Photo by Tim Mossholder on Unsplash

*Record Scratch* *Freeze Frame*

Yep, that’s me. You’re probably wondering how I got into this situation…

Interviewing is something I’ve always loved doing. But because I mainly worked at startups for most of my career I was never exposed to the volume of interviews you get to have in big companies.

Then I joined GfK.

I remember at a meeting someone mentioned they needed help with interviews, the company was moving into an aggressive growth plan (we went from being 25 people in the project by the time I joined, to around 130 at its peak) and they didn’t have many people who wanted to run interviews or that had the right training.

This was my “get your foot in the door” moment. I raised my hand and shortly after I was attending a minimum of 2 interviews a day! We also needed to come up with a new technical test for Full Stack Engineers so I got to work on that too. Exciting times!

During that time I learnt a lot from working with a very skilled team and great leaders, like Andy Howell. Very quickly I started leading more and more interviews. But we all realised that the pace of interviewing wasn’t sustainable nor scalable.

Shortly after, Jared Mooring, one of the best mentors I’ve ever had, joined as Head of Engineering Practice. So, with his support I got started working on formalising an official “Interview Philosophy”.

This wasn’t just for Full Stack Engineers anymore, it now applied to the whole engineering organisation.

It would be a comprehensive set of principles and standards on how to run interviews, with a framework for consistent evaluation of candidates as well as tools to help interviewers provide rich feedback, which in turn we’d provide to recruiters to also help make their work easier.

Ok now let’s move on to what you actually came here for.

Context

Just as the financial market cycles between Bull and Bear markets, the job market fluctuates between Candidate and Employer-led markets.

When I designed the interviewing philosophy for hiring Software Engineers at GfK we were going through The Great Resignation. It was a Candidate’s market.

I’m writing this in 2025. We’re on the other side of the global recession that came after the pandemic. And we’re definitely in an Employer’s market.

In a Candidate’s market, companies need to move quickly. Because candidates usually have multiple processes ongoing and can quickly take an offer from another company if they don’t move quick enough. This merits an “expedited” recruiting process.

When on an Employer market, there’s a higher ratio of candidates to job openings. And companies can take the luxury of being extra selective and take some time coming back to candidates. Other factors affect this, like limited staff capacity to review the increased volume of applications.

Here’s a good article explaining Employer vs Candidate Market. And here’s one detailing Bull vs Bear Markets, in case you want to dig deeper into my analogy.

Both Employer and Candidate Markets have their negatives as well.

In an Employer’s market, candidates are the main affected. Some companies become a bit lax and can lower their standards in some aspects (like the quality of the interviews) as well as taking things to extremes in others, like arbitrarily adding extra stages once candidates are already engaged in the process or not being respectful to candidates. Making the process of finding a job very excruciating to candidates.

In a Candidate’s Market, on the other hand, existing company employees can be affected, as some companies lower their standards in order to get butts in seats, they end up hiring people who are not good at their job or that can be toxic and hurt the existing company culture.

I hope this served as a good introduction and helped set the background for this article. Because this is a long one, I’ve split it into 4 sections and numbered them to make it easier for you to read.

A clarification on Recruiting vs Interviewing

Before jumping in:

This article will only focus on the interviewing process itself and not on the recruiting steps that happen before (like recruiter leads, CV reviews, etc) or after interviews (negotiating salary, start dates, onboarding, etc). As I can’t speak for recruiters and that would merit its own separate article by itself.

Now let’s dig deeper into some aspects I believe should be a constant regardless of in which cycle the job market is at at any given time.

1. Philosophy

This is not the original philosophy I designed at my previous job. While writing this article, I realized I’ve learnt a lot since then, so this is an updated, extended version of what is my very personal view on what a great philosophy should have and what it should look like.

What makes a good interviewing philosophy?

In my view it’s one that focuses on creating a positive interview environment for the candidate and interviewers, where interviewers get enough training and support to do a great job at it and don’t dread it or see attending an interview as a chore.

Where candidates are provided with a conducive environment where they are able to showcase their skills and knowledge. In such a way that they feel satisfied after they hang up from the call.

Regardless of whether they passed or failed the test, ideally they should walk away from it feeling like they’ve done something productive or they have learnt something new. They shouldn’t feel dread, or like the interview was a waste of their time.

Very important as well is that there’s a system to help interviewers ensure candidates are evaluated in a fair, equal and consistent way, while keeping it organic. i.e. It doesn’t feel like it’s just ticking items off a checklist.

And finally, something that’s historically been lacking in interview processes: Rich and accurate feedback. This helps candidates and even recruiters immensely.

Making it easier to communicate and understand results of the interview, what was evaluated and even potentially what was missed/couldn’t gather enough meaningful signals to evaluate.

Some people even go the extra mile providing suggestions on what to improve/focus on for candidates that are rejected.

This is very commendable as not every candidate takes this kind of feedback well, and it takes the interviewers a lot of time and energy to frame the suggestions in the best way possible.

(To all the interviewers that still do that, hats off to you!)

Why even define a philosophy?

Maybe at this point you’re thinking:

“I trust my engineers will know how to interview another person. I hired most of them myself!”

Yes, it’s very likely your engineers are great engineers and know their tech stack, design principles, patterns, multiple paradigms and even can build their own compiler from the ground up. But have you given them the tools to do a great job at being interviewers?

Are they good communicators? Are they good at picking up verbal and non-verbal cues? Do they have any unconscious bias they need to be mindful of? Do they have the tools to be consistent at evaluating multiple candidates for a given role?

We need to keep in mind there’s a reason why the stereotype of us engineers being shy and introverted exists. We are typically not attracted to activities involving interaction with strangers or big groups of people. Even if we’re being paid for it (think standups, refinement sessions, etc).

On top of this, we don’t usually get training at work to help us improve our skills for effectively communicating and dealing with other people. Usually it’s down to us to consume books or other content to help us improve on those aspects.

The purpose of defining a philosophy is that it helps build and maintain a system that sustains itself. Where people that are part of it learn and grow, and as they gain mastery they contribute back to it, improving it and helping it grow as well.

In the case of interviewing I think it’s particularly important for engineers and helps take the stigma out of an activity that we usually don’t relate to a good or comfortable experience.

Think about it:

• As a candidate. What’s the ratio of bad interviews vs good interviews you’ve had on any given job hunt?
• As an interviewer. (Hopefully it got better after a while but) didn’t it feel like a chore the first couple of times your manager asked you to attend or run an interview?

And there’s the hidden benefit that as you become a better interviewer you also become more comfortable being a candidate, as you’ve now sat at the other side of the table and have a better understanding of what your interviewer is looking for.

In recent years this has improved greatly, as companies and people started paying more attention to these aspects and put more effort in spreading information and training staff on the so-called “soft” skills, like Communication, Emotional Intelligence, Conflict Management, etc.

Principles

Let’s define some core principles our interviewing philosophy should fulfil:

• Have a positive impact on everyone involved.
• Provide candidates with a space to showcase their knowledge and skills.
• Gather strong signals.
• Be able to spot red flags.
• Be flexible.
• Make efficient use of everyone’s time.
• Have a healthy and ethical culture.
• Remove bias and ensure consistency.

2. Important Factors

Now that we have our principles set, in order to uphold them we need to focus on a number of key factors such as:

Parameters and expectations

One of the most important factors of an interviewing philosophy is its capacity to deliver. In this case what we’re expected to deliver are candidates that fulfil the role’s responsibilities.

A great job spec can have a major impact in finding candidates that fit the bill. Details like seniority, tech stack, leadership responsibilities, soft skills and sometimes also industry background are some of the parameters we need.

Expectations are usually also in the job spec, and are the definition of the day to day responsibilities. Like “Coach and mentor members of the team” or “Participate in incident management”. This helps recruiters and interviewers know what they need to look for and evaluate.

Once we have that we can move on to the other aspects like setting up the right Environment.

Environment

In order for interviews to be effective we need to ensure we create the right environment and atmosphere where the candidate feels comfortable and can give us the best version of themselves.

Where the rules of the game are clearly defined and they don’t need to be constantly looking for unexpected gotchas.

It needs to feel like a safe environment, where they can ask for clarifications or say they don’t know the answer to something without feeling penalised for that. Giving them room to make their own decisions and showcase their knowledge and skills.

Where the tests and tools are clear and helpful instead of feeling like a hindrance or a mine field they need to navigate very carefully.

With interviewers being trustable, helpful, and good communicators. Without giving them the solutions to the problems but giving them a gentle nudge in the right direction when needed. After all, they’re interviewing their potential soon-to-be colleagues and this is a dry-run of what their day to day could look like.

Now, in order to be able to create the correct interview environment we usually need to have a healthy work environment. And one of the most important aspects of it is Culture.

Culture

Interviews are a crucial instrument both to determine if a candidate would be a culture fit. And they’re also a great opportunity to showcase what your company’s culture is like to candidates.

This has proven to be a major factor in employee retention, just as important as a good salary or a clear career progression path.

What does a good culture look like?

So, first let’s quickly describe what a good culture can look like. (I won’t go into much detail because this could easily turn into its own standalone article).

I believe that an ideal culture should easily be compatible with this quote:

“Train people well enough so they can leave, treat them well enough so they choose not to.”

Richard Branson

Here are some essential values and principles I believe a healthy culture needs to fulfil:

• Trust and Dependability. Team members must be able to count on each other to do high-quality work.
• Accountability. The other side of the coin with Trust. Team members must be able to provide honest feedback and hold each other accountable. This is not the same as pointing fingers and requires a certain level of maturity to be reached.
• Communication. Leaders and team members must be able to communicate effectively to perform highly coordinated work.
• Motivation. Team members should be doing challenging and meaningful work, keeping them engaged, tapping into their potential and nurturing their growth. Leaders should work to ensure the best conditions in order for this to be sustained.
• Identity. Having a shared purpose and set of values as well as a unique style of work and communication helps build a sense of belonging and is also an important factor in employee happiness and retention. Little things like tweaking Ways of Working or choosing their own team name go a long way.

Effective Communication

Good communication is key in running great interviews. And one way of ensuring great communication is to keep a conversational style.

Conversational Communication. One of the worst things we can do as interviewers is to make the candidate feel like they’re in a police interrogation. This is 2 parties sitting across a table, but having negotiation of equal standing.

The interviewers are representing a company that’s looking for someone who provides a service, and the candidate is a provider who offers said service. We are just evaluating if they can fulfil said service to our expectations.

And although we have defined a number of tests to validate that, much of the conversation happens verbally. And in order for the conversation to flow we need to be able to create different avenues of conversation with the candidate.

This will allow us to formulate the right questions to dig deeper into their experience and them to showcase their skill and knowledge.

Candidate Priming. It’s very important to get the candidate in the right state of mind at the start of the interview. Spending some time introducing ourselves and letting them do the same is going to help a lot, as it allows everyone to set a baseline of who they’re talking to and calibrate their style of communication to the audience.

This is also the right time to provide a brief overview of the interview structure and how we expect it to unfold, making sure everyone is aligned on steps and expectations.

Ask Better Questions. Asking better questions is a greatly undervalued skill and it’s intrinsically linked with empathy as it can both help us gain insights into other people’s minds as well as make work easier.

Regarding which questions. This varies, and we’ll go into more detail on them later. Another important thing to remember is that we’re not the only ones asking questions. Listen to them and allow them to ask questions or for clarifications as well.

Remember that communication is also non-verbal, and paying attention to those cues from the candidate, as well as ensuring we communicate the right ones can help make the interview conducive to better results. And on that topic:

Know when it’s better to take a short break. If the candidate gets nervous it would be better to pause for a couple of minutes and let them go grab a glass of water and stretch their legs than push ahead and bomb the interview.

This one is very important, especially if the interview has gone off the rails or hit a wall for some reason. Some people can get very nervous, maybe they’ve had a bad day, haven’t slept well, had some family emergency or something similar.

Don’t make it about yourself. The other cardinal sin an interviewer can commit, worse than turning the interview into a police interrogation, is to make the interview about themselves, grandstanding about how much they know about something, without caring about the candidate at all.

I’ve been in interviews where the interviewers didn’t have any interest in gauging how much I knew about a topic or to have a conversation. They only asked very obscure questions they knew the answer to, and only waited for me to finish my answers so they could talk about how much they knew about the subject.

Granted. These kinds of people shouldn’t be running interviews at all, or should have gotten better training beforehand. But… just don’t be that person.

And on that note, let’s talk about Capable staff.

3. Capable Staff

Having the right people and training them well is the key to getting this all working together. Interviewing is a skill on its own. And as I mentioned before not everyone is good at it.

This means we need to have a process or framework in place to train our people. Later on we’ll discuss how to structure the interview stages and provide feedback. But for all of that you need capable staff.

You might be able to design a couple interviews and technical tests. But the goal here is to make yourself dispensable. You should only be needed to set things in motion and then get out of the way and let your team take care of it. While still having regular check-ups with them and giving them some steering of course.

If done properly it’ll then become a self-sustaining thing. With the technical tests evolving as your interviewers evolve and as technology moves forward.

The new React Compiler is out of beta? FastAPI finally hit v1? Your interviewers will be the ones to let you know, and the ones who’ll open the Pull Request to the technical test repo to make the upgrades.

A specific tech test feature is not relevant anymore? Equally, they’ll be the first ones to raise it with you and propose a new feature to evaluate.

Some questions from the pool out of date? They’ll be the ones proposing new ones.

What do you need to do in exchange? Make sure they have the tools, capacitation and the room to operate to do it.

Which tools do we need?

Question Pools. These are very useful, especially for people who are getting started at interviewing. Helping them get a better sense of the line of questioning to follow.

We can define separate pools for any kind of Technical, Behavioural or Career questions us or our team deem relevant. And the answers only need to outline what a good answer from the candidate looks like. No need to replicate wikipedia. It just needs to be a reference for them during interviews.

Scoring Matrix or Hiring Rubric.This is like a spreadsheet that the interviewers can use to grade candidates on a number of skills or other job-relevant aspects, helping ensure consistency and removing bias.

Here are some useful links with more details:

• Interview Rubrics: Definition, Templates and Examples
• How to create an interview rubric that actually works — LeadDev

Interviewer Notes. These are guides us managers put together with our team. They make it clear how to run the interview and what to focus on, as well as pointing interviewers to the relevant resources they need, like question pool documents, location of technical tests, feedback templates, etc.

In the case of the technical tests they clearly outline what the test was designed to evaluate in candidates. Listing intentional blanks or ambiguities left for the candidate to fill in the process, as well as what to expect the candidate to do and pointers to how much we can help them.

An example could be:

Our “Rocketship” Front End technical test is focused on evaluating the candidate’s RESTful and React skills. You’re expected to run it as a pair-programming exercise and ask the candidate to treat you like if you were junior engineers working with them on this piece of work. We expect them to explain their plan as they go along. Of course when they ask for clarification or hit a wall you can quickly revert to being an interviewer. The idea is to evaluate their communication skills with their peers.

This test has a number of requirements asking them to deliver a new endpoint and connect it to a React dropdown input. Deliberate mistakes have been made in the signatures of methods X and Y. They might get stuck on method Z that handles serialisation, this is not using a standard method so you could let them know they can fully replace it with a util as long as the test for the method stays green.

Tests are passing but because they’re not really testing anything, we expect the candidate to notice that and point it out. If they fail to do so, you can point them to it near the end and ask them which kind of tests they’d write in there to fix that if they had some extra time.

Remember to always run a retro at the end of the test asking candidates what they’d do differently if they had the chance to do it all over again with their newly gained knowledge.

Candidate Feedback Templates. This has proven to be a massive time saver and incredible tool for ensuring consistency when evaluating multiple candidates for the same role.

Some things we’d include in these documents are:

• Questions we asked and outline of answers we got
• Technical questions.
• Behavioural questions.
• Notes on technical test.
• How well prepared they were (git already set up, IDE of choice ready, etc).
• Decisions they took during implementation.
• Attitude towards interviewers.
• Positives and Negatives of their approach to problem-solving, communication and implementation of solution (no expectation of them completing 100%)
• Notes on conversational aspects.
• Relevant career roles.
• Highlights on previous experience.
• Ability to structure and communicate opinions.

We’d also had some kind of letter template with blanks to fill in with the relevant information above and pass it along to recruiters. Giving them a consistent source of information for them to take the feedback to candidates, giving them discretion on what to share.

As I mentioned before, some interviewers go the extra mile and provide suggestions on what to improve/focus on for candidates that are rejected. We’d usually have a section for that in our template as well, but would leave it entirely to the interviewing team to decide if they want to provide such feedback, with help from the manager on making sure it comes across in a constructive tone.

On the same subject. I recently saw this LinkedIn post from Craig Turner, hands down one of the best recruiters I’ve ever worked with, who added this postscript to his team’s feedback emails to candidates:

“P.s. we are only human, if you feel we could have done something better or we have missed something please let us know! 🙏”

And I think it’s genius! Us interviewers and recruiters don’t always get it right and miss things. And it’s always your right as a candidate to also provide feedback on our feedback.

I’ve had a couple of cases where we had an extra call with some candidates when we both agreed we missed something and could do an extended round to re-assess.

Training your interviewing staff

Now that we have all these tools it’s your job as a manager to train your staff. You can do this in multiple ways:

Lead by example. Take them to interviews that you’ll lead (or other engineers who you think are great interviewers already). And have them sit back and take notes.

• (Do ask candidates in advance if they’re okay with an extra person sitting in).
• Compare notes afterwards with your staff to clarify expectations.

Have them take the test. Specific to technical tests. Have mock interviews where they need to take the test themselves.

• This will help them get a better understanding of the flow and tasks in the test.
• Helping them recognise key parts of the tests and also when they might need to prod candidates in case they start to stray too far from the road.
• You won’t always have interviewers who are experts in the language of a given test, but these mocks can help them familiarise better with them and provide support to the main interviewer as needed.

Drill them through the tools. None of the tools mentioned above will be of any help if your interviewers don’t use them.

• Have sessions with them where you discuss the purpose of the tools and teach them how to use them.
• Gather feedback from them on how to make the tools more useful for them.
• Apply the feedback and give them freedom to always propose modifications.
• (You might think your template is great, but if it’s slowing them down and they don’t use it. What’s the point?).

Use debrief for calibration. When having your debrief sessions after interviewing candidates, make sure to ask and look for signals about the tools and tests still being relevant and effective.

This is an ongoing process, just as people join and leave companies you’ll also have people leaving and joining your interviewing staff. And fresh perspectives will help keep everything fresh and relevant.

You don’t need to be doing everything yourself, as I mentioned above, you can share these tasks with your experienced engineers.

Taking the right (amount of) people to the interviews

Ok, so you’ve created tools, tests and other resources. You’ve trained your people. You’ve started screening CVs. Now it’s time to start running interviews. Who should you take? And how many of them?

There are a couple aspects we could take into consideration:

Bring the right people. You always need at least 1 senior interviewer to lead the interview (they don’t have to be a Senior Engineer, just have enough interviewing experience to lead) and as many more interviewers as you decide appropriate. They could have less seniority and, if they’ll have an active role, ideally a good chemistry with the lead interviewer.

Bring the smallest amount of people possible. No one likes to join an interview and suddenly have a panel of faces looking at them. So ideally you want to bring the smallest amount of people to an interview.

I’ve found that 2 interviewers for any given stage are good enough. It’s an efficient use of your engineering staff and not too many faces and voices making the candidate nervous.

On that note. It doesn’t matter if their camera is on or not. Actually, being in an interview with people who have their mics muted and camera off can be very off putting.

I made it a rule in my interviews to not do that. Except for very particular occasions when people we reported to wanted to sit in and observe our interview process. Letting the candidate know in advance.

Define a flow and roles. You don’t want your interviewers to create an awkward flow, speaking over the candidate or each other. Having different ideas in their head about the direction in which they want to take the interview.

In order to do this you need to define clear roles for them. This should be part of the “Interviewer Notes” I mentioned before.

As an example, sticking to my particular preference is having 2 interviewers. My preferred flow is to treat it like if it was a football game. Where one of them takes the role of the narrator and the other one is the commentator. If football is not your thing here’s a quick definition of both (thanks Gemini!):

• Narrator: Describes the live action on the field in real-time. Think of them as the “play-by-play” voice, announcing goals, fouls, substitutions, etc.
• Commentator: Provides analysis and insights into the game. They might discuss player strategies, team tactics, historical context, and offer opinions on the match’s unfolding events.

Now adapted to our technical interview model:

• Narrator: Lead interviewer, in constant conversation with the candidate. Answering their clarifications and helping them navigate the problem.
• Commentator: They take a more analytical role, are not always talking but to make specific questions or comments to the candidate. Like asking them to elaborate on why they took a given path on refactoring a method, or why they chose a given data type for a property.

Hopefully this is a helpful example and gives you an idea on what you need to do to define the flow and roles in your own interview design.

Leave limited room for biases. On that same note I’ve found 3 people is enough to ensure consistency in evaluating candidates. This being the manager plus the 2 interviewers.

I like to call this “triangulation” (yes, very original, I know). Here’s a couple reasons why it works so well:

• It’s an odd number. With 3 people there can’t be a tie between saying “Yes” or “No” to a candidate.
• Smallest representative sample. With 3 people you have the smallest representative sample of assessments.
• Redundancy. With 3 people there’s enough redundancy for one of them to catch what the other missed, or to have a different approach to asking a question.
• Double-blind. Not sure if this is the right term but if the manager ran only screening and the engineers ran only the tech test, they’re aggregating assessments from events they had no part in.

I’ve found satisfactory results using this format as it helps ensure consistency. Even if one of the interviewers had an off day and missed something the other 2 can help fill the gaps. The definition of rules also helps with this, as it helps ensure we’re covering multiple angles.

Reaching a decision

Ok, we have defined tools, a process for training interviewers and for deciding which and how many people to a given interview. Now how can we reach decisions on whether to hire or reject a given candidate?

I have a simple rule for this. To pick a candidate the whole interviewing team had to unanimously say “Yes”. Ultimately we’re a team and need to reach a decision as one.

There was no interference from the manager or anyone else. Except for very specific exceptions, such as the need for an extra interview session or a time-sensitive executive decision, we had autonomy.

If someone was still not convinced we had to keep debating until reaching an agreement. Using the data we gathered, with the tools we designed as well as comparing notes.

If we didn’t get to an agreement we could at least decide if the candidate was shortlisted or rejected and we’d keep interviewing.

Obviously you’d need to take into account response times. How long could you afford to keep hiring going? How long could you keep candidates you already interviewed waiting if they were in the shortlist but we still weren’t 100% sure?

But that would depend on your particular process, needs and timelines.

Now that we’ve defined the most important factors and a clear process for capacitating people and reaching hiring decisions. We can focus on structuring the stages.

4. Interview Process Structure

Role and Seniority are the main differentiators in the structure you decide to put in place. Junior interviews will usually have a single technical stage. Where Senior and above may have separate Coding and System Design stages..

Some Leadership roles might replace Coding with Behavioural or Leadership stages. And so on.

The important thing is to keep in mind everything we’ve defined above regardless of the stage.

Stages and Length

It’s difficult to nail down both the perfect amount of interview stages as well as the duration of each. Some questions we might need to ask ourselves are:

• How many stages do we really need?
• How much time do we need in an initial screening call to make sure we’ve got a good enough impression of the candidate, their experience and if we should progress them?
• How much time would the average ideal candidate take to complete a given stage?
• How much time should we set aside for regular conversation in order to gauge the rest of the signals we can’t measure directly with technical challenges?
• How much time should we leave for the candidate to ask any questions they can have about the company, products, teams, tech stack, etc?
• How much are we affecting the daily workload of our interviewers?

In my experience at GfK, due to the constraints of the market at the time, the need to move fast, the kind of roles we needed and the focus on making efficient use of engineers. We defined a 2-step interviewing process:

• Manager Screening: 30 min.
• Technical Interview: 1.5 h. Split into:
  - 45 min technical challenge. Solving a coding problem that was designed to feel like a regular ticket you’d work on your everyday job.
  - 45 min conversation. Time to ask questions about experience, technologies, etc.

This took a total of around 3 hours of engineering time, taking into account preparation before the interview (like CV review) and time debriefing and writing down feedback afterwards.

On very select occasions where we felt we didn’t manage to gather enough information to make a decision we had an extra 30 to 45 min call with the candidates (if they were happy to attend it) where we dug deeper into what we missed. Or gave them a short take-home test when appropriate.

This worked really well for us, as well as for candidates. We received positive feedback on our fair use of their time. As well as for our engineers.

Screenings

During screenings we’ll often use a mix of classic technical questions as well as open ended ones. Keeping in mind we want to keep it conversational, it’s not an interrogation.

This stage is usually the first, and run by the manager. Their goal is to gain a general impression of the candidate, if they’re a good fit and they have the skills and expertise for the role. This is usually a short interview.

Having this before the technical test helps save engineering time. It’s better for a manager to spend 30 minutes interviewing a candidate that’s not a fit than 2 hours of a group of engineers.

If the interviewer is close to the tech, they can play it by ear and base their technical questions more closely to the candidate’s resume and experience. Otherwise they could draw from the pool of predefined questions and answers we’ve mentioned in the “Capable Staff” section.

Open-ended questions are particularly useful when we want to learn more about their career and professional background. Classic technical questions allow us to gauge the depth of their technical expertise on a given technology or language.

Asking candidates to talk about their favourite languages, tools or other topics; allowing them to explain their reasoning will very often provide us with great insights and open more topics of conversation.

• Ask them to provide examples of when they encountered X situation and how they solved it.
• Allow them to tell you a story about a challenge they solved and they’re particularly proud of.

Keep time in mind though, it’s a very limited resource in interviews and these conversations can easily consume a big chunk of your interview time if we’re not careful.

You might need to direct them a bit to something specific you want to know. But handle it gracefully, no one likes being cut off or spoken over.

We’ll also need to use behavioural questions to gauge personality and culture fit. It’s important to mention this doesn’t mean we’re looking for someone that’s just like us. Similar to an RPG game, you need a variety of skills and personalities to build a powerful and successful party. Much of the same applies when building teams.

This time should also be used for the candidate to ask any high level organisation questions that the manager is better suited to answering. As well as for giving the candidate an overview of the company, products, team and org composition, etc.

Screenings are not failsafe, and more often than not we’ll progress candidates that sadly will not perform well in technical stages. The interviewing staff can use debriefs and ad-hoc catch ups to discuss adjustments that need to be made to screenings. It could be adding some mandatory questions to be asked, or be more rigorous on candidate’ CV evaluation.

Designing Technical Tests

There are technical tests of many types and formats. For example, there’s take-home or live. LeetCode-style vs real-world scenario. And different companies will choose different combinations of this.

I personally favour using a live pair-programming format. It’s an effective use of time and allows for more design flexibility that LeetCode challenges. Similar to a video game, we can design it with more than one possible solution path, allowing the candidates to choose the one they’re the most comfortable with.

And the best thing is we don’t even need to explicitly let them know there’s more than one solution, we just need to take it into account when designing the test and planning our line of questioning.

For example, one of our tests could be resolved in an Object Oriented, Procedure Oriented or Functional way. And depending on the path the candidate chose we’d know which questions to ask along the way.

It’s also a good idea to reserve time at the end to have a mini retro and ask the candidates to reflect on their solution and if they’d solve it differently a second time.

We usually wouldn’t expect them to complete the test to 100% but to get as far as possible, while we evaluate their process and their use of both soft and technical skills.

In this format the candidate has to work on a pre-existing codebase and is asked to implement new requirements as well as refactoring the code. Some of the rules and constraints are loosely defined to allow them to take advantage of it and make design decisions as they deem fit.

For this test, ideally we want to create an environment similar to a regular day at work. With the candidate pairing with a couple of co-workers, who are also not too familiar with the code, to work on a ticket that has been assigned to them.

A controlled amount of stress is already included with the time constraint of the test as well as having to get used to the codebase, the rules and constraints. So interviewers can focus on making the candidate comfortable and have no need to introduce extra variables.

After the time is up it’s a good practice to take a couple of minutes to ask the candidates to have a mini retrospective on their solution and ask them what would they have done differently if they had a chance to do it all over again. It usually unearths useful information on their skills that they weren’t able to display due to stress or the time limitation.

Pros

• Familiar situation. The candidate is provided with a situation that can happen on a regular day at work, a codebase they don’t know much about and asking them to implement a feature and apply any refactoring they deem necessary or useful. This is a much more friendly environment than a code challenge interview where what’s being evaluated doesn’t necessarily relate to what the candidate will do on a daily basis.
• Prioritisation and Decision making. Time will usually not be enough for the candidate to fully implement the requirement and apply all the refactoring they want, so they need to make judgement calls on where to compromise, allowing us to measure their prioritisation and decision making skills.
• Communication. Being a pair programming test, and with the interviewers often switching to something like a junior role to ask questions, the candidate has to explain to the other engineers what their plans are for implementing the solution. Allowing us an insight into their thinking process like how they attack problem solving and pattern matching.
• Creative problem solving. Thanks to the loosely defined constraints the candidate can take advantage of this.
• Retrospection. When having the retrospective we can evaluate the candidate’s ability to recognise their mistakes and formulate better ideas for their solution. Both very valuable developer traits and, aside from the obvious, can be very useful for things like paying down tech debt.

Cons

• Technical skills not evaluated in depth. Even when stretching the technical test it might not be enough to evaluate in-depth knowledge of tools or language features, like Generics.
• Not every developer’s preference. Some developers would prefer to be given a take home test, with more requirements to deliver but also more time to iron out their solution.

In my experience running this kind of test both interviewers and candidates expressed they got value out of this format, regardless of the candidate’s final result in the interview.

Systems Design

Systems Design has become a big part of interviews in recent years. With books written specifically for them, with some of them even specialising in particular areas like Machine Learning.

What does a good System Design interview look like?

• Open-ended problem with no perfect answer. Sometimes this might look to candidates as too ambiguous or broad, but it’s designed that way for them to discuss and agree scope with the interviewer.
• Gather strong signals on a candidate’s skills. Focuses less on the solution and more on allowing the interviewers to gauge the candidate’s design, collaboration and communication skills. Like asking good questions, receptive to input and feedback, clarifying ambiguity and effectively communicating their opinions.
• Surface red flags. There are also negative signals, or red flags, that are just as important to look for when evaluating the candidate as an engineer and colleague. Such as: over-engineering, refusing to take input and feedback, closed-mindedness and how they treat colleagues in stressful situations.

I can’t say I have extensive experience running these. As they weren’t critical for us to evaluate in our particular situation and needs. We relied on the conversational part of the technical interview to gauge the candidate’s understanding of designing systems in isolation, interaction across systems and looking at the big picture in general.

So, here are some links to articles and videos from people with much more authority than me on this and other topics, like Gergely Orosz and Alex Xu:

• Preparing for the Systems Design and Coding Interview — The Pragmatic Engineer . Comprehensive list of books, courses, articles, videos, mock interviews and more.
• System Design Interview: A Step-By-Step Guide . Aside from his books, Alex Xu has created some very good, short, concise videos about the topic. Here he goes over a very good and simple 4-step framework he proposes:
  - Step 1. Understand the problem and establish design scope.
  - Step 2. Propose high-level design and get buy-in.
  - Step 3. Design deep dive.
  - Step 4. Wrap-up and follow-up questions.
• GitHub — donnemartin/system-design-primer: Learn how to design large-scale systems. Prep for the system design interview. Includes Anki flashcards. Repo with guides, questions, exercises with solutions and more.

Back-of-the-envelope Estimations

Some Systems Design interviews ask candidates to run some quick back-of-the-envelope calculations at the beginning of the test.

The main goal of this is to evaluate their grasp of the scalability and storage capacities the system needs, based on the information they’re given on the problem. Like daily active users, daily posts per user, average size of media in posts and data retention policies. Based on this they’re asked to estimate figures like QPS, storage, cache, number of servers, etc.

They don’t need to get the numbers right, similar to the rest of the System Design test, interviewers are mainly trying to evaluate their problem-solving skills and their sense of scale for systems.

Here’s a very good video from ByteByteGo on the topic: Back-Of-The-Envelope Estimation / Capacity Planning. And a great post from Addy Osmani about service availability figures that are good to know: AddyOsmani.com — Service Reliability Mathematics

Bringing it all together

Now, we’ve spoken about many topics I believe are important for defining an interviewing philosophy, just to review:

• Defined principles and important factors like environment and culture,
• the importance of training capable staff,
• ensuring consistency in interviewing experience and candidate evaluation,
• providing rich candidate feedback and making a decision, and
• shared some thoughts on ways to structure interviews and define stages. Screenings, Technical and Systems Design Tests.

I hope this has been of interest and useful to you.

I’ve spent years with these ideas in my head and it took me a lot of effort, coffee and maybe a couple gin and tonics! But it was also a lot of fun structuring it all in the best way possible, putting it into words and getting it out to the world.

If you’re already an Engineer who interviews people or a Hiring Manager:

I hope this helps you in your own interviewing processes, maybe tweak something here and there or leave a comment if you’ve done things in a different way that has worked for you. I would love to get your opinion on this. Positive or negative feedback, it’s all appreciated and well received!

If you’re an Engineer who’s interested in becoming an interviewer:

I hope this gives you a little push for you to raise your hand and volunteer as one. Honestly, it’s really fun! You get to meet a lot of people, tap into different minds from many cultures all around the world, you are always learning something new and get to see different perspectives on things.

And, if you’re a candidate looking for their next job:

I hope this helps you better understand how running an interview works, so you can prepare better for them and it allows you to navigate them more gracefully. As well as helping you recognize red (or green) flags that indicate what a company culture is like so you can make more informed decisions on if you should/want to join them.

Until next time!

Bonus. Further Reading

As a bonus, here are a number of great posts and articles that are related to this topic. Most of them align with my pre-existing personal views, some of them have influenced it as well and some touch topics I might also write a deep-dive article on my thoughts on them.

• How to build an interviewer training process that raises the bar | Metaview Blog . This one reinforces the importance of interviewers training.
• Good Interviewer/Bad Interviewer | Metaview Blog. This goes into deeper detail on what’s a bad and good interview.
• How to lead a coding interview | Metaview Blog. This focuses on signal gathering and has a great point on when it’s ok to step in and help candidates.
• How I interview engineers to assess ability to deliver impact | Metaview Blog . From this one I learnt the concept of “Candidate Priming”.
• Sometimes Management is about Letting Go of the Reins | by Mark A. Herschberg | Medium . A good read for managers, on the topic of leaving things in your team’s hands.
• Seven tips for evaluating soft skills in interviews — LeadDev. This focuses on evaluating soft skills properly.
• Red flags to watch out for during interviews — LeadDev. This one is relevant to both interviewers and candidates.
• Ten reasons engineers choose to stay with an organization — LeadDev. Same as the red flags one, very informative read for everyone.

Photo by Nathan Dumlao on Unsplash