Reading:
From software tester to interviewer: Lessons from my first interview process
RiskStorming image
An educational tool to explore Risk Analysis and Quality Strategy building with the whole team.

From software tester to interviewer: Lessons from my first interview process

Explore the challenges and insights from a tester's journey into conducting fair and effective interviews

Three resumes float against a dark purple background, each featuring an MoT monster. Two pens, one red and one green, lie nearby, representing the selection process in an interview.

"I really enjoyed being part of the interview process, from start to finish. It helped me gain insight into the recruitment process, but more importantly, I felt appreciated as an employee, and that ‘higher ups’ valued my inputs." 

To begin with…

Back in October, my team learned that we were to hire a new tester. We weren't replacing anyone, thankfully; we were adding a brand new person to the team.

This was really exciting. We really value testing at my company. Test-driven development is core to what we do, and testability is our first and foremost engineering principle. Adding a tester to the team was a really good opportunity to broaden the skillset of our team and improve diversity.

I also saw this as a chance to develop my skills in the application and interview process. One of our matrix skills for career development is influence, and I want to increase my influence within the organisation.

Due to the sheer number of applications (we got over 100 by the time we closed the request), the whole team was asked if they wanted to contribute. Luckily we have an excellent in-house recruiter who did the initial screening calls. For candidates who passed the phone screen, the next stage was a take-home test, whose results we all scored and commented on.

Reviewing the take-home tests

For our team, the review of take-home tests involved checking responses to the tasks. We paid special attention to how complete the test coverage in candidates' responses seemed to be.

If the candidates were deemed good enough, the next round was a technical interview with a member of the test team and a senior developer. 

Technical interviews

I prepared for the technical interviews by reviewing each CV carefully, identifying points for interesting discussions like a background in test automation or accessibility expertise. These qualities tended to be indicators for how they’d fare on the technical interview, and they also suggested that the candidates had experience and knowledge that wasn't reflected on their CVs.

I had a different interviewing partner for each interview. This led to some interesting interpersonal dynamics, but in the long run I think the candidates as a group were better off with a variety of interviewers. 

I took the lead on the first task, while the second was led by the other interviewer. This enabled me to be more observant during the second task.

After each technical interview, I compared notes with the other interviewer. It became obvious that we were consistently on the same page. I’m glad, because it made the whole process much easier. 

My biggest takeaway from the technical interviews was the diverse range of knowledge and skills exhibited by each candidate, highlighting the unique strengths and perspectives each brought to the table. This is a great reflection on the testing community as a whole.

If a candidate ‘passed’ this stage, the final step was a CV deep-dive interview with the head of engineering. 

CV deep-dive interview

In the deep-dive interview, the candidate spoke with the head of engineering and another member of the engineering department about what they’d done in their previous roles. The interview was designed to get to know the candidate in more depth and make sure that we were the right fit for each other. 

To ensure a thorough and insightful discussion, In addition to the CV reviewing, I also looked at other feedback from the previous stages. I also prepared notes in advance to guide our conversation and ensure we covered all relevant aspects.

Reflections on our overall process

In terms of the company process, I felt like I followed it well, despite possibly over-preparing for my first technical interview. The process is pretty stringent and well documented so there wasn’t much wiggle room. I think I asked more questions about them than the process dictated.

I'm happy that I refrained from simply jumping into the tests at our first meeting. Instead, I gave them a bit of background on the company and on me, and encouraged them to introduce themselves. This gave me insight into how they worked with various groups within their organisation, and also how they’d fit into ours. Normally this would be part of the final interview, but asking candidates about themselves eased them into the interview, and relaxed them somewhat.

Taking notes was relatively straightforward. I informed candidates beforehand that I would be taking notes during the interview to ensure they understood I was fully engaged and attentive. I found pen and paper to be the most effective method for me. I jotted down key questions, candidate responses, and any immediate feedback as the interviews progressed. I experimented with recording one interview and attempting to transcribe it, even using AI for summarisation, but I found this approach to be less effective and messier than pen and paper. 

The other interviewer and I would always meet up right after the interview to share our thoughts. We'd write up feedback and send it to the candidate, so it was important to be concise.

We did have a few people who were nervous, and as someone who gets very nervous for interviews I completely understood this. To keep people at ease I’d be frank with them and tell them I was also nervous. And as previously mentioned I'd introduce myself and talk about what is important to me. Plus I’d stick in a few of my signature jokes just for good measure.

If people really were struggling (and everyone I interviewed did in one way or another), I found my own way of ‘steering’ them into the answers we were looking for or in some cases a more coherent answer. Nobody wants to come out of an interview thinking it was an absolute car crash, as that doesn’t help anyone. 

Final thoughts

I really enjoyed being part of the interview process, from start to finish. It helped me gain insight into the recruitment process, but more importantly, I felt appreciated as an employee, and that ‘higher ups’ valued my inputs. 

I found it beneficial to have senior developers interview alongside me, as it provided a valuable perspective, especially since they’d interviewed candidates many times before. I have had some excellent feedback, not only from the recruiter and fellow interviewers, but also from candidates. 

This process brought back memories of my own experience with being interviewed at this organisation. At that time, I was a relatively new tester with only 12 months of experience. Reflecting on my progress since then, I'm proud of the significant growth I've achieved. As an interviewer, I drew on that experience as much as possible. Knowing the high standards for quality that we strive for, this helped ensure that the candidates were held to the same standard.

It's crucial to remember that an interview is a two-way street. I want to ensure that candidates have a positive experience and a clear understanding of what it's like to work here. I also want to provide them with ample time and space to ask any questions they may have to help them decide if this is the right opportunity for them.

Suggestions for other organisations

Let less experienced members of your engineering department be involved in interviewing. You’ll gain insights into what mattered to them in interviews, get a wider range of perspectives, and help build a diverse workforce. And seeing how different people in your engineering department interact with peers will help you to learn to gauge cultural fit better over time.

Suggestions for my organisation

Continue to do what you’re doing. Diversity is important, and I now feel a much more valued part of the company culture. This will only mean that I feel closer to the brand and will stay loyal for a long time to come.

For more information

Kelly Kenyon
She/Her
Software Tester
A passionate tester dedicated to ensuring digital accessibility for all. A keen eye for detail and a strong understanding of accessibility standards, working to identify and resolve usability issues.
Comments
RiskStorming image
An educational tool to explore Risk Analysis and Quality Strategy building with the whole team.
Explore MoT
Software Testing Live: episode 01 - Breaking the bank image
Tune in to witness a live software testing session. Rahul joins Ben to explore the ParaBank practice app
MoT Foundation Certificate in Test Automation
Unlock the essential skills to transition into Test Automation through interactive, community-driven learning, backed by industry expertise
This Week in Testing
Debrief the week in Testing via a community radio show hosted by Simon Tomes and members of the community
Subscribe to our newsletter
We'll keep you up to date on all the testing trends.