How Cloudflare interviews — Question to Offer

1. The shape of a Cloudflare loop

Cloudflare hires for engineers who think edge-first. The loop is shorter than Google's and tighter than Amazon's. A standard onsite is four rounds for L4 / L5, five for L6+. Each round is 60 minutes. Two are system design, one is coding, one is a hiring-manager round that leans behavioral, and L6+ adds a cross-team architecture review.

The system-design rounds are the ones that decide the offer. The interviewer is usually a Principal Engineer or a Director of Engineering. They have been writing edge-deployed code for years and they expect you to understand why running a thing at the edge is different from running it at origin.

The hiring bar is high in a specific way: low ego, transparency-first, written-comms heavy. Cloudflare publishes its post-mortems publicly. The interviewers expect you to talk about failure modes the same way — plainly, without hedging.

2. What Cloudflare grades you on

Three signals carry most of the weight in a Cloudflare design round:

Networking literacy. TCP, TLS, BGP, DNS at a sentence level. The L5 candidate knows what an Anycast IP is. The L6 candidate knows why Cloudflare announces the same /24 from 300+ data centers and how the public internet routes the request to the nearest one.
Distributed-systems primitives. Cache invalidation, eventual consistency, versioning under propagation lag. The interviewer expects you to reach for sharded counters and CRDTs the same way an AWS candidate reaches for DynamoDB.
Edge-first thinking. The senior tell here. Before you draw the origin in your diagram, the strong candidate asks: does this need to run at origin at all? Most things Cloudflare ships don't.

Hire-strong: you question the placement of every component in the first ten minutes, and you place at least one piece at the edge that a non-Cloudflare candidate would put at origin.

3. What's different here

Edge-first is the default. If your design has a single origin handling all requests, you're already a level below where Cloudflare grades. The interviewer expects you to push computation, state, and routing out to the 300+ edge locations.
Anycast is assumed. You don't need to explain how the user reaches the nearest edge. You assume it. If you spend five minutes drawing a load-balanced regional pool, you signal you've never worked at edge scale.
Eventual consistency is the default consistency model. Cloudflare runs across 300+ data centers. Strong consistency across that fan-out is expensive and almost never what the customer needs. The candidate who reaches for Raft on every problem is over-engineering.
Post-mortems are expected to be plain. Cloudflare's public post-mortems read like engineering memos, not press releases. The interviewer expects you to talk about failures the same way: name the cause, name the blast radius, name the fix. No hedging, no PR-speak.
You'll be asked about a real outage. Most loops include one question shaped "we had an incident where X — walk me through how you'd diagnose it." The 2019 BGP leak, the 2020 DNS resolver outage, the 2022 Workers regional cascade. They want to see you reason about real failure modes, not textbook ones.

4. The level bar

How the bar shifts:

L4 / L5 (senior) — design at the edge-aware level. You correctly place caching, rate limiting, and routing at the edge. Origin is a small box on the right. Depth on one primitive (typically caching or rate limiting) survives two pushes.
L6 (staff) — design at the propagation-aware level. Every distributed-state design comes with an explicit propagation model: how long it takes for a change to be visible everywhere, what happens to in-flight requests during propagation, what the user sees. The full tradeoff sentence (from [[tradeoffs-as-the-answer]]) on every major choice.
L7+ (principal) — design at the protocol level. You're expected to talk about TLS resumption, QUIC, HTTP/3, DNS protocol details. The system fits inside the public internet and respects its constraints (BGP convergence times, MTU, peering economics).

In this course, Ch 21 units target L6 by default, with explicit notes on what shifts at L5.

5. The Cloudflare-flavored mistakes

Watch for:

Putting state at origin by default. A weak candidate stores session data, rate-limit counters, and config at origin. The strong candidate puts all three at the edge and explains the consistency model.
Treating cache purge as instant. Purging 300+ edges takes seconds, not milliseconds. If your design assumes a purge is atomic, you'll get pushed on it. Have a versioning answer ready.
Ignoring the propagation lag. Every config push, every cache purge, every rate-limit rule update has a propagation window. If you don't say what the user sees during that window, you'll be asked.
Reaching for AWS primitives by name. Cloudflare engineers don't dislike AWS — but if you say "we'd use DynamoDB" in a Cloudflare design round, you're signaling you don't know what Cloudflare ships. Reach for the primitive shape, not the AWS product.
Skipping the failure-mode question. Cloudflare interviewers ask "what if a region goes dark?" on every distributed design. Have a per-region failover answer ready.

6. The seven scenarios in this chapter

Each unit dissects one question end to end. The chapter covers:

21.1 Global edge cache — purge propagation. The canonical Cloudflare question. Versioning, propagation lag, in-flight requests.
21.2 Workers — V8 isolates, near-zero cold start. The serverless-at-edge question. Compare to Lambda and Azure Functions.
21.3 DDoS mitigation at L7. The protect-the-internet question. Pattern detection, adaptive defense, the false-positive cost.
21.4 Cloudflare Tunnel — private network through the edge. The outbound-only network question. L5-friendly.
21.5 R2 — object store with zero egress fees. The compete-with-S3 question. Erasure coding, multi-region, edge-cached reads.
21.6 Durable Objects — stateful actors at the edge. The single-writer-at-edge question. Coordination across many Workers.
21.7 Take-home — edge cache with purge propagation. Code task. Build the versioned propagation mechanism.

7. The next page

The first scenario: global edge cache purge propagation. The most-asked Cloudflare question of the last decade.