Passing the QA Interview in the Era of AI Development

AI did not remove QA from the room.

It changed the room.

That is the simplest way to look at QA interviews in 2026. The old interview was often:

• write test cases for a login form;
• explain smoke vs regression;
• automate a button click with Selenium;
• maybe write a SQL query;
• maybe explain HTTP status codes.

That stuff is still alive. But now there is a new layer on top:

• Can you test software that was partly generated by AI?
• Can you use AI without trusting it blindly?
• Can you review AI-generated tests?
• Can you explain risk, coverage, and product behavior like an adult?
• Can you debug flaky automation instead of generating more flaky automation?
• Can you test AI features themselves: chat, voice, summarization, classification, agents, recommendations?

That is the real interview now.

Not “do you know ChatGPT?”

More like: can you stay useful when everyone has ChatGPT?

The current reality: AI is everywhere, but maturity is uneven

The QA market is not in the “AI someday” phase anymore. It is already here.

PractiTest’s 2026 State of Testing report says 76.8% of respondents use AI in their organization, and 78.8% see AI as the most impactful testing trend for the next five years. The same report also shows anxiety: 65.6% of professionals are “very concerned” about the future of the profession. The interesting part is that hands-on users are less anxious than non-users. In other words, fear goes down when people actually touch the tools instead of doomscrolling about them.

Capgemini’s World Quality Report 2025-26 gives a more enterprise-heavy view: 43% of organizations are experimenting with GenAI in Quality Engineering, but only 15% have scaled it enterprise-wide. That gap matters. It means companies are interested, but most of them are still messy, experimental, and figuring things out. The same report says GenAI is now the top-ranked skill for quality engineers, but core quality engineering skills and communication are still close behind.

Google’s 2025 DORA research says AI adoption among software development professionals reached 90%, with a median of two hours per day spent using AI. Over 80% reported productivity gains, and 59% reported positive impact on code quality. But the same report also says trust is still limited: only 24% trust AI “a lot” or “a great deal”, while 30% trust it “a little” or “not at all.”

Stack Overflow’s 2025 Developer Survey tells the same story from another angle: more developers distrust the accuracy of AI tools than trust them. That is not anti-AI. That is normal engineering. Useful output still needs verification.

So the market signal is pretty clear:

AI literacy matters now. Blind AI faith does not.

That is exactly how you should approach the interview.

What interviewers are really trying to detect

A good interviewer is not impressed because you can say “I use AI for test case generation.”

Anyone can say that.

They want to know whether you can use AI in a controlled way. They are trying to detect these things:

1. Do you still know testing basics?
   AI can draft test cases, but it cannot understand the product better than the team unless someone gives it context.

2. Can you validate AI output?
   Generated tests can look clean and still miss the actual business risk.

3. Can you debug?
   Modern QA is not only clicking through screens. It is logs, APIs, CI failures, network calls, test data, flaky tests, and unclear requirements.

4. Can you think in risk?
   The best QA people do not test everything. They know what would hurt the user or the business if it broke.

5. Can you work with developers using AI?
   If developers generate more code faster, QA must be better at reviewing, prioritizing, and building safety nets.

6. Can you test AI-powered features?
   LLM features are probabilistic. Voice AI has transcription errors. Recommendation systems have bias and ranking problems. Agents can do the wrong thing confidently.

This is where a QA engineer can still be very valuable.

Actually, more valuable than before — if you are not just a manual clicker waiting for perfect tickets.

The wrong answer: “AI will write all tests”

This is the answer that makes you sound like you watched three LinkedIn videos and stopped thinking.

AI can help with:

• generating draft test ideas;
• converting acceptance criteria into scenarios;
• writing boilerplate automation;
• summarizing logs;
• explaining unfamiliar stack traces;
• producing test data variations;
• reviewing a test plan for missing coverage;
• generating API test examples;
• rewriting bug reports more clearly.

But it is not a magic QA brain.

A 2025 practitioner study on LLMs in software testing found that testers use LLMs for test cases, automation, and documentation, but their process is iterative: define testing objectives, prompt, refine, evaluate output, and validate carefully because of hallucinations and inconsistent reasoning.

That is the attitude you want in interviews.

Say something like:

I use AI as a testing assistant, not as the source of truth. I can ask it for test ideas, edge cases, boilerplate automation, or log summaries, but I still validate against requirements, actual product behavior, risk, and test execution results.

That sounds mature.

“AI writes my tests” sounds lazy.

The new QA profile: hybrid, but not fake-SDET

A lot of people panic and think they now need to become a full backend engineer, ML engineer, DevOps engineer, security engineer, and prompt engineer at the same time.

No.

But you do need to become less narrow.

The modern QA profile is hybrid:

Notice something: AI is only one row.

It is important, but it sits on top of the basics.

If you do not understand testing, AI gives you faster nonsense.

What to say when they ask: “How do you use AI in QA?”

Do not give a philosophical answer.

Give a workflow.

Bad answer:

I use AI to automate testing and improve productivity.

That says nothing.

Better answer:

I use AI in four places. First, during test design, I give it a user story and ask for missing negative cases, boundary cases, and possible ambiguity. Second, during automation, I use it to draft boilerplate code, but I review selectors, assertions, waits, and data setup myself. Third, during debugging, I paste sanitized logs or stack traces and ask for hypotheses, then verify them manually. Fourth, I use it to improve bug reports or summarize test results for non-technical people. I do not paste secrets or customer data into public tools, and I do not merge generated code without running it.

That answer has everything:

• practical use;
• security awareness;
• verification;
• understanding of test design;
• communication;
• no hype.

That is what you want.

What to say when they ask: “Will AI replace QA?”

Don’t be dramatic.

Say:

AI will reduce repetitive QA work, especially boilerplate test writing, simple regression generation, and log summarization. But it increases the need for people who can define coverage, review generated output, test business logic, validate AI behavior, investigate production issues, and explain release risk. The weak version of QA gets automated. The strong version becomes more strategic.

That is the correct angle.

Manual testing as “click these 40 scripts every release” is in trouble.

Manual testing as exploratory thinking, product risk, usability, business logic, and release judgment is not dead.

Automation as “copy-paste Selenium scripts” is in trouble.

Automation as test architecture, CI stability, data strategy, and debugging is not dead.

AI-generated code makes QA more important, not less

One reason QA still matters: AI can increase the amount of code and change velocity.

That can be good. It can also produce more review burden.

A 2025 randomized controlled trial on experienced open-source developers found that early-2025 AI tools actually slowed developers down by 19% in that study, even though developers expected speedups. The authors studied 16 developers working on 246 real tasks in mature repositories. This does not prove AI is bad everywhere. It proves the real world is more complicated than demos.

Google’s DORA report makes a similar practical point: AI can act as a “mirror and multiplier.” In strong teams, it can boost efficiency. In weak teams, it can expose or amplify existing problems.

That is a very QA-friendly argument.

If AI helps developers ship faster, then teams need:

• better automated checks;
• better code review;
• better rollback strategy;
• better test data;
• better monitoring;
• better exploratory testing;
• better release risk decisions.

So in an interview, don’t position yourself as the person fighting AI.

Position yourself as the person who helps the team use AI without shipping garbage.

Testing AI features is now a real skill

If the company has AI features, your normal QA checklist is not enough.

For example, a voice AI research app is not just “does the button work?”

You need to test:

• microphone permissions;
• noisy audio;
• accents;
• interruptions;
• partial speech;
• incorrect transcription;
• slow network;
• retry behavior;
• hallucinated summaries;
• privacy boundaries;
• prompt injection;
• personally identifiable information handling;
• fallback messages;
• rate limits;
• model latency;
• regression across prompt/model changes;
• human review flows;
• audit logs.

For LLM-based features, you may need eval-style thinking:

• What should the model never say?
• What answers are acceptable but not exact?
• What is a failure?
• What is a severe failure?
• How do we compare version A and version B?
• What test set do we keep stable?
• What do we monitor after release?

This is where QA can move closer to product quality and safety.

You do not need to be a machine learning scientist to test AI features. But you do need to understand that AI output is probabilistic and context-sensitive. A test can pass ten times and still fail on the eleventh. So you need better sampling, stable evaluation data, thresholds, logs, and human review.

The interview questions are changing

Here are the kinds of questions I would expect now.

This is not sci-fi. It is basically normal QA, but with AI added to the workflow.

What you should prepare before the interview

Do not prepare only theory.

Prepare proof.

1. A small automation repo

Have one clean repo with:

• Playwright or Selenium tests;
• API tests;
• GitHub Actions;
• screenshots or traces on failure;
• README with setup steps;
• clear test structure;
• a few negative tests;
• one example of test data setup.

It does not need to be huge. It needs to be clean.

A small stable repo is better than a giant broken “framework” copied from YouTube.

2. A test strategy example

Take a fake product, like:

• login + payments;
• AI chatbot;
• voice note summarizer;
• mobile banking app;
• browser extension;
• API for orders.

Write a one-page test strategy:

• scope;
• risks;
• test levels;
• data;
• automation approach;
• non-functional checks;
• what you would not automate;
• release criteria.

This shows you can think, not just code.

3. An AI-assisted workflow example

Show how you use AI responsibly.

Example:

• user story;
• your prompt;
• AI output;
• your review notes;
• final test cases;
• what you removed;
• what you added manually.

This is powerful because most candidates will just say “I use ChatGPT.” You show actual process.

4. A bug report sample

Have a bug report that includes:

• title;
• environment;
• steps;
• actual result;
• expected result;
• evidence;
• logs;
• severity;
• impact;
• possible area of failure.

Bonus points if you show a before/after where AI helped you rewrite it more clearly but you kept the technical accuracy.

5. One debugging story

Prepare a story like this:

A CI test was flaky. I checked the video/trace, saw that the request finished but the UI state was not updated yet. The test was waiting for an element too early. I changed the wait to assert on the actual network/user-visible state and cleaned up test data between runs. Flakiness dropped.

That sounds like real automation.

Not course automation. Real automation.

Tools to mention without sounding like a tool collector

You do not need to list 47 tools.

Pick a practical stack.

For web QA:

• Playwright or Selenium;
• Postman, Bruno, Insomnia, or REST Assured;
• GitHub Actions / GitLab CI / Jenkins;
• Docker basics;
• SQL basics;
• browser devtools;
• Allure or built-in reports.

For mobile QA:

• Appium;
• Espresso/XCUITest basics if relevant;
• Android Studio / Xcode basics;
• ADB;
• Charles / Burp / mitmproxy;
• logs;
• device farms if relevant.

For AI-era QA:

• ChatGPT / Claude / Gemini for test design and review;
• GitHub Copilot / Cursor / JetBrains AI if you code;
• AI-assisted log analysis;
• visual testing tools if the company uses them;
• test management tools with AI features if relevant.

Do not pretend every AI testing platform is amazing.

Practitioner discussions in QA communities are pretty skeptical. People are trying tools like Mabl, Testim, Applitools, QA Wolf, Katalon, Functionize, self-healing tools, and no-code platforms, but the common question is still: “what is actually worth it vs fancy Selenium/Playwright with marketing?”

That skepticism is healthy.

Say:

I am open to AI testing tools, but I evaluate them by stability, maintainability, integration with CI, ability to handle real test data, debugging quality, and whether they reduce maintenance instead of hiding it.

That is a professional answer.

What not to say

Avoid these:

AI will replace QA soon.

Lazy and not useful.

I don’t use AI because real testers don’t need it.

This sounds outdated.

I use AI to generate all my automation.

This sounds dangerous.

Manual testing is dead.

No. Bad manual testing is weak. Exploratory testing is not dead.

Automation means 100% coverage.

No. That phrase should be illegal.

I can test anything.

No, you cannot. Good QA people know constraints.

I don’t need to understand code because AI can write it.

This is the fastest way to fail an automation interview.

A better way to describe yourself

Try this positioning:

I am a QA engineer who can test manually, automate where it makes sense, use AI to speed up test design and debugging, and still think critically about risk. I do not treat generated output as truth. My goal is not just more tests. My goal is useful coverage, stable feedback, and fewer surprises in production.

That is the modern QA pitch.

It is simple. It is not desperate. It does not sound like LinkedIn slop.

The basics still matter

This is the part people forget.

AI does not excuse you from knowing:

• HTTP basics;
• JSON;
• SQL joins;
• browser devtools;
• mobile logs;
• cookies and sessions;
• authentication;
• test data cleanup;
• assertions;
• CI failures;
• version control;
• selectors;
• waiting strategies;
• boundary testing;
• risk-based testing.

Actually, AI makes fundamentals more important.

Because now you are reviewing generated output. If you do not know what good looks like, you cannot tell when AI gives you garbage.

Google Cloud’s TDD/AI guidance says AI output should be funneled into pipelines guarded by version control, automated tests, and human review. It also says 62% of developers who write tests use AI to assist them, but strong quality practices are still needed because AI can increase instability if used without controls. That is basically the whole game.

Use AI. But keep the guardrails.

How to answer the classic “test this login page” question in 2026

Do not roll your eyes. They still ask it because it shows how you think.

A modern answer:

1. Confirm the basics:

   • valid login;
   • invalid password;
   • unknown user;
   • empty fields;
   • email format;
   • password rules.

2. Add security:

   • brute-force protection;
   • rate limiting;
   • account lockout;
   • session expiration;
   • CSRF if relevant;
   • password reset flow;
   • MFA if supported.

3. Add UX:

   • useful error messages;
   • accessibility;
   • mobile layout;
   • loading states;
   • keyboard navigation.

4. Add API:

   • status codes;
   • response body;
   • token/cookie handling;
   • invalid payloads;
   • expired tokens.

5. Add automation strategy:

   • smoke test for valid login;
   • negative API tests;
   • avoid automating every UI error;
   • mock or seed users;
   • run in CI;
   • capture trace/video on failure.

6. Add AI-era note:

   • use AI to generate an initial checklist;
   • review it against actual requirements;
   • remove duplicates;
   • add missing business/security cases;
   • never expose real credentials to public tools.

That answer shows you understand both old and new QA.

How to talk about AI honestly

Here is the balanced version:

AI is useful for speed.

It is weak at accountability.

AI can generate ten scenarios quickly.

It does not know which scenario matters most unless you guide it.

AI can summarize logs.

It can also hallucinate a root cause.

AI can write Playwright code.

It can also write bad waits, weak assertions, duplicated tests, or selectors that explode next week.

AI can help with bug reports.

It can also make them vague and polished instead of precise.

So your job is to be the filter.

That is a good thing.

Because filters with judgment still get paid.

Example interview answer: AI-generated automation

Question:

Would you accept a pull request with tests generated by AI?

Answer:

I don’t care whether the first draft came from AI or a human. I care whether the test is valuable and maintainable. I would review if it maps to a real requirement or risk, whether assertions verify behavior instead of implementation details, whether data setup is isolated, whether selectors are stable, whether it runs in CI, and whether failure output is useful. If it is just more brittle UI coverage, I would push back.

This is a strong answer because it refuses the fake debate.

The issue is not “AI or no AI.”

The issue is quality.

Example interview answer: testing an LLM summarizer

Question:

How would you test an AI summarization feature?

Answer:

I would split it into deterministic and non-deterministic checks. Deterministic checks include permissions, file upload, input limits, empty input, unsupported formats, latency, errors, retries, and data privacy. For the model output, I would build a stable evaluation set with expected criteria rather than exact strings. I would check factual correctness, missing critical details, hallucinated details, tone, language handling, and safety constraints. I would also test prompt injection, PII handling, and regression between model or prompt versions. For release, I would track failure categories and define what severity blocks release.

That is the kind of answer companies want now.

The human part still matters

LinkedIn’s 2025 skills research lists AI literacy and LLM proficiency among fast-growing skills, but communication, strategic thinking, and adaptability also keep showing up.

WEF’s Future of Jobs 2025 report says employers expect 39% of workers’ core skills to change by 2030.

So yes, learn tools.

But do not become a tool zombie.

In interviews, the strongest candidates explain:

• what risk they saw;
• why they tested something;
• why they automated something;
• why they did not automate something;
• what trade-off they made;
• how they communicated it;
• how they used AI;
• how they verified AI was not lying.

That is how you sound senior.

A practical 30-day prep plan

Week 1: Refresh the base

• HTTP methods and status codes.
• API testing basics.
• SQL SELECT/JOIN/GROUP BY.
• Browser devtools.
• Test design techniques.
• Bug report writing.

Week 2: Automation cleanup

• Pick Playwright or Selenium.
• Create a small test repo.
• Add CI.
• Add screenshots/traces/reports.
• Add README.
• Add API tests.

Week 3: AI workflow

• Use AI to generate test ideas from a user story.
• Review and improve them.
• Save the before/after.
• Use AI to explain one flaky test.
• Use AI to improve one bug report.
• Document what you accepted and rejected.

Week 4: AI feature testing

Prepare one testing strategy for:

• chatbot;
• voice transcription;
• summarizer;
• recommendation system;
• AI agent that performs actions.

Pick one and make it solid.

You do not need five fake projects. You need one good example you can explain.

Final checklist before the interview

Can you answer these without sounding like a blog post?

• How do you decide what to automate?
• How do you review AI-generated tests?
• How do you test an AI feature?
• How do you debug a flaky test?
• How do you test an API endpoint?
• How do you explain release risk?
• How do you handle unclear requirements?
• How do you use AI without leaking sensitive data?
• How do you know if your tests are useful?
• What did you improve in your last QA process?

If yes, you are in decent shape.

If no, fix that before memorizing another list of Selenium commands.

Final thought

The QA interview in the AI era is not about pretending to be a machine learning expert.

It is about proving that you are still useful when machines can generate drafts.

That means:

• better judgment;
• better risk thinking;
• better debugging;
• better communication;
• better automation discipline;
• better understanding of AI failure modes.

AI can help write tests.

It cannot decide what quality means for the product.

That is still your job.

For now, anyway.

And honestly, that is the interesting part of QA.