From a Monorepo Commit to an Over-the-Air Vehicle Update, and Choosing What to Build

The hiring manager's round was a second system design question. An engineer at a car company commits a change and pushes it to the company's monorepo. Eventually, software containing that change is installed on the onboard computers of customers' cars. What happens in between? Describe the whole path from the push to the update running in the vehicles, then answer the hiring manager's deeper questions about the build step. ### Clarifying Questions - Is the vehicle software shipped as one versioned image for the whole car, or as separately versioned components for different onboard computers? - How many hardware variants must each release support? - Roughly how many commits land per day, and how long may checks take before a change is merged? - Do safety-critical components need extra qualification or sign-off before release? - What constraints apply in the vehicle: may an update install only while the car is parked, and what happens if power is lost during installation? - How are vehicles reached: do they poll for updates, and can some stay offline for long periods? ### Part 1 — From push to the vehicle fleet Walk through every stage between the push and the software running in customers' cars: how the change is verified and built, where the results are stored, how a release is assembled, and how it is rolled out and installed. For each stage, say what can go wrong and which gate stops a bad change from moving forward. ```hint Name the gates List every point at which a bad change could still be stopped, and what evidence each gate needs before it lets a build through. ``` #### What This Part Should Cover - Pre-merge checks and a CI pipeline that produces reproducible, traceable build artifacts - Artifact storage, signing, and provenance linking every installed binary to its source commit - A staged rollout with health gates, pausing and rollback - Safe delivery and installation on the vehicle itself ### Part 2 — Deciding what to build in a monorepo The hiring manager focuses on the build: the monorepo holds many projects, so a single commit should not rebuild and retest everything. How does the system decide which things must be built and tested for a given commit, and in what order? ```hint Start from the changed files Ask what could possibly observe a change to a given file, directly or through something that depends on it. ``` #### What This Part Should Cover - How dependencies between build targets are declared and represented - Computing the set of targets affected by a change, including indirect effects - A build order that respects dependencies while exploiting parallelism and caching - Cases where file-based change analysis is wrong or unsafe ### What a Strong Answer Covers - A traceable chain from commit to installed binary, with the same artifact promoted through every stage rather than rebuilt - Quality gates that become more expensive and more realistic at each stage, from unit tests to real vehicles - A dependency-graph view of the build, with correct incremental and cached builds - Vehicle-side safety: authenticated updates, atomic installation, and a guaranteed path back to a working version - Observability, and the ability to halt a rollout quickly ### Follow-up Questions - A change touches a library that almost every target depends on. What does CI do, and how do you keep that change from blocking everyone else? - How do you prove that the binary installed in a car is exactly the one that passed testing? - A canary wave shows a small rise in a fault signal. How is the rollout paused, and how are the affected vehicles returned to a good version? - How do you handle a vehicle that comes online after months offline and is several releases behind?