All jobs / Project / delivery manager
Release Management interview questions
Release Management questions a Project / delivery manager can be asked, from first job to senior. Open one to see the strongest answer and why it works.
The team deployed the new checkout to production on Tuesday behind a feature flag that is still off.
Has the feature been released?
The strongest answer: No — deployed means the code is in production; released means users can use it; separating the two lets us deploy safely and choose the go-live moment and audience deliberately
Why it works: Exactly — deploy and release are different events, and the flag is what gives you a controlled go-live and an instant way back.
- Deploy is not release.
- Deploy: code is in production.
- Release: users can use it.
- Flags separate the two on purpose.
What should a rollback plan contain before a go-live?
The strongest answer: The trigger that decides we roll back and who calls it, the exact steps including data, how long they take, who runs them, and proof it was rehearsed — not “roll back if needed”
Why it works: Right — a rollback plan is a decision plus a rehearsed procedure; the trigger and the owner are the parts everyone forgets.
- Trigger, owner, steps, rehearsal.
- Define what triggers rollback.
- Include data, not only code.
- Rehearse it before go-live.
Your organisation’s change advisory board meets weekly. A production configuration fix is needed today.
How do you handle it?
The strongest answer: I use the emergency change path the policy defines — a named approver, the change recorded and reviewed after — and if this fix recurs I propose making it a pre-approved standard change
Why it works: Exactly — change management has emergency and standard paths for this; using them keeps both the speed and the record.
- Use the emergency path.
- Named approver, recorded after.
- Recurring fixes become standard changes.
- Never change production unrecorded.
Three teams must each deploy their part of one feature: a database change, a backend service and a mobile app update.
How do you coordinate the deployment?
The strongest answer: I agree an order where each step is backward-compatible — database, then service, then app — with one owner and channel for the window, a check after each step, and a rollback per step
Why it works: Right — sequence, compatibility at each step, one coordinator, verification and per-step rollback are what turn three deploys into one release.
- Order, compatibility, one owner.
- Each step backward-compatible.
- Verify after each step.
- Rollback plan per step.
The release includes a data migration the engineers say cannot be reversed once it runs.
What is your rollback plan?
The strongest answer: I push for a two-step migration that keeps the old shape usable during the release; failing that, a tested restore, a rehearsed fix-forward path, and a named person who calls the point of no return
Why it works: Exactly — expand-and-contract removes the irreversibility where it can; where it cannot, restore plus fix-forward plus a named decision is the plan.
- Remove irreversibility where possible.
- Two-step migrations keep a way back.
- Tested restore plus fix-forward.
- Name who calls the point of no return.
After a run of incidents, leadership proposes a monthly release train with a two-week code freeze before each one.
What is your view?
The strongest answer: A month of batched changes makes each release harder to diagnose and roll back; I argue for smaller, more frequent releases with automated checks and rehearsed rollback, and a freeze only around a real external constraint
Why it works: Right — the fix for risky releases is smaller ones with a way back and better checks; a long freeze raises the size of what you eventually ship.
- Batch size is the risk.
- Smaller, more frequent releases.
- Automate checks, rehearse rollback.
- Freeze only for a real constraint.