DevOps Culture and Delivery Practices Questions

Direct answer

I would first measure where the two days go, because most of the delay is usually waiting for a reviewer to start, not time spent reviewing. Then I would change a few things in each area (policy, tooling, habits), keeping the review's purpose intact: catching problems and spreading knowledge. Every speed-up has a cost to quality, so I name it and add a safeguard.

Measure first

Illustrative: of about 48 elapsed hours, a PR (pull request: a proposed change awaiting review) spends 44 hours waiting for a first response and 4 hours in actual review and revision. Queue time is 44 / 48 = about 92 percent. If that is the shape, the fix is making review start sooner, not making reviews shorter.

Changes and the quality risk each introduces

Order of rollout

1. Publish the response expectation and turn on automatic assignment (cheap, immediate).
2. Move mechanical checks to automation, so reviews get shorter.
3. Encourage smaller changes, which compounds: smaller PRs are picked up sooner.
4. After a month, re-measure queue time and also check escaped defects (bugs found after merging) so the quality side is visible.

Example author-context template (pasted into every PR description)

What: Add retry with backoff to the invoice export job.
Why: Exports failed about once a day when the storage service timed out.
How tested: Unit tests for 3 retry cases; ran an export of 5,000 invoices in staging.
Look closely at: the retry limit in export_job.py (is 3 attempts enough?).

Four short lines let a reviewer start without a conversation, which is where much of the waiting disappears.

What would change my call: if reviews are slow because only one person understands the code, no policy fixes that; the real work is spreading knowledge, for example by pairing and rotating reviewers.

Pitfall: declaring victory on review speed alone. If defects reaching production rise as waiting falls, the speed-up has been bought with quality.

Position. I would not skip review, but I would not answer a flat "no" either. I would turn "skip review" into "what is the cheapest safe way to hit the date". Code review means a teammate reads a change before it merges, to catch defects, share knowledge and keep to team standards.

Steps, in order

1. Ask what the deadline is and what happens if it slips. A contractual launch date and a "would be nice by Friday" need different answers. Ask the stakeholder what they are actually worried about: usually it is waiting time, not review itself.
2. Find where the time really goes. Often the delay is a pull request (PR, a proposed change awaiting review) sitting a day before anyone looks, not the 20 minutes of reading.
3. Offer relaxations that keep the safety.
   • Review turnaround: a same-day review rota (a schedule naming who is on duty to review each day) for the sprint (illustrative: first response within 4 hours).
   • Smaller PRs: several 200-line changes are faster and safer to review than one 1,500-line change.
   • Risk tiers: a deep review (two reviewers) only for code touching payments, authentication or data migrations; one reviewer for ordinary changes; a post-merge review (the change merges first and a teammate reads it afterwards, within one business day) for text or config tweaks. Risk tiers means sorting changes by how much damage a mistake could do and matching review effort to that.
   • Pairing as live review: pairing means two people writing the risky part together at one screen, so the second person's reading happens live and replaces a later review.
   • Keep the automated checks (tests, linting, and secret scanning, which automatically detects passwords or keys accidentally committed into code): they cost no human time.
   • Decouple merging from releasing: put unfinished work behind a feature flag (a switch that hides code from users), so a merge does not mean users see it.
   • Cut scope instead of cutting checks, which is the trade the stakeholder can own.
4. Write down what was accepted. One line in the ticket: which tier was relaxed, who approved, when the post-merge review happens.

Worked example (illustrative). Launch in 10 working days, 6 PRs left, each building on the previous one so they cannot be reviewed in parallel. Assume an 8-hour day and about 2 hours of actual reading and fixing per PR (0.25 day). With a one-day wait for a first response, each PR takes 1 + 0.25 = 1.25 days, so 6 x 1.25 = 7.5 days of the 10. With a 4-hour rota (0.5 day wait), each takes 0.5 + 0.25 = 0.75 days, so 6 x 0.75 = 4.5 days. The rota saves 3 days without removing a single review. The two PRs touching billing keep two reviewers; the four copy and layout PRs get one reviewer, except that a change that only edits text may merge first and be read within one business day.

What would change my call. A live outage or a legal deadline justifies an emergency path: merge with one named approver and a mandatory post-merge review the next business day. I would never relax review on security-sensitive code without a compensating control.

Closing the loop. Tell the stakeholder what they get (date held) and what the risk is in plain words; after launch, report whether the relaxed tiers produced defects.

What I would actually say to the stakeholder (illustrative)

"I can hold the date, and I do not want to skip review, because review is what catches the bugs that would cost us a bad launch week. What I can change is the waiting. Today a change sits about a day before anyone looks at it. For the next 10 days I will set up a review rota so every change gets a first look within 4 hours, and I will split the work into smaller pieces. That saves about 3 days. The two billing changes keep two reviewers because a mistake there costs real money. The four copy and layout changes get one reviewer, and a change that only edits text is read within one business day after it merges. The remaining risk is that a small mistake in a text change reaches users a few hours before a second person reads it; I will have that read within one business day and tell you if anything turns up. Is there a part of the launch you are most worried about, so I can make sure it is covered?"

Direct answer

I would run a hybrid: agile discovery and delivery inside a compliance envelope. The uncertainty is about what users want, which is best resolved by short build-and-learn cycles. The regulation is about evidence and sign-off, which is best handled by planning the evidence up front and collecting it continuously. A pure waterfall would lock in guesses about users; pure agile would reach the sign-off date with no paper trail.

Terms

• Waterfall: phases run once in order (requirements, design, build, test, release), and each is signed off before the next begins.
• Agile: work is delivered in small increments (often two-week iterations called sprints) and plans change as you learn.
• Hybrid: the two are combined deliberately, each where it fits.

The shape I would choose (illustrative plan)

1. Discovery, 4 weeks, outside the regulated boundary. Prototypes with no real user data; the goal is to learn what users want. Meanwhile the compliance lead lists exactly which requirements the regulator will audit.
2. Build, six two-week sprints (12 weeks). Each sprint ships a working slice. Every story that touches a regulated behaviour carries a link to the requirement it satisfies and its test evidence, so the traceability record (which requirement is covered by which test) grows as a by-product of the work.
3. Formal verification and sign-off, 3 weeks. Because evidence has been collected all along, this phase is assembling and reviewing the package, not creating it.

Total: 4 + 12 + 3 = 19 weeks.

What this choice costs

• Some overhead per story (traceability links, approvals for regulated areas), which lowers raw speed compared with a pure agile team.
• Less freedom late in the project: anything that changes a regulated behaviour after its evidence is recorded reopens that evidence, so we push those decisions earlier.
• A single big release date for the regulated surface, even though the team builds incrementally, so users do not get every increment immediately.
• Risk of a "hybrid" that gets the bureaucracy of waterfall and the unpredictability of agile. I guard against it by naming, in writing, which items are fixed (regulated requirements) and which are flexible (everything else).

What would change my call

• If the regulator requires the full specification approved before any build starts, the front end must be waterfall, and I would spend more on discovery before committing.
• If the regulator allows pre-approved categories of change, I would lean further toward agile and ship inside those categories freely.
• If user needs are in fact well understood, the uncertainty premise is weaker and a plan-driven approach costs little.

Pitfall: treating sign-off as one final gate. Early informal reviews with the compliance lead are cheap; a rejected package at week 19 is not.

Direct answer

I would agree a commitment on the time to first substantive review response, not approval, tiered by pull request size, set with the team after a two-week baseline. I would define what happens when it is missed as a support ladder, not a penalty, and I would report adherence for the whole team alongside quality signals, so the number cannot be improved by rubber-stamping (approving without reading).

Set realistic expectations

1. Baseline first. For two weeks, measure how long pull requests currently wait for a first meaningful review, by size. Setting a target before this is guesswork.
2. Commit to first response, in working hours. A first response means a real review comment or approval, not an emoji. Approval time depends on the author's rework and is not the reviewer's to control.
3. Tier by size. Small changes are quick to review; large ones take longer and should be split. Illustrative tiers: small (under about 100 changed lines) 4 working hours, medium 8, large 16, with large changes also prompting the author to split or walk the reviewer through it.
4. Agree it with the team. Leadership sets the goal ("pull requests do not sit for days"); the team picks the numbers and the way reviewers are assigned. Run a pilot on one team for four weeks before extending.

When it is missed (the escalation ladder)

• At the SLA (service level agreement, the promised response time): an automatic reminder to the assigned reviewer.
• At 1.5 times the SLA (6 working hours for small, 12 for medium, 24 for large): another team member (a reviewer on rotation) takes it.
• At 2 times (8, 16 and 32 hours): the engineering manager steps in to clear reviewer load or reprioritise.

No one is penalised for a miss; repeated misses are read as a capacity or ownership problem.

Worked example (illustrative week, hours are working hours to first response)

Overall 5 of 10 are within SLA, 50%. Per tier, the median first-response time is 2.5 hours for small, 10.5 for medium (the middle of 7, 9, 12, 30 is the average of 9 and 12) and 17 for large. Pooled over all ten, sorted as 1, 2, 3, 6, 7, 9, 12, 14, 20, 30, the median is 8 hours and the 90th percentile is 20 hours (the 9th of 10 values); with so few reviews that is only an illustration, and real reports use a month or more of data per tier. The finding is that the medium tier fails: three of four missed, with one at 30 hours. I would ask why before blaming anyone. Perhaps medium pull requests are big enough to need a block of time that nobody has, or the 8-hour target is too tight. I would adjust the target or add review time, then compare the next week.

Report without gaming

• Report at team level, never per person, using the median and the 90th percentile (the value that 9 in 10 reviews beat) per tier.
• Place quality beside speed: changes-requested rate (the share of reviewed pull requests where the reviewer asked for changes before approving; for example 3 of 10 is 30 percent) and reverts (changes undone after merge) or bug fixes after merge. The median is the middle value when sorted, so one 30-hour outlier does not distort it. A falling response time with falling changes-requested rate suggests rubber-stamping.
• Report the distribution of pull request sizes, since people can also game by splitting changes into trivial slices.

What would change my call: if the team is small enough that everyone sees every pull request, drop the formal tiers and use a single norm.

Situation. I was an engineering manager for a team of 12 shipping a web service. Over one quarter, 5 of our 40 releases (12.5%) needed a hotfix, and the common thread was changes merged without a second pair of eyes or any automated checks. I proposed required pull request checks: a pull request (PR) is a proposed change; required checks are automated tests (and, in the original proposal, linting) that must pass, plus one approving review, before the change can merge. In the end only the tests and one review became blocking; linting stayed advisory, as described below. (The numbers here are illustrative; use your own in an interview.)

Resistance I met

• Senior engineers: "this slows us down and implies we are not trusted."
• A tech lead worried flaky tests would block urgent fixes.
• Two engineers said linting rules were a matter of taste.

What I did

1. Gathered evidence first: listed the five hotfixes and what check would have caught each; three of five would have been caught by tests that already existed but were not run automatically.
2. Co-designed the rule set with the tech lead and one skeptic, so they owned it.
3. Started advisory for three weeks, fixed the two flakiest tests, and set a review response target the team chose.
4. Added a hotfix lane (one approver, review afterwards) to answer the "urgent fix" objection.
5. Turned on blocking for tests and one review only; linting stayed advisory until the team agreed a style guide.

Result. In the next quarter 2 of 44 releases (about 4.5%) needed a hotfix, and median time to merge rose by a few hours at first (judged against a before-figure I could only reconstruct roughly from PR timestamps, since I had not measured it) and recovered after we fixed review response time. With counts this small (5 hotfixes, then 2), the drop is encouraging rather than proof; I told the team so and kept tracking it for another quarter. The skeptics later proposed two additional checks themselves.

What I would do differently. I would have measured merge time before the rollout, not afterwards, so I could show the cost honestly instead of estimating it after the fact. I would also have fixed the flaky tests before the advisory phase, since they cost the most goodwill.