Design a CI platform like GitHub Actions: system design interview question

How the interviewer opens it

“Design a continuous integration platform that runs tests and validation when developers push code. Jobs have dependencies and need isolated execution. The platform must share execution resources fairly across repositories.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

What to clarify first

Triggers and dependencies
Scale
Job resources
Fairness
Isolation and secrets
Read and write mix
Latency
Consistency and durability
Retention and output
Product boundaries

The interviewer has the answers. In a SysRound round, Alex gives these answers, as a real interviewer does.

Scope of a strong answer

Core requirements

Create a pipeline run for a code push at a fixed commit.
Execute jobs after their required jobs succeed.
Isolate each job and publish its status, logs, and artifacts.
Share capacity fairly across repositories and support cancellation.

Usually out of scope

Host source repositories.
Deploy applications.
Implement a secrets service.
Support multiple regions.

What interviewers ask about

Which repository runs next: Repositories have different queue sizes and job sizes. New work must receive a fair share without stopping active jobs.
Job results and dependencies: A worker can finish without reporting its result. Later events can conflict with a retry, a dependency decision, or cancellation.
What a job can access: The platform deliberately executes untrusted code. A normal test command can attack credentials, other jobs, or the platform itself.
Job output and downstream use: Job output greatly exceeds control traffic. Retries and partial uploads can expose the wrong artifacts to dependent jobs.

Common mistakes

Treats the platform as a queue without defining dependency or attempt states.
Equates equal job counts with fair resource allocation.
Assumes a lost worker has stopped execution.
Uses container isolation without a threat model for hostile code.
Promises exactly-once execution despite worker failures.
Sends logs and artifacts through the scheduler or metadata database.

The bar by level

Senior (L5/E5): Separates jobs from attempts and handles stale results, cancellation races, and missed dispatch events. Accounts for reserved CPU in repository fairness. Defines hostile-code isolation, secret permissions, output limits, and recovery after worker failure.
Staff (L6+/E6+): Defines precise fairness, execution, and durability guarantees. Explains the limits of nonpreemptive allocation and repeated execution. Controls the damage from worker compromise and platform partitions. Uses estimates to justify scheduler simplicity, fleet limits, and separate output storage.

Sources · 1 reference

These records explain where the question appears. A company tag or candidate report does not guarantee a future interview question.

SysRound · 1 record

No company association
Design a CI platform like GitHub Actions
Reported date not specified
Source snapshot: Nov 12, 2026
View source

How the interviewer opens it

“Design a continuous integration platform that runs tests and validation when developers push code. Jobs have dependencies and need isolated execution. The platform must share execution resources fairly across repositories.”

The prompt is vague on purpose. The first minutes are for you. Reduce the prompt to the core features and agree on the numbers before you draw.

Scope of a strong answer

Core requirements

Create a pipeline run for a code push at a fixed commit.
Execute jobs after their required jobs succeed.
Isolate each job and publish its status, logs, and artifacts.
Share capacity fairly across repositories and support cancellation.

Usually out of scope

Host source repositories.
Deploy applications.
Implement a secrets service.
Support multiple regions.

What interviewers ask about

Which repository runs next

Repositories have different queue sizes and job sizes. New work must receive a fair share without stopping active jobs.

Job results and dependencies

A worker can finish without reporting its result. Later events can conflict with a retry, a dependency decision, or cancellation.

What a job can access

The platform deliberately executes untrusted code. A normal test command can attack credentials, other jobs, or the platform itself.

Job output and downstream use

Job output greatly exceeds control traffic. Retries and partial uploads can expose the wrong artifacts to dependent jobs.

Common mistakes

Treats the platform as a queue without defining dependency or attempt states.

Equates equal job counts with fair resource allocation.

Assumes a lost worker has stopped execution.

Uses container isolation without a threat model for hostile code.

Promises exactly-once execution despite worker failures.

Sends logs and artifacts through the scheduler or metadata database.

The bar by level

Senior (L5/E5)

Separates jobs from attempts and handles stale results, cancellation races, and missed dispatch events. Accounts for reserved CPU in repository fairness. Defines hostile-code isolation, secret permissions, output limits, and recovery after worker failure.

Staff (L6+/E6+)

Defines precise fairness, execution, and durability guarantees. Explains the limits of nonpreemptive allocation and repeated execution. Controls the damage from worker compromise and platform partitions. Uses estimates to justify scheduler simplicity, fleet limits, and separate output storage.