5 exercises — choose the best-structured answer to common engineering productivity and DX engineering interview questions. Focus on metrics frameworks, survey design, build systems, and delivery practices.
Structure for engineering productivity interview answers
Distinguish measurement frameworks: DORA measures delivery pipeline health; SPACE measures multidimensional productivity
Name Goodhart\'s Law: every metric becomes a target — acknowledge gaming risks in your answer
Cover the full loop: measure → intervene → re-measure; closing the loop is as important as the measurement
0 / 5 completed
1 / 5
The interviewer asks: "Compare the DORA metrics and the SPACE framework for measuring engineering productivity — when would you use each, and what are the limitations?" Which answer best covers engineering productivity measurement?
Option B provides the complete analysis: DORA metric definitions with elite-team benchmarks from the State of DevOps report, DORA's limitation scope (pipeline health only), gaming risks, all five SPACE dimensions with their measurement approach, the explicit anti-single-metric guidance from SPACE authors, decision criteria for each (delivery benchmarking vs DX diagnosis), a combination strategy, and Goodhart's Law as the meta-limitation for all productivity metrics. Options A, C, D each describe the frameworks correctly but don't give benchmarks, gaming risks, Goodhart's Law, or the combination strategy.
2 / 5
The interviewer asks: "How would you design a developer experience survey to measure and track DX over time — what questions do you ask and how do you analyse the data?" Which answer best covers DX survey design?
Option B covers all six design dimensions: survey cadence with rationale (quarterly, 5-10 questions), the DX Core 4 framework with its four dimensions, Likert scale specifics (7-point, not 10-point), avoiding leading questions, statistical significance testing for trend analysis, eNPS calculation and segmentation, qualitative coding of open-ended responses, the closing-the-loop practice (publish in 2 weeks, announce actions), and complementary hard signals (ticket volume, time-to-first-PR). Options A, C, D each mention 1-2 correct practices but don't cover survey length/fatigue tradeoff, the DX Core 4 framework, statistical analysis, or closing the loop.
3 / 5
The interviewer asks: "Explain how Bazel's remote build cache works — what is hermetic building, how is the cache key computed, and what are common cache invalidation pitfalls?" Which answer best covers build cache engineering?
Option B covers all six dimensions: hermeticity as a principle with Linux sandbox enforcement, cache key computation components (toolchain + CLI + envvars + input hashes), CAS (Content-Addressable Storage) blob lookup, remote cache transports (gRPC + concrete vendors), four specific invalidation pitfalls (non-hermetic rules, timestamp inputs, toolchain version drift, ~/.npmrc example), remote execution as the extension, and debugging tools (analyze-profile, --explain). Options A, C, D each describe the basic input-hash → cache-key concept but don't cover hermeticity enforcement, CAS, invalidation pitfalls, or debugging.
4 / 5
The interviewer asks: "Explain trunk-based development — how does it differ from Gitflow, and what are the engineering practices required to make it work at scale?" Which answer best covers TBD practices?
Option B covers all six dimensions: Gitflow's late-integration problem (weeks of accumulated conflicts), TBD commit cadence (daily to trunk, max 2-day branches), DORA performance linkage, three specific enabling patterns (feature flags with vendor examples, branch-by-abstraction, expand/contract), CI speed requirement (<10 minutes), trunk health monitoring practices, branch lifetime metric, and the two most common objections with their solutions. Options A, C, D each identify feature flags and short branches but don't cover branch-by-abstraction, CI speed requirements, trunk health monitoring, or the objection/resolution patterns.
5 / 5
The interviewer asks: "How would you measure and reduce developer onboarding time — what metrics matter and what are the highest-leverage interventions?" Which answer best covers onboarding engineering?
Option B covers all five dimensions: four specific metrics with their distinct meanings (TTFC vs TTFPR vs TTFS vs time to productivity), benchmark numbers (1-3 days TTFPR, 3-6 months full productivity), five high-leverage interventions with implementation specifics (make bootstrap, devcontainers, Nix; buddy time in sprint planning), cohort analysis methodology for regression detection, segmentation strategy, and three specific anti-patterns (stale docs, broken setup scripts, overburdened buddy). Options A, C, D each list the right interventions but don't provide benchmarks, cohort analysis methodology, or anti-patterns.