Articles
Teleport Engineering Coding Challenge: Design Docs, Linux Processes, and Reviewable Pull Requests
Prepare for Teleport's engineering challenge with design reviews, Linux process reasoning, small pull requests, and a clear technical walkthrough.
A Teleport engineering coding challenge can look less like a timed algorithm test and more like a small engineering collaboration. The public Systems challenge asks for a design document, feedback before implementation, several reviewable pull requests, and a technical walkthrough. Prepare to explain the sequence of decisions, not merely to show a finished repository. Your invitation and assigned challenge still determine the actual requirements.
This guide separates Teleport's published process and challenge specification, individual candidate reports, and original practice advice. It does not provide a ready-to-submit answer to the live job-worker task. For a related systems warm-up, Explain OS processes, threads, and memory helps you name the behavior a Linux process design must account for.
Confirm which challenge and level you actually received
Official source: Teleport's 2025 explanation of its engineering hiring process describes a recruiter call, hiring-manager walkthrough, private Slack channel, and project-like challenge. It says the challenge window is 14 days after the private channel opens. That is a dated description of Teleport's process, not a promise that every current invitation has the same deadline. Confirm your own start time, due time, team, challenge link, and any amendments with the recruiter.
The public Systems Engineering challenge is unusually specific: its example project is a Linux job-worker service, and requirements differ by engineering level. It asks candidates to submit a design document as a pull request, wait for two reviewers' approval before implementation, and split code into roughly three to five pull requests. A walkthrough follows. Those instructions apply to that public Systems task as written; another role may receive a different repository. A candidate who memorizes the level-five cgroups requirements while being asked for another level or a Kubernetes-oriented task has prepared for the wrong problem.
Before beginning, make a one-page requirement ledger with four columns: source line, deliverable, verification, and unresolved question. Copy only the requirements relevant to your assigned level. Mark whether a statement came from the current invitation, public repository, recruiter clarification, or your own assumption. When these disagree, raise a concise question through the communication channel Teleport gives you. Do not silently promote a public example into an active requirement.
| Question to settle | Why it changes the work | Evidence to obtain |
|---|---|---|
| Which role, challenge, and level? | Changes the required interface and Linux behavior. | Exact invitation and repository path. |
| What starts and ends the window? | Determines the review schedule. | Recruiter or challenge instructions. |
| How is design approved? | Code may be premature before review. | Current approval rule and reviewer contact. |
| Which tools and dependencies are allowed? | A convenient library may violate the task. | Written task policy or reviewer answer. |
| What must be demonstrated? | Tests, build, PR history, and walkthrough differ. | Submission checklist. |
This ledger is an editorial tool, not a Teleport form. Its main benefit is preventing a technically polished solution to the wrong specification.
Write a design review that exposes the risky decisions
The public Systems task asks for scope, proposed API, security, command-line experience, and implementation details. It also requests a review-ready document rather than a sequence of draft documents. That creates a useful preparation target: practice making a short design legible enough that another engineer can challenge it before code exists.
Use a separate original rehearsal, not Teleport's job worker: build a local file-indexing service that accepts a directory, discovers files, records metadata, and lets a client request a status report. Your design note should state what counts as a valid root, whether symlinks are followed, how a scan is stopped, what happens when a file disappears midway, and what the client can learn after a failed scan. There is no single correct answer. The value is tracing one decision through API behavior, safety, tests, and limits.
For example, say that version one refuses to follow symlinks outside the chosen root. Then identify the risk—unexpected traversal into unrelated files—and the test—create an in-root symlink pointing outside and verify it is rejected. If you instead allow all symlinks, explain how you avoid cycles and inaccessible paths. A design claim without an observable check leaves the reviewer guessing whether you understand it.
Write one concrete client interaction: start a scan, get its identifier, ask for status, and request a report. Show one error response and what a caller should do next. If the format is still unsettled, mark it as a design decision, not a Teleport API fact. A brief alternatives paragraph should explain why you chose the smaller option and what would force a later change. Avoid building a speculative architecture for a performance requirement the task never states.
When you ask for review, separate a decision from a question: “I plan to reject paths outside the configured root. The open question is whether symlinks inside the root may point outside it; the current design rejects them.” That lets a reviewer approve, amend, or disagree. Once the design is approved, keep a short record of the chosen behavior so implementation and tests can be compared with it.
Practice Linux process reasoning without copying the assignment
Official specification: The public Systems challenge concerns Linux processes; higher levels add output streaming, process lifecycle, and resource control. It calls for tests of important happy and failure paths, reproducible builds, and care around races, deadlocks, networking, and security. It also urges small scope. Those are evaluation areas in that published task, not evidence that another Teleport team asks the same question.
For a distinct process exercise, write a tiny local supervisor for a fixed, harmless command such as a script that sleeps, writes two messages, and exits. Do not implement the hiring task's server, client, authentication, or cgroups. Instead, record the process identifier, start time, exit result, and captured output. Rehearse answering: what state exists before start returns; what happens if the child exits immediately; and what remains after the parent is interrupted? State what your rehearsal actually tests on your machine. A macOS-only rehearsal does not validate Linux-specific signal or cgroup behavior.
A useful state table makes ambiguity visible:
| Observed event | Expected local state | Question to test |
|---|---|---|
| Start fails before a child exists | Rejected, no live PID | Is the error reported without a phantom job? |
| Child starts, then exits | Completed with exit result | Can output still be inspected? |
| Stop requested while child exits | One terminal outcome | Are concurrent paths synchronized? |
| Parent restarts | Depends on persistence design | Does documentation match the actual behavior? |
This is an original practice state table. It is deliberately smaller than the public challenge. The table forces you to explain the difference between process launch, process completion, and a durable record. It also exposes the danger of using a PID as a permanent identity: operating systems may reuse process identifiers after a process ends.
If your rehearsal has concurrency, run a race detector where your language supports one and write a test that actually overlaps stop and exit. A mutex around a map can protect one data structure yet leave a blocked reader or a lost terminal event. When explaining a bug, draw the event ordering that causes it rather than naming “a race” without a trace. The same habit transfers to the public challenge without giving away its solution.
Make pull requests that a reviewer can inspect
The public instructions ask for multiple pull requests so reviewers can participate, and Teleport's process article presents the challenge as a collaboration. In preparation, choose your own small project and divide work by a reviewer-visible behavior: interface and tests, first working path, failure handling, then cleanup or documentation. Each PR should have a reason to exist independently and a runnable check.
A reviewable PR description answers four questions in a few sentences: what changed; why it is needed; how you checked it; and what remains. Include a small input/output example when behavior is hard to see in the diff. If a design decision changed during implementation, link the revised decision to the test. A giant “final solution” PR hides the reasoning and makes reviewer feedback arrive too late.
For the file-indexing rehearsal, one possible sequence is a design-only PR, a scan-and-status PR, a failed-file-path PR, and a focused test/README PR. Do not copy that sequence blindly into Teleport's assigned task. The public challenge has level-dependent requirements and an explicit design approval point. Use the current reviewer's response to determine the next increment.
Keep review comments as engineering conversations. When a reviewer questions error behavior, reproduce the specific case, state the present contract, and offer a smaller amendment or a reasoned rejection. Do not merge a branch merely to look fast. Conversely, do not over-document every obvious line to simulate deliberation. The history should let someone see what became safer or clearer after feedback.
Plan for asynchronous review and the walkthrough
The public Systems document asks candidates to seek design approval early, then implement after two reviewers approve. That makes calendar planning different from uninterrupted coding time. Reserve room for design comments, PR review, and a final run from a clean checkout. If the review cadence threatens the deadline, surface the issue promptly with a short status and the specific decision needed. A status like “design PR is ready; I need approval on symlink scope before coding that path” is actionable.
Candidate reports are limited: a Glassdoor collection includes an August 2026 Senior Systems post recalling a November 2025 Linux challenge and a July 2026 SRE post about a different Kubernetes exercise and review delays. These are individual, unverified accounts from different roles and periods. They illustrate why you should confirm the current challenge and leave space for asynchronous feedback; they do not establish a universal task, delay, or outcome.
Prepare a walkthrough that follows one requirement from design to code to test. Name the risk it addresses and an alternative you rejected. Then show a failure path you deliberately checked. If you cannot explain a dependency, generated code, or a large unreviewed change, investigate it before presenting. Teleport's published task warns against outsourcing the design and implementation to AI; follow the exact policy in your current invitation and take ownership of every retained line.
Finally, distinguish evidence from claims. A passing test demonstrates a specific checked behavior, not production readiness. A clean build on your laptop does not prove reproducibility on another Linux environment. A README that states the runtime, command, limitations, and test command lets a reviewer reproduce your claim. Rehearse the clean checkout yourself where possible, and state when Linux-only behavior remains untested locally.