Simon wrote a great post in 2015 about questions we can ask candidates during an interview. A little later, I wrote an article on the bias and problems built into different styles of interviews, and some ways we can counter that to get a better understanding of the candidate. Ideally, we ask a person the right questions, and in the right conditions so that we can learn about their skill level and how they might contribute to our teams. I also assess candidates based on the questions they ask during an interview. These questions show that they are curious and paying attention. They show that the person is able to discover when they don’t know something, and figure out how to seek that information. And, they of course can learn more about whether or not they want the job based on the answers.
So, what questions should you be asking when you go to job interviews?
Clarifying the Role
Job advertisements tend to be pretty generic. Most will say something about discovering and reporting bugs, creating and executing test scripts, and generally working to help the development group produce the best software they can. But, in the same way that a test case isn’t testing, the job specification isn’t the job. There are whole categories of things that people forget to describe when they make a job advertisement, and others that are hard to turn into bullet point lists. These questions are designed to help you learn what a tester really does at this company.
Companies, and even teams within a company, approach testing from vastly different perspectives. Some groups deliver software hundreds of times every day and do most of their testing by layering automation and using radical collaboration tools like Extreme Programming. Others companies completely separate the testing, development, and product groups. Testers are expected to do the testing equivalent of big design up front, and then perform those plans once there is software to look at. Most companies today are somewhere between those two extremes. You will probably want to understand how the company thinks about and approaches software testing.
Culture is shorthand for the ways people in a company interact, the goals they strive for, their value system and ethics, and how employees treat each other. Some cultures foster an environment where lone individuals can control broad swaths of the product, and are responsible for its problems as well. Others are collaborative, congenial, and encourage open discussion about where improvements can be made and who the appropriate people to do that work are. There are also the very important questions of diversity and inclusion practices. Getting a feel for culture can help the interviewer, or you, to figure out if you are a fit for this organization and how long you might want to work there.
Clarifying the Team
Team compositions vary quite a bit. The last company I worked with had a completely flat structure. There were 6 or 7 developers, 2 testers including me, and we all sat in the same room. We had some people that were acting as leads in practice, but they didn’t have the title or the power that comes along with that title. We all reported up to one development manager when we needed something, or when he needed something from us.
Other teams I have worked with were steep pyramids. One company had a handful of testers per group, each group had a lead tester, and a couple of groups combined would work with someone called a test architect. There were also managers and directors in the mix. Everyone reported up to someone else and the ladder was tall. My personal preference is to work in a more flat structure. I feel like it is easier to get things done, and decisions come through much faster. These questions can help understand how flat or deep the organizational hierarchy is at a company, and how that will affect the testing work.
This is a tricky category because it is dependent entirely on the flow of conversation. I usually have a laundry list of questions I want to ask people I’ll be working with and what you see above is an example of that. But, I also come up with a lot of questions based on what we are talking about at any point in time. Technology work is full of lingo, some of it is overloaded to mean different things at different points in time. In testing, we don’t have a lexicon, or a standard dictionary. A lot of my questions focus on that. An interviewer might start talking about their regression testing process and I’ll say “When I say that term I mean the testing we do to discover new problems introduced by a change. Is that what you mean?” I also like to flip questions back on the interviewer to learn about them. If they ask me how I would test something, after I give my answer I like to ask them the same question. This can be a learning experience, and can also be a litmus test for how the conversation is going.
This is just a few of the questions I like to ask. They help me learn much more about what sort of job I would be getting into. Sometimes, they help the people on the interviewing side to better understand what they are looking for, and what they really need in a new tester. What questions do you like to ask when you go to a job interview?
This is a guest posting by Justin Rohrman. Justin has been a professional software tester in various capacities since 2005. In his current role, Justin is a consulting software tester and writer working with Excelon Development. Outside of work, he is currently serving on the Association For Software Testing Board of Directors as President helping to facilitate and develop various projects.
Help us improve this page!
What problem are you trying to solve?