Describe a time you saw a quality problem coming weeks or months before it manifested. What did you do?

Senior QAs see patterns. The interesting thing isn't that you saw it — it's how you handled the gap between when you knew and when the team knew.

STAR walkthrough — sample answer:

Situation: A previous team was preparing a major migration of customer data from one storage backend to another — driven by a vendor cost decision. The migration was scheduled for a quarter out. About 8 weeks before the planned date, I noticed a pattern: the team's existing migration tooling (used for smaller cutover events) had been built by people who'd since left, was poorly documented, and had been failing intermittently in test runs without anyone treating it as urgent.

Task: I had no formal authority over the migration; I was a senior QA on a different stream. But I could see the trajectory: the small failures were going to scale up under the larger migration's load, and there was no time being budgeted for migration-tooling work.

Action: I didn't escalate cold. First I gathered evidence:

• Quantified the existing tooling's failure rate in CI runs (around 12% over the previous quarter, with no triage).
• Interviewed the engineer who currently maintained it — they confirmed they were "vaguely worried" but it wasn't on their priority list.
• Built a rough estimate of what could go wrong under the larger migration: data inconsistency for some customer segments, partial cutover requiring rollback, the kind of incident that would be a multi-day recovery.

I took a one-page risk write-up to the engineering manager owning the migration. Framed it as a pre-mortem: "if this migration goes badly, here are the most likely causes; here's the evidence each is real; here are three preventive options sized in eng-weeks."

The manager initially pushed back ("we'll handle it as we get closer"). I asked for one specific thing: a 1-hour spike to validate the riskiest scenario, then re-evaluate. They agreed. The spike confirmed the concern — under simulated load, the existing tooling couldn't handle the volume.

Result: The team allocated 2 weeks of dedicated migration-tooling work in the sprint after the spike. They rebuilt the orchestration layer, added robust retry and resume logic, and ran two full dress-rehearsals before the real cutover. The migration went out clean — about 20 minutes of partial-availability for a small segment and full recovery without manual intervention. The migration manager later told me the early write-up had been the trigger that changed their planning.

What I learned: pattern-recognition is necessary but not sufficient. The senior skill is the delivery of the warning — evidence, pre-mortem framing, a small specific ask that gets to validation cheaply.

Why this works: shows the candidate did real legwork to validate the pattern, used a pre-mortem rather than alarmism, gave the decision-maker a low-cost path to validate, and the outcome was a successful migration rather than an avoided disaster.