Engineering Practice
Putting it together: multiple-choice review
Crux Multiple-choice synthesis across the engineering-practice track — how CI, trunk-based dev, flags, review, on-call, and postmortems form one loop where each link enables the next.
Your altitude — climbing toward senior
ZeroJuniorMiddleSenior
You are at senior altitude — in orbitSix questions that cut across the whole track. Each one is a sequencing or dependency decision a tech lead actually makes — not a definition to recite, but which link of the delivery loop is load-bearing and what happens when you pull it out.
Goal
Confirm you can connect TDD, contract testing, code review, trunk-based development, feature flags, on-call, and postmortems into a single feedback loop — and predict the seam failure when a practice is adopted without its dependency.
Quiz
Completed
Leadership mandates daily deploys to trunk on Monday. The team has a 25-minute, flaky test suite and no feature flags. What is the predictable outcome, and what was the missing dependency?
Heads-up Trunk-based development keeps conflicts small only because integration is frequent AND each merge is gated by a trustworthy build. A slow flaky suite is no gate, so frequency just multiplies broken integrations.
Heads-up CI quality is the precondition for trunk-based development. The branching strategy depends directly on the signal being fast and trustworthy enough to gate every merge.
Heads-up Change-fail rate falls from small batches plus a reliable gate. Without the gate, failures keep slipping to trunk no matter how often you deploy.
Quiz
Completed
A team proudly deploys 40x/day, but change-fail rate is 28% and MTTR is creeping up. In DORA terms, what have they done wrong?
Heads-up Speed and stability are not a tradeoff in the data; elite teams win on all four metrics at once. Slowing down treats the symptom, not the missing dependencies (CI, flags, fast recovery) that make frequency safe.
Heads-up Deployment frequency is a valid DORA metric. The error is reporting it alone, with no change-fail-rate or MTTR metric to govern it.
Heads-up Frequency without a stability metric regresses the system; that is precisely the failure DORA's balanced set is designed to expose.
Quiz
Completed
A service has 340 feature flags, none removed in a year. A config change flips a forgotten 'release toggle' during peak traffic and takes down checkout. Which link of the loop was actually missing?
Heads-up Flags are what let you decouple deploy from release and kill bad code instantly — the Knight Capital lesson. The defect is missing TTL/cleanup, not the existence of flags.
Heads-up On-call catches the incident after the blast; it cannot prevent a stale toggle that should have been removed months earlier. The prevention lives in flag lifecycle, an owned postmortem action item.
Heads-up Blameless analysis looks for contributing factors, not one root cause. The deep contributing factor is flag debt: a release toggle treated as permanent, with no removal step.
Quiz
Completed
An on-call engineer bisects a checkout outage to a single PR in four minutes and recovers by flipping a flag off — no rollback build. Which two upstream practices made that fast recovery possible?
Heads-up Big infrequent releases make blast radius large and bisection slow — the opposite of what enabled the four-minute recovery. The lever was small batches plus a kill-switch.
Heads-up MTTR here was set by batch size and the flag kill-switch, not raw compute or headcount. The same incident on a giant release would still take hours to bisect.
Heads-up More upfront QA lengthens lead time and does nothing for recovery speed once a change is live. Fast recovery comes from small batches and the ability to flip a flag.
Quiz
Completed
The same outage recurs three quarters running, each time with a fresh postmortem doc on the wiki. Which single seam of the loop is broken?
Heads-up Blame makes people hide incidents, so you lose the learning. Recurrence comes from action items never shipping, not from insufficient blame.
Heads-up The count of docs is not the problem — their lack of follow-through is. One postmortem with an owned, shipped action item beats three that nobody acts on.
Heads-up Rotation length does not determine whether a fix ships. The broken link is the absence of tracked action items feeding back into tests, contracts, and flag defaults.
Quiz
Completed
A 20-service org runs full end-to-end integration tests on every merge; the suite is slow and flaky, so engineers mute failures and bugs reach prod. What is the senior fix that keeps the delivery loop intact?
Heads-up Deferring e2e to nightly removes the gate from the merge entirely; broken work lands on trunk all day and you discover it the next morning. The loop needs a fast per-merge signal, which contracts provide.
Heads-up Retrying flaky e2e hides real failures behind green and trains the team to ignore the gate — exactly the muting behaviour that let bugs through. The fix is a faster, deterministic signal, not more retries.
Heads-up Flags decouple deploy from release; they do not validate correctness. Shipping unvalidated code behind flags just hides bugs and grows flag debt. Contracts validate the boundary that unit mocks fake away.
Recap
The through-line across the whole track is one closed loop with a load-bearing order: tests and contract checks make CI a trustworthy gate; that gate makes trunk-based merging safe; trunk-based plus feature flags decouples deploy from release; small frequent deploys keep any escape’s blast radius tiny, where on-call catches it; and a blameless postmortem with owned action items turns the incident into new tests, contracts, and flag defaults — closing the loop. Pull a link out and the downstream practice inverts. And you govern the whole thing with DORA’s four metrics together, never one ceremony in isolation.