Q19 of 32 · Behavioural

Tell me about a time you joined a team and inherited a messy test suite. What was your approach?

BehaviouralMidbehaviouraljoining-teamtest-suitehumilitystarmid

Short answer

Short answer: Resist the urge to rewrite. Investigate why it grew the way it did, talk to people, find the highest-pain points, and intervene surgically before you suggest broader change. Joining-team trust is earned by listening before proposing.

Detail

New-joiner behavioural questions test whether you'll come in and break things or come in and listen. The right answer balances initiative with humility.

STAR walkthrough — sample answer:

Situation: I joined a team about 18 months ago that had a Cypress E2E suite of around 400 tests. PR feedback was 25+ minutes, flake rate was high enough that re-runs were the norm, and several tests had .skip() with comments like "TODO investigate." My new manager mentioned the suite as a known pain in my first week.

Task: Improve the suite, but without coming in as the new person who criticises everything.

Action: First two weeks: pure listening mode.

  • Ran the suite locally, took notes on which tests flaked.
  • Read the git blame on the worst tests — most had been written under deadline pressure by people who'd since left or moved teams.
  • Talked to the four engineers who interacted with the suite most — asked what frustrated them, what they wished worked, what they'd already tried.

Two patterns emerged: (a) the team didn't trust the suite, so they bypassed it (--skip-tests on PRs); and (b) the existing convention was to add tests for every bug, leading to a suite that tested implementation details rather than user behaviour.

I picked one surgical intervention to start: rewrote the 12 worst-flaking tests using better wait strategies and removed the 8 tests that were duplicating unit-level coverage. Submitted as one focused PR with a write-up: "20 tests touched, runtime down 4 min, flake rate of these specific tests went to zero in 50 local re-runs."

That visible win earned permission for a broader conversation. I proposed (in a team retro) a "quality bar for new tests" — no new tests without a clear user-behaviour reason, no .skip() without an owner and a deadline. The team agreed.

Result: Over the following quarter, the suite went from 400 tests / 25 min / 15% flake rate to 320 tests / 11 min / under 2% flake. The bigger change was cultural: PR --skip-tests became rare because the suite was trusted again.

What I learned: messy test suites are usually the residue of past good intentions under pressure. Treating them as "previous people's incompetence" misses that, and it'll alienate the team. Listening earns the right to change things.

Why this works: shows humility on joining, deliberate investigation, surgical first intervention to earn trust, and broader change rooted in team agreement rather than imposition.

// WHAT INTERVIEWERS LOOK FOR

Listening before proposing, surgical first intervention to earn trust, and team-led broader change rather than imposition. The signal of maturity is treating prior decisions as having reasons, not as failures to be fixed.

// COMMON PITFALL

Coming in with a 'rewrite from scratch' instinct. Interviewers read this as someone who'll create churn and alienate teammates. The strong version respects past work even while changing it.