How to prepare for a software testing interview

I don’t talk about all preparation aspects here… I don’t cover what should be in your CV or how you should research the role you’re being interviewed for or what testing terminology you should be conversant with. I only touch lightly on the interview itself, as my main focus is to describe how to draw on your testing experiences and knowledge, to answer questions during an interview for a software testing role, and to learn from the interview experience itself.

Be the authority on your work experiences

No one knows better than you what projects you’ve worked on, what your tasks were, or how you contributed to the outcomes. Do some background prep so that you have enough information to share in an engaging and useful way.

The first key task is…

Develop the practice of writing up details about each project as you finish working on it.

It’s so easy to forget the details of what we actually did after some time has passed right? It’s also easy to be keen to move onto the next thing and forget the last… But, there’s a lot of value in pausing to reflect on what you did and how you did it. From now on, as I finish each project, I will write up an information sheet about that project. These sheets will remind me of the range of activities, tools and processes I used and what I contributed. For now, as I’m playing catch up, I just focused on writing up sheets for the last few projects only.

1. Write up a project sheet

For each project/employment period, write up a project information sheet. I suggest using the following titles:

• Name of company/employer
• Project
  • Name of the software being developed and a list of basic architecture details such as platform, language, database, client base
• Time period
• Your role/title
• Team information
  • The SDLC and framework used
  • List of the people in the team and others you interacted with
• Tools used
• Tasks – regular
• Tasks – one-off

2. Add Retrospective notes

Do a Retrospective for the project from your personal point of view and experience. This period of free thinking might remind you of additional details about the project and your involvement – and is likely to provide rich material for an interview about how you interact with others and resolve problems. It may also help you identify the sorts of projects you are drawn to work on in the future.

Consider the following questions in your Retrospective:

• What went well?

• What didn’t go so well? List the challenges even if these were eventually resolved

• Ideas for learning or for the next project? Was there anything you wish had been done differently or that wish you had known more about?

• Any achievements or highlights? Be sure to mention any great feedback received for your contribution. Note what tools or processes really helped the project and state how. What parts did you really enjoy?

What questions will you be asked?

There are probably around five types of questions that a software tester may be asked:

1. Questions about previous projects
2. Questions about tools
3. Questions about your behaviour and how you work with others
4. Questions about your testing approach
5. Questions about your testing terminology knowledge

Think about what questions you’re most likely to be asked for each interview and prepare answers for those questions. Remember to save all your prepared answers for future interviews too – and keep refining them – so that when another interview opportunity arrives, you have some ready-to-go material.

At the end of this article, I have included a suggested approach below to writing your answer for each of the above question types as it’s not always really obvious how to use the STAR approach on some of them. Once you’ve drafted your answer, practise speaking it out loud to confirm that the answer is less than three minutes long, informative and has good flow.

Practise being interviewed

Now that you have done some content preparation, find a colleague or mentor who’s willing to do a mock interview with you. Send them your CV so they have the same material that an interviewer would have as this might prompt them to ask similar questions and enable you to be perfectly prepared.

Obviously, the third key task is…

Find an interview coach and practise being interviewed.

Request that the practice interviewer pauses after you have answered each question to give you feedback and coach you. Take the opportunity to respond to the same question again if you need to improve your delivery.

Give your practice interviewer permission to give you any feedback. I got really useful feedback from this as I had absolutely no idea that I sighed deeply and ‘tutted’ when I was thinking about how to answer an unexpected question! I think we can all agree that sighing would not make a good impression and could easily be interpreted as disinterest, rather than simply being an unfortunate habit.

The interview itself

Ok, so this article is entitled ‘How to prepare…’, but I just wanted to add some bonus points:

• Show interest… sit forward, make eye contact, consider taking basic notes when the system and environment is described (this could be useful later)
• Trust that you have prepared enough – if they ask a question you haven’t specifically prepared for, just pause and think through the STAR pattern to formulate your answer. Before you know it, this may become second nature to you. (That’s what I am hoping for myself anyway!)
• Recognise that the interview is an opportunity for an employer to select their preferred candidate and you may not be it – this time. And that’s ok
• Be interactive… ask questions to encourage a natural conversation and show that you’re interested. You could ask for clarification about what they’re wanting you to explain. Or perhaps ask about their experience of a particular tool
• Be yourself… the interviewer wants to get an idea of what your personality is and whether you will be a good fit with the team

Do a Retrospective on the interview

Yes, even though a Retrospective is done after the interview you were preparing for, a Retrospective is preparation. It just happens to be preparation for the next interview.

The fourth key task is…

Do a Retrospective on the interview and use this to update your project sheets and draft answers.

There really is great value in applying the Agile principle of ‘inspect and adapt’ to most areas of our lives – and interviews are definitely a prime candidate for a Retrospective. What can you learn from the experience of that interview? What products, tools and terms were mentioned that you wish to research and learn more about?

Once you have been advised whether you were successful or not, ask for feedback from the interviewer and add these points to your Retrospective. The fact that you took action based on feedback from a previous interview might help you be successful in the next.

Use the usual Scrum prompts to reflect on the interview…

Whatever the outcome, an interview is a win-win situation

Even if you’re unsuccessful in your application for the role or project you were being interviewed for, it’s most likely that the interview will have been beneficial for you because:

• Every interview is an opportunity to practise. And practice helps you to improve your skills
• Particular tools, terms or products may have been mentioned that piqued your interest.  Look them up to build your knowledge. This will allow you to converse about them in the future with a bit more awareness
• During an interview, you have an extraordinary opportunity to hear how other development teams are approaching their work. You may pick up an idea or information that is useful right now or some time in the future

The project information sheets I mentioned above may be useful reminders of tools, techniques or processes that are suitable for your current project. I recently referred to a sheet when I was trying to remember the name of a tool we had used for a particular problem – and the name was there. Another time, I searched for the name of the cool web icons we used, but sadly, I had failed to note them down. Of course, Google is still my friend, but it would have saved a bit of information sifting if I’d noted the name down.

Summary of this approach

The key tasks for preparing for an interview in software testing:

• Develop the practice of writing up details about each project, as you finish working on it
• Draft your answers as short, engaging stories using the STAR approach
• Find an interview coach and practise being interviewed
• Do a Retrospective on the interview and use this to update your project sheets and draft answers

This approach helped me think about my experience and skills in a more organised way. Did it help me get the assignment? Still not sure yet… but it’s certainly giving me more confidence heading into interviews.

Suggested approach to using STAR for each question type

I’ve created some formats for answering several questions types as I didn’t find it that obvious how to use the STAR approach for some of them. Remember that STAR was created to respond to behavioural questions, so it needs a bit of thought to be used for a more technical answer. BetterUp site has a great article if you want further information on the STAR approach for interviews.

Q1. Tell us about your work on Project X…

Use the information you have collated on your project sheet, including the Retrospective section, to draft an answer for each of your projects. You want to be able to demonstrate that your actions have contributed to successful projects.

• Situation
  • Briefly describe the product that were you working on and what development was being done on it
• Tasks
  • Explain what you were responsible for doing
• Actions
  • Detail how you carried out the tasks. Touch briefly on the tools and processes that you used so that the interviewer is aware that there’s a range of topics they could ask you for more information on
• Results
  • Describe the outcome for the project or your time on it. Highlight what outcomes you contributed to

Q2. What was your experience with Tool X?

Use the above STAR pattern again to describe your experience with several of the tools that you’re familiar with.

• Situation
  • Explain what sort of tool it is. It could be worth mentioning how it was selected, if you’re aware of this or were involved in that process
• Tasks
  • Explain what the tool was intended to helped with
• Actions
  • Describe how you used the tool and your level of competency
• Results
  • Describe how the tool helped the team to deliver quality software or any other observations you have

Q3. How do you behave/respond/work with others in Situation X?

This is the key behavioural interview question type. You may be asked how you received difficult feedback or how you’ve given it. There’s a raft of possible questions of this type! Select a question you think you will most likely be asked and prepare an answer for it. If nothing comes to mind for the scenario, review your Retrospective notes for recent projects as this might help you recollect a suitable example. You want to show that you can work well in a team and contribute to team success. The interviewer also needs to know that you are open minded and, when one action doesn’t work, that you’re prepared to try a different approach.

• Situation
  • Briefly describe the situation and who was involved
• Task
  • Talk about the particular task that the situation was about and what the challenge was or what expectation was not met
• Actions
  • Explain what you did about the situation.
• Result
  • Summarise how you turned the situation into a positive

Q4. What is your approach to X Testing?

You may be asked what your approach is to regression testing or something else. Use this opportunity to share how you have done it in the past and how you might do it in the future. Make it clear that you are aware that each development project and environment will dictate your testing methods to some extent.

• Situation
  • Mention which project you will be sharing your experience from
• Task
  • Describe the scope and timeline for the testing and, perhaps, how that was determined
• Actions
  • Explain how the testing was done, what you contributed to, how you were involved and how progress was monitored
• Result
  • Discuss the findings and success of the testing and whether this experience of X testing resulted in any process improvements or subsequent revision of testing plans

Q5. What is Testing Terminology X?

This interview question may be asked to determine your testing terminology knowledge. This is one category of question that might be tricky to use the full STAR pattern on, but use the parts you can.

• Situation
  • Explain what the term means
• Tasks
  • Describe when it might be useful
• Actions
  • Describe when you have used it and how, and then your level of competency with it
• Results
  • Discuss whether it proved to be useful

• Twitter
• Linkedin
• Email