Before You Automate, Ask Better Questions
What a simple interview prompt revealed about mindset
I often ask candidates to automate a short flow:
Go to the dashboard
Log in with default credentials
Create a new user
Log out and log in again as the new user
Most people jump straight to tools. “I’ll use Selenium, Cypress, or Playwright. I’ll open the browser, click here, then there.” That tells me they can script. It does not tell me they can test.
Quick pause: if you’re finding this interesting already, hit subscribe to LifeOfQA so you don’t miss future posts like this.
This post is about what I expected to hear, why it matters, and what both candidates and hiring managers should take from this.
What I heard vs what I hoped to hear
What I heard:
A list of steps and a tool name. No questions about purpose, risk, or the layer where this check belongs.
What I hoped to hear:
Short, clear questions that reveal intent.
What are we trying to learn? Which layer is appropriate? Is this for regression, smoke, or only to seed data? What are the constraints around data, environments, and CI?
I was not looking for a perfect framework plan. I was looking for judgment.
Why candidates jump straight to tools
Industry pressure: tool names get treated like skill badges.
Past incentives: teams reward the count of tests, not the value of information.
Interview anxiety: naming a popular tool feels safer than probing the problem.
Habits from tutorials: most teach clicking paths, not test design.
None of this makes someone a bad tester. It shows where the focus has been. The fix is to practice asking for context first.
Why context questions matter
Signal over noise: without a goal, you collect the wrong signals.
Right layer, less pain: where you automate decides stability, speed, and cost.
Faster feedback: good questions surface constraints early and save weeks later.
Shared understanding: when a tester seeks purpose, developers trust the checks more.
What I mean by “automation mindset”
Automation is a way to learn about the product at speed.
Context first. Layers next. Tools last.
Choose the lightest check that gives the most useful information with the least noise.
Treat data, cleanup, and reporting as part of the design.
What candidates should do in this question
You do not need to pitch a tool. Start with curiosity.
Ask for the purpose of the check.
Clarify what success looks like.
Identify the layer where the signal is strongest.
Call out constraints like unique data, environment limits, and CI.
Explain the tradeoffs simply.
That is enough to show judgment.
Why hiring managers should keep asking this question
It exposes thinking in minutes.
It separates tool driving from test design.
It spotlights communication, risk sense, and pragmatism.
It predicts maintenance cost and CI health better than a code kata.
A simple rubric helps: Did they seek context, choose a sensible layer, consider data and CI, and explain tradeoffs clearly?
Takeaways
Do not start with which tool. Start with what we want to learn.
Good automation is not about reproducing clicks. It is about producing insight.
Asking for context is not delay. It is design.
Hiring or interviewing, look for curiosity before code.
If you found this helpful, stay connected with Life of QA for more real-world testing experiences, tips, and lessons from the journey!