A · Professional problem solving and implementation
Engineering systems
Build, release, repository workflows, and the quality tooling around them.
Classification boundary
Include: Include build, release, repository, development-environment, and engineering workflow infrastructure.
Choose a neighboring leaf when: Use quality/security when test strategy or protective controls are primary, and system design for runtime architecture.
This capability may appear in standards across different stages. Explore stage expectations
49 questions
Choose a group based on the evidence you need. Groups follow existing question formats, not difficulty or mandatory prerequisites. Each batch has up to eight questions.
Concepts and boundaries1
Check concepts, assumptions, and conditions of use.
Questions 1–1
No questions in this section match your target. ·
Judgment and options47
Compare goals, constraints, options, and trade-offs.
Questions 1–8
- On-call engineers receive many alerts each day, yet user complaints and service objective violations still go unnoticed. How would you redesign alerting?
- An old system keeps accumulating new business and is becoming hard to maintain. How would you create an adapter boundary between old and new systems so legacy rules and data models do not spread into new code? Explain the migration steps and any compromises or risks you would accept.
- Tell me about an architecture upgrade. Why did it have to be upgraded rather than patched further, what challenges came up during migration, how did you keep the business running, and did the benefit materialize?
- For a given capability, how do you decide between building it, adopting open source, or buying it? How do building and open source differ in cost, control, maintenance, and risk, and when should you switch from one to the other?
- A repository accepts external contributions, and CI runs build scripts, reuses caches, reads test credentials, and produces release artifacts. How would you separate untrusted execution, credential permissions, and cache boundaries so code cannot read secrets or poison trusted artifacts?
- Cloud costs keep rising and finance asks for cuts while teams are improving reliability. How would you find savings without shifting risk elsewhere?
- How do you identify and record technical debt and pay it down without stopping business delivery? Which debts are worth paying and which can be left for good, and how do you judge?
- Your solution depends on a lower-level service or library. If it changes substantially, how would you migrate, fall back to a version that preserves core features, or replace it?
No questions in this section match your target. ·
Questions 9–16
- The root cause of an incident is still unknown, but business stakeholders ask when service will recover. How would you update them, communicate uncertainty, and avoid misleading commitments?
- In the technical area you work in, how is the industry developing? Is your solution adapting to that trend or going against it?
- Some production resources differ from their declared configuration, including undocumented emergency fixes. How would you distinguish intentional changes from unexplained differences, assess the risk of overwriting state, restore trust, and prevent recurrence?
- A release must reach thousands of runtime nodes with varying versions and network conditions. How would you design rollout batches, health checks, and pause criteria?
- After a release goes wrong, the team says “we can roll back.” How would you check that this is true and not just a line in the plan?
- A company’s frontend projects live in separate repositories, and someone proposes merging them into a monorepo. How would you decide whether to do it, and how would you validate it in steps?
- The application can be rolled back, but a database migration removed an old field and the previous version can no longer start. How would you redesign release order and rollback?
- What technical gains did this project bring? How do you measure them, and what complexity and maintenance cost did you pay for them?
No questions in this section match your target. ·
Questions 17–24
- After a frontend framework upgrade, compilation succeeds, but render timing, default caching, or side-effect order changes. How would you verify product behavior remains correct?
- A user signs in within one child app but loses permissions or session state when switching to another. How would you design the boundary for shared auth context?
- One app emits an “order completed” event, but other modules interpret it differently, causing duplicate requests and divergent page state. How would you define a cross-app event contract?
- Users report a blank page after navigating across apps, while each team’s monitoring appears healthy. How would you establish end-to-end observability?
- After independently developed apps are integrated, styles collide, themes differ, and overlays are clipped. How would you choose a style-isolation strategy?
- Several frontend modules build independently, but releases still require coordination. What evidence would show they have a real independent delivery boundary?
- A large frontend makes parallel delivery difficult, but splitting it into several apps at once is risky. How would you plan an incremental migration and judge each step?
- If a micro-app fails at startup, users cannot access other modules. How would you isolate the failure and, if needed, disable noncritical features to keep the rest available?
No questions in this section match your target. ·
Questions 25–32
- Several child apps depend on different React and component-library versions, causing both duplicate downloads and runtime conflicts. How would you govern shared dependencies?
- Several child apps share the browser address bar, but back/forward, deep links, and login redirects behave inconsistently. How would you define a routing contract?
- After code changes, the build system sometimes misses affected apps and sometimes rebuilds the entire repository. How would you validate the dependency graph and cache invalidation rules?
- One repository contains multiple teams and production deployment config, but code-owner rules do not cover temporary admins and automation accounts. How would you review permission and approval boundaries?
- Two product packages form a dependency cycle, and splitting them creates a need to share domain types. How would you change the boundaries without hiding the cycle in a new shared package?
- A team decides to split a large repository, but history, CI, package releases, and ownership are connected. How would you sequence the migration?
- In a monorepo, shared packages are casually changed by one team, while consumers discover behavior changes only after upgrading. How would you establish ownership and compatibility contracts?
- Packages have very different release cadences, but shared version numbers force unrelated teams to release together. How would you design versioning and release policy?
No questions in this section match your target. ·
Questions 33–40
- The repository has hundreds of packages and full CI is slow. The team wants to test only “affected” areas. How would you prove selective testing does not miss critical dependencies?
- A build registry must clean up years of images, but production services may still roll back to old versions. How would you define retention and artifact recoverability?
- An organization must move several repositories from an old CI system to a new platform without pausing delivery across teams. How would you sequence migration and decide which repositories enter each wave?
- A client must upload a large file, but the operating system may pause or terminate background work at any time. How would you chunk the task, persist progress, and make rescheduling safe?
- Hundreds of repositories pin different third-party versions, and security teams struggle to identify exposure when a severe vulnerability appears. How would you establish dependency updates and risk handling?
- A defect appears only in production and cannot be reproduced in development or staging. How would you determine whether the cause is environment, traffic shape, or data characteristics, and improve environment design?
- Teams share a repository but release at different cadences; shared package changes often block unrelated teams. How would you design boundaries, impact analysis, and release agreements?
- The same release behaves differently across clusters, and configuration changes are not fully audited. How would you establish configuration sources, drift detection, and rollback?
No questions in this section match your target. ·
Questions 41–47
- Teams are copying shared components and adding local variants, making similar features inconsistent. How would you decide which differences belong in the shared design system and which should remain team-specific? How would teams help maintain those rules?
- A shared library releases a backward-compatible version, but application repositories cannot upgrade promptly because of pinned dependencies, generated code, or different release windows; a security fix remains blocked. How would you design compatibility policy and the dependency-upgrade process?
- A feature is fully launched, but switches created years ago still control several code paths; the team does not know which flags can be removed and relies on memory during rollback. How would you establish flag lifecycles and cleanup ownership?
- Teams can release micro-frontend modules independently, but loading, navigation, error messages, and accessibility behavior are becoming inconsistent. How would you decide which capabilities belong to the platform and which stay with product teams?
- A backend API generates TypeScript, Java, and Swift SDKs, but nullable types, enums, and error models are drifting across languages. How would you design the contract source, generation process, and cross-language compatibility tests?
- A production dependency has a different artifact hash from the build associated with its repository tag, and the team cannot confirm it passed the expected CI. How would you establish build traceability, artifact verification, and release authorization?
- New clients use a replacement API, but users upgrade slowly and older versions still account for meaningful traffic; continued support also constrains server evolution. How would you set a support window, capability detection, migration notices, and retirement criteria?
No questions in this section match your target. ·
Implementation and verification1
Examine execution, verification, and correction.
Questions 1–1
No questions in this capability match your target. ·