They ask: Have you done performance testing?
You say: I have, and I would be honest about how. I had never been a performance tester. I needed to know whether a platform would survive a thousand people arriving at once, so I set up a load test with an agent's help and ran it for hours.
It found what those tests find. Things that are fine with ten users and not fine with a thousand.
I mention it because it is a real example of the shift. Performance testing used to be a speciality you were hired into, mostly because the tooling was unfamiliar. The tooling is no longer the barrier. Knowing what to simulate and how to read the result is the barrier, and that is judgement.
What I did not know then, and would say now, is that the hard part is choosing the number. A thousand users is a guess unless you know what a normal morning looks like and what the worst one did.
The answer that ends the conversation early: claiming performance testing as a strength on the basis of one exercise. Say what you ran, what it found, and what you still do not know, and honest experience beats an overclaim every time.
They ask: If agents write the tests, why should anyone learn to write them?
You say: Because you cannot evaluate what you have never built, and evaluation is the job now.
The framing I use is that hand-writing automation has become the manual step. It sounds backwards. For years automation was what replaced manual work. Now there is a layer above it, and typing the script yourself is the slow human version of something an agent does quickly.
But the person directing that agent has to know what good looks like. Why a test that depends on another test's state is lying to you. What a failure means when it arrives. Without that you are forwarding output you cannot assess, and everyone in the room can tell within two questions.
The test I would apply to myself is simple. If the agent produced something wrong, would I catch it. If the honest answer is no, then I am not directing anything, and the title on my badge does not change that.
The answer that ends the conversation early: "AI writes the tests now." You have described your own role as unnecessary.
They ask: How does code get to production on your team?
You say: Local first, then a testing environment where both the automated suite and a human have a look, then production. Somebody with a name gives the green light.
That has not changed and I do not think it should. What changed is the volume arriving at the front of it. When changes were typed by hand there was natural friction. That friction is gone, so more arrives at the gate, and the gate has to be faster without becoming ceremonial.
The agent can prepare everything up to the line. Run the suite, diagnose the failures, assemble the evidence, write the summary. Crossing the line is a decision about risk, and a decision about risk needs somebody who can be asked why afterward.
That is not caution for its own sake. Accountability has to land on a person who can explain the reasoning, and no session log has ever been able to do that. When something reaches customers, somebody is asked why it was allowed through. That question needs a person on the other end of it.
The answer that ends the conversation early: "we have a pipeline that deploys automatically." Fine, but they asked who decides. If nobody decides, you are describing the process that produced the outage they are interviewing to prevent.