Standardize and update CI/CD across hundreds of microservices without per-repo edits

What's really being asked

This question tests whether you can solve the fleet-wide CI/CD bottleneck that Expedia faced when they scaled to hundreds and then thousands of microservices. The interviewer wants to see if you understand how to decouple pipeline definition from service source code so that a single change can propagate across the entire fleet without manual edits or copy-paste. It also checks your grasp of the operational cost of thousands of independent pipelines, including network bandwidth and compute overhead from duplicated validation and integration testing.

The full answer

First, a thin-wrapper pattern where each repository contains only a minimal pipeline file that imports versioned templates from a centralized shared library or pipeline repository. Second, a versioning strategy so services can pin to a stable template version and opt into newer releases rather than being broken by a sudden global change. Third, a rollout mechanism such as a GitOps-driven control plane or an organization-scoped shared library update that pushes template changes progressively. Fourth, canary validation where the new template runs against a small subset of services first before enrolling the full fleet. Fifth, a discussion of compute and network efficiency, noting that consolidating common test and validation stages into reusable templates reduces the duplication and bandwidth costs that Expedia encountered when running separate integration tests on thousands of individual pipelines.

The mistakes people make

A red flag is proposing to open manual pull requests against hundreds of repositories or to copy and paste Jenkinsfile snippets between repos, which is exactly the anti-pattern that created maintenance nightmares at scale. Another red flag is suggesting a single monolithic pipeline that forces every service through identical stages regardless of language or runtime, because microservices benefit from independent development cycles. Failing to mention versioning or blast-radius control is also weak; without it, a bad template update can halt builds across the entire organization.

What usually comes next

The interviewer may ask how you would handle services that legitimately need custom pipeline stages, such as mobile builds or ML model training. They may also dig into rollback strategy if a shared template introduces a regression, or ask how you audit which services are on which template version. A senior candidate should also expect questions about secrets management and RBAC when a central pipeline library has broad repository access.

A concrete example

Imagine a company with 800 microservices moving off Jenkins where each repo had its own full pipeline definition. You create a single shared-library repository containing reusable pipeline modules for build, scan, and deploy. Each microservice repo replaces its bloated pipeline with a ten-line wrapper that calls sharedLibrary at v1.4. When you need to add a new security scan, you update the shared library to v1.5, trigger it against 20 volunteer services, measure build time and failure rate, then use a GitOps controller to bump the wrapper import across the remaining 780 services over a week. This avoids the programmatic or manual editing that Expedia engineers struggled with and cuts redundant integration test bandwidth by centralizing common stages.