Quality Engineering Interview Questions
Real interview questions from real Slalom Build QE interviewers
In a previous article we described the Quality Engineering Interview process. Here we’ll share real interview questions used by real quality engineering interviewers. Yes, below are actual questions (and actual answers!) asked in actual interviews.
We do this to provide deeper insight into how we approach interviews and evaluate candidates' potential. We believe what we look for and what we ask should be transparent and freely available. Interviews are more conversations to understand how you think, less rapid fire trivia to evaluate what you know.
The scope of a quality engineering interview is necessarily vast — these ten questions only touch a small cross-section of possible topics. Don’t assume that just because you understand these question you have everything you will ever need for quality engineering.
However, even if they are just a small slice of the pie, each provides tremendous insight into the thinking behind the question: why the interviewer chooses this question over the millions of others, and what they are looking for in an answer.
The questions below are divided into skills and behavioral categories as defined in the previous article.
Here we go!
Skills Interview Question #1
Blake Norrish
Senior Director of Quality Engineering
I have a suite of one hundred automated end-to-end tests. I run them and some fail. I rerun them and a different set fails. What might be causing this flaky behavior?
Why I ask this question
Building automation for non-trivial software is a critical skill for quality engineers. However, real E2E test automation is so much more than just finding the right selector to click a button.
In real-world E2E test automation, driving application behavior with UI interactions with tools like Selenium, Cypress, or Playwright is the easy part. The hard part is doing this in a repeatable, deterministic way so that test results are trustworthy and meaningful.
In E2E environments this necessarily gets into topics like test data management, deployment pipelines, system decomposition, managing shared resources, and many other concepts. Understanding these challenges and how to mitigate them is the real skill, and this is what this question dives into.
I like this question because it separates people who only have a basic understanding of test automation and think E2E test automation is all about knowing a UI framework API, from people who have real industry experience solving real automation challenges.
What a good answer looks like
E2E tests can exhibit flaky behavior for many reasons, and good answers will cover a variety of these, while talking intelligently about why they might happen and possibly what can be done about them. Let’s go through some examples.
Let’s start with the most obvious: E2E tests are usually driven through the UI, and UI automation can exhibit flaky behavior. A good answer will usually discuss this, possibly get into topics like explicit vs. implicit waits in WebDriver-based tools like Selenium, and how DevTools-based tools like Playwright partially solve this. Knowing the limitations of UI automation is a good start when answering a flaky test question.
What else? Well, E2E environments are usually large and complex, so was there known instability in the environment itself? Is there monitoring and alerting on the E2E environment like there is in production (there should be!)? Do we know if deployments or other “known downtime” things were happening in the environment at the time?
What about external things that could impact test results? E2E environments are often “production like” and connect to services outside the boundary of “our” system, were there any issues in those during the time of the flakiness?
What about test data, a huge and complex topic in itself. Do the flaky tests leverage data, explicitly or implicitly, that could be deleted or modified outside of the test itself? How close are these E2E tests to hermetic tests, something that is often very challenging to accomplish in E2E environments just due to the vast set of data any one test depends on?
What about the flaky tests interacting with themselves? If one automated test is executed multiple times in parallel against one environment, does the test guarantee that each test instance is hermetic?
What about ordering of tests? Do some tests accidentally depend on state created setup or destroyed by other tests? Could it be that our execution framework does not guarantee test order (it shouldn’t) and the flakiness is a symptom of a slightly different execution order each time?
Maybe the tests themselves are randomized in some way. While usually not recommended, some types of tests purposefully randomize data, usually to ensure coverage over an undefinable range (for example: unstructured input data).
What if the SUT itself has a nondeterministic defect and the test is correctly identifying this! This isn’t a false positive at all, it’s a true positive!
The above examples are just the tip of the iceberg for E2E test flakiness. I’m sure experienced test automators were coming up with additional examples even as they were reading this.
The point of the question isn’t to ensure you know the correct five reasons… there isn’t a correct five. You could miss any one of those (even the obvious #1) and could still do great on the question. It’s more about how you think about test automation and the depth of your understanding of the challenges of E2E testing.
Quality Engineers aren’t simple scripters that take test cases and churn out Selenium tests without thinking, they should understand the value proposition of test automation, and this includes the challenge of creating deterministic, dependable E2E tests. This question helps identify candidates with this (very valuable) expertise.
Skills Interview Question #2
Jeff Averill
Director of Quality Engineering
When working on a feature or story, how do you determine what you will automate?
Why I ask this question
Automation has many pitfalls — from flaky tests to gaps in coverage and everything in between. There is no perfect science in what to automate that applies everywhere, and this answer can help uncover how an interviewee thinks about their automation approach. It speaks to their experience, challenges in their career, changes in best practices over time, and so much more.
The reason I like this question is it helps uncover how a candidate processes their approach to work. I want this insight into their thought process.
What a good answer looks like
My expectations depend on the level of the individual. At the basic level, I don’t want to hear “everything.”
People newer to QE may talk about UI automation pitfalls in their experience: moving or hidden elements that cause intermittent test failures, or complex workflows like 2-factor authentication are some good starting points to discuss. These can take many cycles to implement if not thought out well, or discussion with developers about the testability of their work.
At a higher experience level I look for questions from the candidate about the automation approach before they even start to answer: what has been decided for this project by a lead? Where are the largest complexities of this application? Have we determined how far down we can push automation (unit tests, integration)? Is this aligned with the Test Automation Pyramid (or variant shape)? Who can I speak with to ensure my plan aligns with the team or lead?
This is just the start of where the conversation can go — and this doesn’t even cover what sort of application is being built, which can lead to a number of different approaches. What are the common flows or happy paths of what is being implemented?
I want to understand how a person thinks of these questions before they start work. Break down the challenge and weigh the estimated levels of effort to the value it will bring — this should be how we determine what to automate. The common trouble areas are a great place to start, and then step back and think more holistically about what we are trying to solve for.
Skills Interview Question #3
Dan Snell
Director of Quality Engineering
Below is a small snippet of simple Java code that leverages Selenium. Please review it and offer some recommendations on how to improve it.
Why I ask this question
I ask this question to assess both general coding approaches as well as specific test automation concepts. Even this small, simple code sample allows me to look at both.
It is important that quality engineers understand both good coding practices as well as good automation practices to both provide solid input when performing code reviews as engineering partners and also build robust automation solutions on our projects.
I like this question because I can adapt it to the level of the candidate. I would not expect an engineer with a few years of experience to give me the same depth of answer that a Sr. Architect would.
What a good answer looks like
There are two parts to this: automation-specific answers and general coding parts.
On the automation front, I’m looking for ways to make the test readable, as well as identification of some of the common errors around sleeps and locators. I can gauge depth of understanding of the topics (see sleeps vs. waits and impact on execution time) that helps me separate if they just know it should be done vs. really understand the why behind it.
I also am interested in hearing about descriptive tests, locator choice, page object model approaches, etc. I may then branch off these topics and address concepts like hard-to-find elements, locator fragility, and working with development teams.
On the coding front I’m looking for recommendations around code structure, design patters and organization, readability, naming, the use of parameters for data object-orientation or not, and handling of secure data in code.
One of the key differentiations between an average answer, a good answer, and a great answer comes down to the what, why, and depth of understanding. An average answer addresses the what. A good answer can understand the why, while a great answer should be able to describe multiple ways to approach addressing a problem(Page Object vs. Page Components) and the pros and cons in each.
Using this small chunk of (very) poorly written code as a starting point helps me understand if a candidate has sufficient hands-on experience writing both code and automation to be a successful member of our Quality Engineering capability.
Skills Interview Question #4
Adam Tapper
Principal, Quality Engineering
What is the goal of software testing?
Why I ask this question
In his book, The 7 Habits of Highly Effective People, Stephen Covey identifies one habit as “Begin With the End in Mind.” This means that every undertaking should have a clear direction and desired outcome.
In software testing, engineers often write tests for their code because they know code is supposed to have corresponding tests. When pressed on what they are testing or how they know when they have “enough” tests, I am often met with blank stares as it is likely the first time that someone has asked them to think deeply about the why behind what has become a rote task.
Many companies conflate the role of quality engineer with that of “tester” in which the role exists to check a box stating that some level of feature validation has been done prior to going public with the feature. Simply checking the box often leads to separation of quality activities from development, finger pointing when a production issue is discovered, and apathy toward, or disdain for, the quality processes in place.
As a quality engineer, my job is to be an evangelist for whole team ownership of quality, one of our core values here at Slalom Build. This means creating a vision of what high quality looks like for a product and how it benefits the client and their customers. I ask this question because I want to know that candidates can advocate for the importance of the quality engineering processes rather than arbitrarily testing whatever code is in front of them.
What a good answer looks like
There is no specific correct answer to this question; rather, I am looking for candidates to think beyond the idea that we test to find defects or ensure quality. I’ll explain a few possible answers below.
Revenue Generation
When I’m addressing clients that ask why they should pay for a quality engineer on their team, I often start with the idea of speed to market. It’s extremely rare that a company is the sole provider of a product or service today. The more likely scenario is the market is saturated with providers working tirelessly to gain an edge over their competitors. This means a three week delay in releasing a feature can be the difference between a record-breaking sales quarter and layoffs. As this point, it’s fair to ask: “Why even go through the quality process then? Why not just release all features as soon as the development team says they’re done?”
To answer that, we have to return to the idea that there are often many competitors in the industry. This changes our goal slightly from speed to market to speed to market with confidence. I often tell clients that in today’s world, you only have one chance at a first impression with potential customers before they move on to another service. In fact, 1 in 4 visitors will abandon a website that takes longer than 4 seconds to load, and 46% of users don’t revisit poorly performing websites. This means that reducing the website load time from 4 seconds to 3 seconds can result in retaining over 10% more potential business.
Rarely have I heard revenue generation as a goal of quality engineering which can really set a candidate apart by showing that they understand the big picture of software development in regards to running a business rather than their individual responsibility.
Minimize Risk
Defects are bad and should be ruthlessly eliminated. While a bit overstated, that is a declaration that most everyone in the software development community would agree with. It naturally follows that the job of a quality engineer would be to endlessly hunt for defects until a product is deemed perfect, all the while maintaining a backlog with hundreds or even thousands of issues with varying severity and priority. This is an expensive, confusing and overall boring process. Rather than finding every possible defect, the goal of a quality engineer should be to identify and minimize business risk.
Allow to me to give you a scenario. A pool chemical supply company also sells pool toys, but toys account for 5% of their revenue. Pool season starts tomorrow, and they are working towards the release of a new feature that will allow for a subscription service which enables them to contract property management companies and service all of the buildings in their portfolio. When working on a the last part of the feature, the team notices that clicking on a toy advertisement doesn’t work, but only on the subscriptions page. The team determines it can be fixed if the release is delayed by 3 days. Is fixing the toy issue before the subscription release worth losing the potential recurring revenue of multiple corporate clients that will sign up with competitors? These are the types of risk-based questions that quality engineers must expose and then help businesses answer.
Cost Savings
Building custom software is expensive! Mention that to a room full of executives when they are doing their yearly budget planning and you will be met with resounding head nods. Quality engineering can actually help make it less expensive. This point can often confuse clients because a quality engineer is an additional role on a team. Allow me to explain.
Quality engineers can aid in cost savings through early defect detection. When a new button prototype is being developed, and it’s discovered that the button is not interactable on mobile screens when the keyboard is opened, the issue can be fixed within a matter minutes or hours. When that same issue is discovered at the completion of building the system, that button is now used in 148 places including key functionalities such as requesting quotes and submitting payments. Fixing it after the system is built requires much regression testing and puts the business at risk for losing leads, collecting payments late, and having frustrated customers that may become former customers. Having quality engineering involved early in the development cycle is much more cost efficient than replacing existing customers.
These are just a few of the many goals of software testing that can be mentioned in response to this question. The main goal of the question is to ensure that candidates understand how their day-to-day work ties into overall business goals. Ultimately, quality engineers are not testers and defect loggers. They are a driving force behind the success of the business.
Skills Interview Question #5
Ramana Manohar
Director of Quality Engineering
You are a quality engineer starting on a new greenfield web application project. As you plan your test strategy, what considerations would you have for test environments and branching strategy?
Why I ask this question
Many teams do not put enough emphasis on test environments and branching strategy as a component of their test strategy. This can prove to be problematic, especially for QEs on the team. Is this a challenge that you can help address?
As a quality engineer on a project, it’s important to have a good line of sight into every detail that affects quality. It is not only about having a great test automation framework/tool or excellent test coverage. You need to understand the larger picture as well: the entire pipeline the product moves through before it’s ready for production.
Branching strategy goes hand in hand with environment setup, so how do you approach answering this question? I intentionally leave it open ended, and I look for the candidate to try and make sense of this ask and work their way through a good solution.
What a good answer looks like
There is no ONE right or wrong answer to this question. Specific answers will vary greatly depending on the experience, exposure, and skill of the candidate.
An important thing to keep in mind is that even though this question may seem to lie in the domain of Platform/DevOps, quality engineers have responsibility to help shape the infrastructure and the CI/CD pipelines within a project. Partnering with platform teams in the right way is critical. So, is this on your radar?
First things first, I like to see if you have any questions for me before you start answering. For example: does the project have a cloud platform, if so which one? Is there a platform architect/DevOps expert on the project team? Does the team have a good understanding of Definition of Done? Etc.
Meaningful questions mean you are putting more thought into this. I appreciate that and can probably expect a good level of detail and well-rounded answer. If you do not have any questions and jump right into solutioning, it is still okay, but you will need to go the extra mile to explain the assumptions you probably made along the way.
Moving on to the answer to the actual topic, I look for a variety of things from you. You can bring up whatever aspects you feel are important. A well-structured answer might discuss the importance of pre-prod environments and how they’re connected, or go into any hands-on experiences you have with cloud platforms & CI/CD tools.
Additional topics might include:
- Do you know the concepts of IaC? If so, what tool are you familiar with? Terraform? Great, let’s talk…
- You mentioned that you’re familiar with Jenkins. Can you elaborate your role? Did you just click a job to trigger your tests or were you actually involved in building the job and maintaining them?
Furthermore, when discussing this topic, here are some of the things I keep in mind to see where YOU think quality fits into the picture:
- What is your philosophy when it comes to defining different environments for a project?
- What types of branching/development models are you familiar with? Can you explain a popular model (Trunk-based, GitFlow, etc.) and how QE fits into this?
- Is testing done only on the QA/Test environments? Are you thinking of the testing pyramid and how various types of testing can be performed at different stages and environments?
- What types of testing are done at different stages of promotion? Are you able to suggest what testing should go where?
- What about code promotes and branching strategy? Do you see yourselves involved in this process?
- What’s your opinion on whether QE should be included in the PR approval process?
- How do you come up with the mechanism for conducting smoke & regression tests?
- How doe this particular topic fit into the overall test strategy for the project?
The list goes on… but you get the drift.
The point of this question is to assess your understanding of test environments and CI/CD, topics which are often overlooked by quality professionals. Understanding that quality engineers can (and should) contribute by proving a different lens into the DevOps, Infra & CI/CD setup for a project is vital to the team’s effectiveness. Being synergic and having quality ‘engineered in’ the project is always the end goal.
Skills Interview Question #6
Jake Kline
Principal, Quality Engineering
It’s your first day on a project called “Movie Stream Cash Machine” for a client called FakeFlix. When you meet the architect she says they haven’t really thought about testing yet and wants you to work on that area. She points to me and says “This guy can answer your questions and get you anything you need.” As a quality engineer, what would you need to ask me?
Why I ask this question
One, the question is deliciously open-ended giving the candidate the freedom (and perhaps the curse) to go anywhere she wants based on her career experience, imagination, and critical thinking. It’s also evocative of those delirious word problems they’d administer in math class that require essay responses. Nostalgia aside, time is limited and I need questions that inspire conversation, examine technical skills across many dimensions, and are flexible enough to be abandoned and returned to based on the overall flow of the interview (i.e. if we wanted to deep-dive into python or OWASP and then return to solutioning Fakeflix, we could.)
Another plus is that the question can be applied to candidates across the career spectrum from junior engineers with no consulting experience to seasoned veterans of both consulting and QE.
Finally, the candidate gets a touch of reality with this question; we are a fast paced, dynamic consultancy. Things come at us quickly and we are often asked to confront ambiguity by staying curious and focusing on outcomes.
What a good answer looks like
Like I suggested earlier, all answers are context driven. Remember, this question could lead to a good discussion about using Cypress versus Playwright or solving for a severe miscalculation in QE staffing. Is one objectively better or worse than the other? Keep an open mind about responses. Build a mental model of what is said and try to visualize what the candidate is telling you. That said, I believe there are several conceptual components to a good answer.
THE CANDIDATE ASKS QUESTIONS: the architect in the question called me (Jake) out as a person who could answer questions and get things the candidate needs. Nothing helps ground a lofty open-ended question like some concrete facts in the form of answers to questions. Good answers here should include a lot of questions, anything from: “What is my role?” “Is there a test strategy” “What is the tech stack” to “I’m completely lost. Could you clarify what we’re trying to accomplish?” In my experience many early career candidates start out working on something they’re comfortable with (like front-end automation or test cases) and work outward to the problem of solutioning for Fakeflix. Some career consultants attempt to skip over the question entirely. The point is that asking questions throughout the process of answering this question is key to narrowing in on answers with interesting content.
THE CANDIDATE GLEANS WHAT AFFLICTS ME: Through the Q&A process the candidate comes to understand what the “Movie Stream Cash Machine” project actually is and what Fakeflix is looking for from Slalom. Getting an idea of the scope of the solution (problem) and how it might be architected (ask the architect! ask me!) will ground the conversation materially and allow both candidate and interviewer to probe interesting avenues of the testing problem implicit in the overall solution. It is also an opportunity for the candidate flex on tech stacks and processes she knows have worked for her in the past and for the interviewer to throw roadblocks in the way to assess creativity and problem solving, i.e. “Great, you’re a .net person! Love it! Well we’ve already invested in Java Spring for the microservices. Will that be a problem?” Implementing standards like DRY & SOLID have also come up here in the past. Kudos if the candidate wants in on establishing these.
THE CANDIDATE ASKS FOR THINGS, LOTS OF THINGS: Again, according to the architect, the interviewer is the conduit to the world. I like to see candidates ask for the world: 1) because I set no constraint there and 2) they deserve this once to dream the impossible dream. Go loud on this: ask for seven more QEs; ask for a platform engineering team that will implement ephemeral environments in their CI\CD pipelines for every feature branch; ask for a branching strategy that uses one branch onto which everyone rebases (just ask for it, come on!) Ask for comprehensive logging; Ask for total observability into the entire system; Ask for automation frameworks for every tier of the application; Ask for an unlimited cloud budget; Demand that performance testing be started day one and included in the pipeline; and of course demand a clear and concise test strategy worthy of a QE Pulitzer. Bonus points for offering to write such a strategy. The caveat to the dream is that I like to see some precision in the answer. I want the world as well but I have my reasons. Candidates should too.
THE CANDIDATE POINTS OUT PROBLEMS: Candidates at any level should feel free to call shenanigans when it feels like shenanigans are in play. Good answers usually include things like the project is understaffed, QE is understaffed, “you’ll never get front-end automation working in a synchronous framework,” “Who decided it was my fault that bugs escaped into the wild?” Too often an interviewer is viewed by the candidate as an authority or so well versed in a question that only “the right answer will do.” In this case, I like a skeptic, a doubter. You can’t doubt that you’re doubting. Doubting is thinking. You know the rest.
Behavioral Interview Question #1
Christin Wiedemann
Senior Director of Quality Engineering
One open-ended question I always ask is a variation of “How do you learn?”
Variations and follow ups include:
· How do you keep your skills up to date?
· What are you learning right now?
· What’s one thing you’d really like to learn?
Why I ask this question
I favor open-ended questions that allow for interpretation and give the interviewee the freedom to provide the answers that make sense to them. I want my questions to spur a dialogue, an exchange of thoughts and ideas. At the same time, I appreciate that any interview situation can be stressful, and that not everyone is used to, or comfortable with, that kind of interaction. I try to make sure to guide the interviewee along with clarifications and follow up questions if I sense they that are unsure of what I’m expecting of them, or how to respond.
Continuous learning is undoubtedly key to thriving and growing, especially in today’s technology sector, and it’s one on my personal core values. The details around how you learn are not that important, and it doesn’t even necessarily matter what you’re learning — I’m looking for passion, curiosity, and drive.
Asking how you learn, and how you keep your skills up to date, helps me understand what you’re interested in, what you’re passionate about, and what motivates you. It gives me a sense for how you view your own growth and professional development, and if you take ownership of your career progression.
What a good answer looks like
A good answer shows that you’ve thought about your own learning, and that growing — personally and professionally — is something that you’re passionate about. You are committed to investing in yourself.
It’s not about how much time you spend, or exactly how you’re learning, or even what you’re learning. Maybe you’re trying to learn Japanese through evening classes, or honing your juggling skills with a friend. Maybe you’re trying to perfect that focaccia recipe. Maybe you’re half-way through a cloud certification, or just starting to learn Rust. What matters to me is that you want to learn, and that you have the drive to do it.
A good answer explains why you enjoy learning, and what motivates you to learn. An extra bonus is if you also talk about how you learn best, whether it’s through studying on your own, in-person classes, or something else altogether. I don’t evaluate you on how you learn, but your ability to talk about it says a lot about how committed you are to continuous learning, and how much you have — or haven’t — thought about it.
I expect you to talk about what you’re interested in learning, at least at a high-level. If you can’t think of anything, not a single thing, that’s definitely a concern to me. We all have areas in which we need to improve, and admitting to it in an interview is not a sign of weakness, and it doesn’t make you look bad. On the contrary, it reflects maturity, self-awareness, and humility — all traits that I value highly. A lack of interest in learning also reflects a lack of curiosity, and I think being curious is an essential trait for a quality engineer.
How you view and approach learning is an important topic in my interviews, but I think it’s also one of the most important questions you can ask yourself.
Behavioral Interview Question #2
Blake Norrish
Senior Director of Quality Engineering
Tell me about a time you had a challenging or negative interaction with a coworker. This could be with your manager, a teammate, a client, or a direct report. If you could do it over, tell me what you would do differently.
Why I ask This question
There are several things I’m looking for when I ask this question.
First: the ability to reflect on your own behavior, to analyze it, and to determine areas for growth or improvement. This is a key behavioral skill and highly corelated with long term career success. I ask this question to see if you think about your own behavior and have areas of it that you are working on.
Second: some amount of conflict is inevitable in collaborative environments like software development teams. I also ask this question to get a sense of how you deal with this conflict.
Lastly: nobody is perfect. I ask this question to see if you are forthcoming and honest enough to admit this and mature enough to have a healthy conversation about your mistakes.
What a good answer looks like
The exact answer will depend on the nature of the interaction you choose to talk about and your experience level- how a director level candidate responds should be different from how an early career engineer responds.
Regardless of your level, I want you to show me that you can talk and reflect on a situation that probably makes you uncomfortable, that possibly paints you in a less-than-best light, one that maybe you aren’t proud of. I want you to discuss what you were thinking at that that time, why you chose to do or say what you did, then talk to me about the impact that behavior had. Lastly, talk to me about how or why you would do it differently, and for extra credit, talk to me about how you’ve been working since that interaction to behave differently next time a similar situation arises.
Here is a contrived summary of a good answer:
I was the lead QE on a recent project. I had several other QEs working for me, but I was not their direct manager. Several weeks in, I noticed one of the QEs was not performing to expectations: they did not complete the sprint work they committed to, and some other work seemed rushed. This was surprising because I had only heard good things about this employee previously.
I confronted the person and told them I expected their performance to improve, and detailed the exact improvements I expected. I told them if they did not improve, I would have to discuss the situation with their manager. They apologized and agreed to try harder. At the time, I felt I was being very professional by not letting this problem get out of hand.
The individual’s performance did not improve, and several weeks later went on a leave-of-absence for personal reasons.
This is where I realized I had made a significant mistake in my earlier interaction: I had assumed laziness or incompetency, but never gave the person the chance to explain-I just told them to improve. My first question to them should have been something like: “Hey, I noticed you struggled to complete work this sprint, is there anything going on I should know about?” Maybe they would have told me, and maybe not, but it would have been better than just assuming they were slacking and warning them to try harder.
Since then I have tried to approach every performance problem with the intent of understanding the problem first, before I jump in to try to solve it. There may be more going on than what I am initially aware of, and any solution I come to before doing this will be premature.
This is obviously a scripted answer created to explicitly show the key points I’m looking for: acknowledgement of a mistake, a plan for improvement, etc. Real answers are never this clean and direct, but that’s ok. Just like for any other response, regurgitating a perfect answer from a mental script will not be as authentic as a response developed in the moment, even if this makes the response a bit longer or roundabout.
Let’s contrast this with a poor answer. Again, contrived for simplicity.
In my last project I was working with a guy named Adam. We were peers on the project so neither one of us was ‘in charge’. Adam loves Playwright, he can’t stop talking about it! BLAH BLAH Playwright BLAH BLAH all the time every day. He wanted to use it on this project, but I thought Cypress would be a safer choice. He wouldn’t take no for an answer, and eventually I relented.
Unfortunately, the client testers struggled with Playwright, and this significantly impacted our velocity. I should have stood up to Adam and convinced him that Cypress would have been better.
This is a poor answer. Why? Because there is no real acknowledgement of a mistake. The response boils down to: I was right, he was wrong, I should have argued harder. This does not demonstrate the emotional maturity nor ability to introspect that I’m looking for in a response. There is no vulnerability, no room to improve. Try harder next time is not a plan.
Team collaboration is challenging and isn’t always rainbows and unicorns. Successful quality engineers (or any role in a team) have the ability to reflect on their own behavior, acknowledge mistakes, and develop strategies for improvement. This question gives the candidate the opportunity to show me these skills.
Behavioral Interview Question #3
Jeff Averill
Director of Quality Engineering
What does being a Champion of Quality mean to you?
Why I ask this question
This is a very broad question. What I like about it is that it shows me not just what the candidate is thinking, but also provides a peek into their work history: what type of environment they have worked in, how their team members perceive them, and what empowerment they have been given, just to name a few. Many places focus on metrics alone for their measure of quality — and being tactical has its advantages. But I want people to think broader than just metrics.
Often quality engineers see defects as an indication of failure. So to be a champion, they need to increase automation coverage, highlight high priority defects to be addressed quickly, review the application from the user perspective. If you take a step back, these answers are all reactionary.
At Slalom Build, being a Champion of Quality is ingrained in our QE Core Principals. Quality engineers have not always had a fair seat at the table in software development. We are aiming to change that, from how we show up on a project to how we can coach and challenge our teams and clients with a Quality mindset. This question helps me understand where a person is coming from and how they view the impact quality engineers can have outside of testing and automation work.
What answers I look for
I want to hear what proactive activities can occur to champion quality. Quality does not come just from testing and automation. There can be all sorts of actions taken before any automation code is written or testing is done:
- Asking targeted questions in refinement and planning
- Asking for clarity on acceptance criteria or even the impact a user story may have more broadly on the application
- Discussing the intended approach with the developer and solution owner
- Walking through designs from a user perspective
- Discussing impacts that changes to functionality will have on other areas of the application
I want my whole team to have a focus on quality. Developers, solution owners, experience designers, everyone should be contemplating the impacts that functional changes will have on a given application.
Many candidates have different answers for this question, as their experience will vary. That is okay! I want to then hear what they have done in the past and what they would want in the future. Answering this question with statements like “fewer Priority 0 bugs” or “higher automation percent coverage” is a decent answer.
I challenge folks to think of the root of quality — where does it come from and how can we work toward that. Take a step back from the current story being worked on and consider more broadly what this questions is asking. What would be their ideal setup for a project? What would need to change to work toward that? Once these are answered, working toward that may be easier than you think.
Behavioral Interview Question #4
Christin Wiedemann
Senior Director of Quality Engineering
What else do you think I should know about you? A variation of this question is: What questions do you think I should have asked, but didn’t?
Why I ask this question
The best interview questions are the ones that spark an interesting discussion, rather than merely prompting an answer. My goal is never to make you as an interviewee struggle, on the contrary — I want the interview to be a good experience for both of us, regardless of whether you will ultimately be joining our team or not. I do, however, want to try to understand if you would be able to succeed, and grow, in the role you are interviewing for. To do this, I will ask you a series of questions that probe a wide range of topics.
I don’t want anyone to leave an interview feeling that they didn’t get a chance to prove themselves; that I didn’t give them the opportunity to highlight their skills and strengths. That’s why I like to leave at least five minutes at the end to ask what else you would like me to know about you, giving you a chance to talk about whatever is important to you.
What a good answer looks like
A good answer talks about what you are proud of, what you are passionate about, and what motivates you. This is truly your moment to shine, so take it and make the most of it. It is also your last chance to tell me what makes you, you. What is unique about you that will make me remember you?
I want you to talk about what matters to you, not what you think I want to, or expect to, hear. What you do exceptionally well, in your personal or professional life? Do you bake amazing cinnamon buns, or maybe you know how to fix a flat bike tire faster than anyone you’ve ever met? Can you visualize and debug complex SQL statements in your head?
How do you make a positive difference, on a team, within an organization, and in society? Tell me about your core values, your life motto, or the mantra you repeat to yourself when you feel stressed or find yourself outside of your comfort zone. What brings you true pleasure and joy in life? Do you like the arts, do you find solace in nature, or do you thrive when playing team sports?
I’m genuinely interested in who you are, and I want to get to know you. There are no wrong answers to this question; any answer that is true to yourself is a great answer.
Thanks for reading!
You made it to the very end! You must be a passionate, motivated individual, and maybe even an aspiring quality engineer. If so, check out our Careers page for open roles in Slalom Build Quality Engineering
For more information on Slalom Build check out SlalomBuild.com, including the Quality Engineering page.
For some first-hand accounts of joining our team, check out these articles from some of our very own quality engineers:
If you want to read more on our approach to Quality Engineering, here are some additional articles:
