Automation Engineer interview questions and how to answer them
Automation interviews reward people who've watched their own work break. Most questions are really asking whether you can keep a test suite or a control system trustworthy after the demo is over. Expect a mix of talk, live code or logic, and a war story or two.
What happens in each round
- 1
Recruiter screen
What happens
Which side you come from, software automation or plant controls, which languages or platforms you've used for real, and whether your expectations fit the role.
- 2
Hiring manager conversation
What happens
How you decide what's worth automating, how you've worked with developers or operators, and whether your past projects stayed useful after you shipped them.
- 3
Technical exercise
What happens
On the software side, writing a small test against a web page or an API, often in a shared editor. On the controls side, reading or writing a chunk of ladder logic, or walking through a fault on a drawing.
- 4
Design or system round
What happens
Whether you can lay out a test framework, a pipeline, or a control sequence that other people could maintain without you in the room.
- 5
Team fit and behavioral
What happens
How you handle pressure at release time or during a line outage, and how you push back when someone wants a shortcut that'll hurt later.
Questions you're likely to get
1.How do you decide which tests to automate and which to leave manual?
Why they ask
Teams that automate everything end up with slow, brittle suites nobody trusts. They want to see judgment, not enthusiasm.
How to answer
- Automate checks that run often, are stable, and would hurt badly if they broke, like login, checkout, or core API contracts.
- Leave exploratory work, one-off checks and fast-changing UI to people until the design settles.
- Mention cost: every automated test is code someone has to maintain.
- Give a real case where you chose not to automate something and why.
2.Tell me about a flaky test you tracked down. What was causing it?
Why they ask
Flaky tests are the daily reality of this job. How you handle them tells them whether the suite will stay trusted with you on it.
How to answer
- Describe the symptom plainly: which test, how often it failed, and where it failed (local or CI).
- Walk through how you narrowed it down, such as rerunning with logs, video, or a trace viewer.
- Name the real cause: a race with an async call, shared test data, a hard-coded wait, an environment difference.
- Explain the fix and what you changed so the same class of problem wouldn't come back.
3.How would you structure a UI test framework for a new web app?
Why they ask
They want to see whether you can build something the next person can pick up, not just scripts that work on your laptop.
How to answer
- Pick a tool and say why, for example Playwright for built-in waiting and parallel runs.
- Separate page objects or components from test logic so a UI change is fixed in one place.
- Handle test data deliberately: create it through the API, clean it up, don't depend on test order.
- Wire it into CI with clear reports, screenshots on failure, and a way to run a single test locally.
4.Where should most of your tests live: UI, API, or unit level?
Why they ask
It checks whether you understand the test pyramid and the cost of slow, end-to-end checks.
How to answer
- Most coverage belongs at the unit and API level because it's fast and precise.
- Keep UI tests for the handful of journeys a real user must complete.
- Say you'd work with developers so unit coverage isn't left entirely to them or entirely to you.
- Mention a time you moved a slow UI check down to the API and what it saved.
5.Walk me through how your tests run in a CI/CD pipeline.
Why they ask
Automation that only runs when someone remembers to click a button isn't automation. They want to know you've owned the pipeline side.
How to answer
- Name the tool you've used, such as Jenkins or GitHub Actions, and what triggers the run.
- Explain which suites run on every pull request and which run nightly.
- Describe how results show up: a failed check that blocks the merge, a report, a message in Slack.
- Talk about keeping it fast, through parallel runs, containers, or splitting suites.
6.How do you test an API that depends on a third-party service you don't control?
Why they ask
Real systems call payment providers, email services and partner APIs. They want to see you can test around them without flaky results.
How to answer
- Use mocks or a stub server for most runs so tests are fast and repeatable.
- Keep a small set of contract or sandbox tests against the real service to catch changes.
- Check error handling: timeouts, bad responses, rate limits.
- Be honest that mocks only prove the shape you gave them.
7.A production line stops and the HMI shows a fault you haven't seen before. What do you do?
Why they ask
For controls roles, this is the job. They're checking whether you stay calm, work safely, and troubleshoot in order.
How to answer
- Start with safety: talk to the operators, follow lockout procedures, don't bypass interlocks to get running.
- Go online with the PLC and trace the fault back through the logic to the input that triggered it.
- Check the physical side next, like a sensor, a loose wire, or a stuck valve, before assuming the code is wrong.
- Document the cause and the fix so the night shift isn't guessing next time.
8.How do you make PLC code that someone else can maintain?
Why they ask
Plants live with a program for a long time. The person who wrote it is often long gone when it breaks.
How to answer
- Use clear tag names and comments that describe what the rung does in plain words.
- Break the program into routines or function blocks by machine section.
- Keep version control or at least a disciplined backup and change log.
- Follow the plant's own standard, even when you'd have done it differently.
9.Tell me about something you automated that turned out not to be worth it.
Why they ask
People who've done this job for real have at least one of these. It shows self-awareness and a sense of cost.
How to answer
- Pick a real example, like a UI suite for a screen that kept changing, or a tool nobody adopted.
- Explain what you expected and what actually happened.
- Say what you'd do differently, such as starting smaller or asking the users first.
- Keep it short and don't blame others.
10.How do you handle a developer who says your failing test is wrong, not their code?
Why they ask
Automation engineers spend a lot of time delivering bad news. They want to know you can do it without starting a feud.
How to answer
- Look at the failure together, with logs, screenshots or a trace, instead of arguing in chat.
- Admit it quickly when the test is the problem and fix it.
- When it's a real bug, show the steps and let the evidence make the case.
- Mention how you build trust so failures get taken seriously.
11.What would you do in your first month here?
Why they ask
They want to know whether you'll listen before you rebuild everything.
How to answer
- Learn the product or the plant, and run the existing suite or program yourself.
- Find what people complain about most, like the slowest pipeline step or the most frequent fault.
- Pick one small, visible fix and ship it.
- Hold off on rewriting the framework until you understand why it looks the way it does.
Mistakes that sink good candidates
Listing tools you've barely touched
Interviewers will hand you a keyboard and ask you to use them.
Blaming flaky tests or faults on the environment without explaining how you'd prove it
Brushing past safety in a controls interview, even as a joke about getting the line back up
Talking only about writing automation and never about maintaining it
Need more Automation Engineer interviews to prep for?
HeroApply applies to Automation Engineer jobs that match you, every day. 1,843 jobs are open today.