Are we hiring the right person?
Hiring is difficult. I don't think many people would disagree with that.
Over the years, I have been involved in hiring from different perspectives. I have applied for jobs, been interviewed, interviewed candidates myself and made decisions about who should join a team.
One thing I have noticed is that companies often spend a lot of time improving their interview process. They discuss the number of interview rounds, the type of assessments, the scoring system and who should be involved.
What sometimes receives less attention is understanding what they actually need from the person they are trying to hire.
Before creating interview questions, scorecards or deciding how many interview stages are needed, there is a question that should come first:
What problem are we trying to solve by hiring this person?
I have seen companies with very organised hiring processes. Technical assessments, panel interviews, culture interviews, take-home assignments and detailed feedback forms.
Everything was prepared.
But when people discussed what the team actually needed from the new person, the answer was sometimes much less clear.
That makes the rest of the process difficult.
You can have a well-designed interview process and still end up assessing the wrong things.
Start with the problem, not the interview
One thing I have seen many times is that teams start preparing interviews by looking for questions.
Someone realises an interview is coming up, opens an old document, searches online for examples or asks a colleague what questions they normally use.
There is nothing wrong with preparing questions. A consistent process is useful, especially when multiple people are involved.
But the questions should come from understanding what the team actually needs.
Some useful questions to answer first are:
- "What is the team struggling with today?"
- "Where do we need someone to make an impact?"
- "What would make us look back after six months and think: hiring this person was the right decision?"
Those answers should shape the interview.
Without that understanding, it is easy to spend time testing things that are interesting, but not necessarily relevant to the role.
The role you need versus the role you assess
I saw a good example of this through someone in my own circle (yes, QA people do occasionally socialise with other QA people!).
The company was hiring for a role focused on shift-left quality, coaching teams and improving collaboration. Automation was mentioned as part of the role, but it was clearly not the main goal.
Looking at the job description, I would have expected discussions around influencing teams, working with developers, improving engineering practices and helping teams take more ownership of quality.
The interviews focused on something else.
Most of the conversations were about technical implementation details: frameworks, tools, programming questions, testing approaches and edge cases.
What stood out was that the candidate never really got the chance to speak with someone they would actually work with after joining.
There was nothing wrong with the interviewers or the way they ran the sessions. They were simply assessing a different set of skills than the role description suggested.
That creates a difficult situation for candidates as well.
They are left wondering:
"Is this what the company values most, or is the job advert leading and is this just what they happen to test during the interview?"
Technical assessments should have a purpose
Years ago, before I started interviewing candidates myself, I had an interview where I was asked to implement a graph in Java from memory.
The exercise was done on a whiteboard. No documentation, no Javadoc, no internet and no IDE. Alternative solutions were not accepted.
I understand why companies use exercises like this. They can show how someone approaches a technical challenge and how they think through a problem when they do not immediately have all the answers.
What I found interesting was what happened afterwards.
During the feedback conversation, I learned that the company did not actually use this kind of work in their day-to-day environment.
That made me question the value of the exercise.
The exercise itself was not necessarily bad. The bigger question was whether it was measuring something that mattered for the role.
There are roles where algorithms, data structures or coding without assistance are important. In those cases, testing those skills makes sense.
The difficulty is that some assessments stay in hiring processes simply because they have always been part of them.
I see something similar in QA interviews.
Many technical assessments ask candidates to build a complete automation framework from scratch.
As someone who genuinely enjoys building frameworks, I understand why people like these exercises. They are a good way to explore someone's technical thinking.
However, most QA engineers do not join a company and start with an empty repository (unless you are like I was and you actually look for these roles).
Usually, they inherit an existing environment. They need to understand what is already there, decide what needs improvement and figure out where automation will actually help.
Those discussions often tell you much more about how someone will work in the role.
Technical exercises can absolutely be useful, but the question is if they help you understand the skills the person will actually need.
Conversations teach you more than question lists
Good interviews need some structure. Without it, it is difficult to compare candidates fairly or make sure important topics are covered.
However, the interviews I remember most are usually the ones where the conversation moved beyond the prepared questions.
A candidate might mention a decision (or opinion) they made in a previous role. If that sounds interesting, I usually want to understand why they made that choice. What alternatives did they consider? What would they do differently now (if anything at all)?
Those moments often tell you more than a prepared answer to a question they have already heard several times.
You see how someone thinks when there is no obvious answer. You see how they communicate their ideas and how open they are to different perspectives.
I have also been in interviews where the interviewer was so focused on getting through the question list that they stopped exploring interesting answers.
The next question was already waiting, even though the previous answer had opened the door to a much better conversation.
The questions you did not plan to ask are often the ones that give you the most insight.
Not everyone should interview
A potentially controversial opinion, but I do not think everyone should automatically be involved in hiring.
Being good at your job does not automatically mean you understand how to evaluate someone for a different role (or even the same role).
Interviewers need context.
They need to understand why the role exists, what challenges the team has (and company overall), what the long term plans are and what success should look like after someone joins.
Without that, people naturally judge candidates based on their own experience.
Different interviewers naturally notice different things. A developer might dig deeper into technical decisions, while a manager may focus more on ownership or communication. Both views are useful, but only if they connect back to what the team actually needs.
The goal of an interview is not to prove that the interviewer knows more than the candidate, but to understand if this person could succeed in the role.
The problem with hiring more of the same
Another pattern I have seen is teams hiring people who look very similar to the people who are already successful.
Sometimes that does work, it is possible that a team genuinely needs more experience in a certain area.
But it can also become a problem.
A very technical team might actually benefit from someone who is strong at communication and coaching, while a team with good technical skills but weak quality ownership might need someone who can start conversations and challenge assumptions.
The best person for one team is not automatically the best person for another.
The same applies to cultural fit.
I like the idea of cultural fit when it means someone can work well with the team. But it shouldn't mean hiring people who think and behave exactly like everyone already there.
A question I prefer is not:
"Do they fit our company?"
It is:
"Can this person help this team become better?"
That usually leads to a more useful discussion.
Hiring is also about knowing what you can teach
Over time, I have become much more aware that not every requirement has the same importance.
Some skills are needed immediately, while others can grow.
A company that treats every requirement as equally important can easily reject people who could have become excellent team members.
Many technical skills can be learned.
Someone can learn a new programming language, improve their automation skills or become familiar with a new tool.
Changing someone's attitude towards learning, communication or collaboration is usually much harder.
This does not make technical skills unimportant.
It means hiring teams need to be honest about what they actually need on day one and what they are willing to help someone develop.
Every interview stage should have a reason
Hiring processes have a tendency to grow over time.
A technical assessment gets added because it was part of the process before. Another interview appears because someone feels they need more confidence before making a decision. A culture round gets introduced because other companies do something similar.
After a while, nobody is quite sure which parts are still adding value.
Having multiple stages is not automatically a problem. For some roles, several conversations with different people are useful.
The question is whether each part of the process helps you understand something important about the candidate.
Before adding another step, it is worth asking:
- What are we trying to learn from this?
- Is this the best way to find that out?
- Does this person need to be involved?
A good hiring process does not have to be short or simple.
It just needs every part of it to have a clear reason for being there.
What I've learned
Hiring has taught me that the hardest part is usually not finding people to interview.
It is understanding what you are actually looking for.
I have made hiring mistakes myself, and I am sure I will make more in the future. Hiring always involves uncertainty because you are trying to predict how someone will work in an environment they have not experienced yet.
The best hiring decisions I have been involved in usually started before the first interview was scheduled.
The team understood where they needed help. They knew what was already working, what was missing and what kind of person would complement the team.
When that understanding is there, the interview process becomes much easier to shape. The questions have a purpose because they are connected to the reality of the role.
After years of interviewing and hiring, I keep coming back to the same point:
Many hiring mistakes are not caused by a lack of good candidates, but because companies never became clear enough about what they needed someone to do.
Finding the right person starts with understanding the problem first.
Alex Hovenkamp