Katkat
Back

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

TeslaSoftware Engineer · Onsite
HardSoftware EngineerOnsiteSystem Design

Last updated

Trace everything that happens between an engineer pushing a commit to a monorepo and the resulting software being installed on customers' cars, then explain how the monorepo decides which targets to build and test and in what order. It tests CI and release gating, artifact provenance, staged over-the-air rollout, safe in-vehicle installation, and dependency-graph builds.

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.

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?

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

Hints

Hint 1

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.

Hint 2

Start from the changed files: Ask what could possibly observe a change to a given file, directly or through something that depends on it.

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?