Your bug backlog has grown to over 800 open tickets that no one trusts or looks at anymore, and important bugs are getting lost in the noise. As a senior engineer asked to fix the triage process, not just the backlog, how would you approach it?

technical-conceptual · Senior level · software-engineering

What the interviewer is really asking

Assesses whether the candidate can design a sustainable bug lifecycle and triage process — consistent severity/priority criteria, a regular triage cadence, clear states and ownership, and backlog hygiene — rather than running a one-off bug-bash that leaves the same problem to regrow.

What to say

• Fix the inflow, not just the pile: an 800-ticket untrusted backlog is a process failure, so establish a regular triage cadence (e.g. a short triage two-to-three times a week) with consistent, written severity and priority definitions so every incoming bug is assessed promptly and consistently instead of accreting.
• Make the lifecycle explicit: define clear states (new, triaged, accepted, in-progress, fixed, verified/closed, won't-fix) and assign an owner at triage, so a ticket can't sit ownerless — and require enough detail (repro steps, environment, impact) to be actionable, sending back the ones that aren't.
• Clear the existing pile honestly: time-box a backlog review, aggressively close stale, duplicate, obsolete, and won't-fix tickets so the remaining set is real and trusted, then keep it that way with an SLA or aging policy that flags bugs sitting untriaged past a threshold.

What to avoid

• Running a one-time bug-bash to burn down 800 tickets without changing the triage process that produced them, so it regrows.
• Leaving severity and priority to each reporter's gut with no shared definitions, which is what made the backlog untrustworthy in the first place.
• Treating every old ticket as sacred and refusing to close stale or duplicate ones, so the backlog stays too noisy to trust.

Example answers

Strong: An 800-ticket backlog nobody trusts is a broken process, so I'd fix the flow before the pile. I'd stand up a regular triage — a focused 20 minutes a few times a week — with written severity and priority definitions so incoming bugs get assessed consistently and quickly, an explicit lifecycle with clear states, and an owner assigned at triage so nothing sits ownerless. Tickets without repro or impact get bounced back. Then I'd time-box a backlog sweep to close stale, duplicate, and obsolete items so what remains is real, and add an aging policy that flags anything untriaged past a threshold so it can't silently rebuild.

Weak: I'd organize a team bug-bash to work through the 800 tickets and knock the backlog down to something manageable, prioritizing the ones marked critical first so the worst bugs get cleared.