DevOps Culture, Principles, and Practices
What to know
DevOps is a sociotechnical movement, not a toolset. Candidates must be able to explain the CALMS framing (Culture, Automation, Lean, Measurement, Sharing), the Three Ways (flow, feedback, continual learning), and the tension between silos and cross-functional teams. Understand blameless postmortems (focus on system causes, not individuals), Westrum organizational typology (pathological, bureaucratic, generative), and DORA metrics (deployment frequency, lead time for changes, change failure rate, time to restore). Know that toil should be identified and automated, and that value stream mapping exposes wait states rather than work time.
Traps
Questions often conflate blame-free with accountability-free: blameless postmortems still assign owners and actions. Another trap is treating DORA metrics as targets to game-deployment frequency without stability is not improvement. Watch for "which is a DevOps principle" items where the distractor is a specific vendor product. Also distinguish lead time (commit to production) from cycle time (start to finish of a work item) and from MTTR, which DORA now frames as failed-deployment recovery time.
Rule of thumb
When a scenario describes a conflict between teams, ask: does the proposed fix change incentives and information flow, or only add a tool? Prefer answers that shorten feedback loops and make work visible. A worked example: a team ships monthly with 30% change failure rate. Improving only CI speed changes one metric; pairing smaller batch sizes with automated rollback and blameless review improves flow, feedback, and learning together-the answer that addresses all Three Ways.
Practice cue
Map one value stream, mark every handoff, and estimate wait time at each. The longest wait, not the longest work, is usually your first improvement target.