Cloudflare Interview Questions: Networking, Coding, System Design

Cloudflare runs a global network that sits in front of other people’s websites, so its interviews lean on networking, caching, security and failure handling more than a typical software company’s do. Expect a coding round or two, a system design round for most levels, and questions about what happens between a browser and a server. This page lists the questions that fit that pattern and gives worked answers for the coding ones.

Cloudflare does not publish a stage-by-stage description of its engineering interviews, so what follows about the process comes from candidate reports. Your recruiter can tell you the exact loop for your role, and you should ask.

What the process usually looks like

Candidate write-ups mostly agree on this shape, with differences by team and level:

1. A recruiter call about your background and the role.
2. Often a conversation with the hiring manager about your past projects.
3. A live coding screen, usually one medium-difficulty problem or a small practical task.
4. A loop of several interviews: coding, system design, sometimes debugging an existing piece of code, and a behavioral or values conversation.

Timelines reported by candidates range from a few weeks to a couple of months. Treat all of this as a guide, not a promise.

Networking and web fundamentals

This is the area that most separates Cloudflare preparation from generic interview prep. You should be able to talk about each of these for a few minutes without notes:

• What happens when you type a URL and press Enter. Cover DNS lookup, the TCP handshake, the TLS handshake, the HTTP request, caching at each layer, and rendering. Interviewers often keep asking “and then?” until you run out of detail, so know where you can go deeper (for example, how a recursive resolver finds an authoritative server).
• TCP versus UDP. TCP gives ordered, reliable delivery with congestion control. UDP gives you datagrams and nothing else, which suits DNS queries, real-time media and protocols such as QUIC that build their own reliability on top.
• How DNS resolution works, including caching, TTLs and why a change can take time to show up.
• What TLS does. The handshake authenticates the server with a certificate, agrees on session keys using asymmetric cryptography, and then switches to symmetric encryption for the data because it is far cheaper.
• What anycast is. Many servers in different places announce the same IP address, and routing sends each client to a nearby one. Know why it also helps absorb DDoS traffic: the flood is spread across many sites instead of landing on one.
• What a DDoS attack is and how it is mitigated. Distinguish volumetric attacks, protocol attacks and application-layer (HTTP) floods, and talk about rate limiting, filtering and absorbing traffic at the edge.
• HTTP caching. Cache-Control, ETag, conditional requests, and what a cache key is.

The OSI model comes up in questions, but “which layer does X work at” matters less than being able to explain what actually goes over the wire.

Coding questions

Reported coding problems are ordinary data-structure and algorithm questions, with a streak of practical, systems-flavored ones: rate limiters, caches, parsing, and string handling. Practice the standard set (arrays, hash maps, linked lists, trees, graphs, sliding window) and add these two.

Rate limiter

Allow at most limit requests per key in any window of window seconds. The trick that makes the code testable is passing in the clock instead of calling time.time() inside the class. Interviewers notice that.

import time
from collections import deque

class SlidingWindowLimiter:
    def __init__(self, limit, window, clock=time.monotonic):
        self.limit, self.window, self.clock = limit, window, clock
        self.hits = {}

    def allow(self, key):
        now = self.clock()
        q = self.hits.setdefault(key, deque())
        while q and now - q[0] >= self.window:
            q.popleft()
        if len(q) < self.limit:
            q.append(now)
            return True
        return False

t = [0.0]
lim = SlidingWindowLimiter(3, 10, clock=lambda: t[0])
for step in [0, 1, 2, 3, 9, 10, 11, 12]:
    t[0] = step
    print(step, lim.allow("a"))

Output: requests at times 0, 1 and 2 are allowed; 3 and 9 are blocked; 10, 11 and 12 are allowed again because the old hits have left the window. Each call is amortized O(1), and memory is O(limit) per key.

Follow-ups to prepare: the fixed-window counter (cheap, but allows a burst of twice the limit across a window boundary), the token bucket (allows controlled bursts), and what changes when the limiter runs on many servers. In that last case you either share state (Redis or similar, with a latency cost) or accept approximate limits by giving each node a share.

LRU cache

Caching is Cloudflare’s business, so “design an LRU cache” is a fair guess. In Python, OrderedDict gives you the hash map plus recency order in one structure. In an interview where that feels like cheating, build it with a hash map and a doubly linked list and say why both are needed: the map gives O(1) lookup, the list gives O(1) move-to-front and eviction.

from collections import OrderedDict

class LRU:
    def __init__(self, cap):
        self.cap, self.d = cap, OrderedDict()

    def get(self, k):
        if k not in self.d:
            return None
        self.d.move_to_end(k)
        return self.d[k]

    def put(self, k, v):
        self.d[k] = v
        self.d.move_to_end(k)
        if len(self.d) > self.cap:
            self.d.popitem(last=False)

c = LRU(2)
c.put("a", 1); c.put("b", 2); c.get("a"); c.put("c", 3)
print(c.get("a"), c.get("b"), c.get("c"))   # 1 None 3

Reading “a” made “b” the least recently used entry, so adding “c” evicted “b”. For the trade-offs between eviction policies, see FIFO vs LRU vs LFU.

Is this binary tree balanced?

A common warm-up. The naive version computes the height at every node and is O(n^2) on a skewed tree. The better version returns the height, or -1 as a signal that a subtree is already unbalanced, so each node is visited once.

class TreeNode:
    def __init__(self, val=0, left=None, right=None):
        self.val, self.left, self.right = val, left, right

def is_balanced(root):
    def height(n):
        if not n:
            return 0
        l = height(n.left)
        if l == -1:
            return -1
        r = height(n.right)
        if r == -1 or abs(l - r) > 1:
            return -1
        return max(l, r) + 1
    return height(root) != -1

balanced = TreeNode(1, TreeNode(2), TreeNode(3))
skewed = TreeNode(1, TreeNode(2, TreeNode(3)))
print(is_balanced(balanced), is_balanced(skewed))   # True False

Time is O(n), and space is O(h) for the recursion, where h is the tree height.

System design questions

Likely prompts, based on what the company does: a CDN, a DNS service handling very high query volume, a distributed rate limiter, a key-value store, and a pipeline for traffic analytics. A structure that works for all of them:

1. Ask about requirements and scale: read/write ratio, latency target, how fresh the data must be, what happens when a region fails.
2. Draw the main path end to end before adding detail.
3. Go deep on the part the interviewer cares about, and name the trade-offs out loud.
4. Cover failure: what happens when a node, a link or the origin is down?

For a CDN, the points that tend to matter are request routing (anycast or DNS-based), the cache key and TTLs, what happens on a cache miss (and how to stop a thundering herd of misses hitting the origin, for example by collapsing concurrent requests for the same object), purging, and TLS termination at the edge. Our posts on questions to ask in a system design interview and trade-off analysis cover the method in more depth.

Behavioral questions

Expect the usual: a conflict with a teammate, a decision made with incomplete information, a project you are proud of, explaining something technical to a non-technical person. Prepare four or five real stories and fit them to the Situation, Task, Action, Result structure. Be specific about what you personally did, and say what you would change. If your answers sound memorized, this post on rehearsed-sounding answers helps.

A four-week prep plan

• Week 1: networking and web basics. Use a packet capture or curl -v to watch a real request, and read how DNS and TLS work from a primary source such as the Cloudflare Learning Center.
• Week 2: arrays, hash maps, linked lists, trees. Do 20 to 30 problems and explain each one aloud.
• Week 3: graphs, heaps, sliding window, and the two practical problems above, written from memory.
• Week 4: two or three system design walkthroughs with a friend, plus your behavioral stories.

If you want guided practice on the data-structure side, AlgoCademy has step-by-step coding lessons, and the Reverse Linked List lesson is a good starting point for pointer-manipulation problems.

Common mistakes

• Knowing algorithms but not what happens in a browser request. At this company that gap shows quickly.
• Calling the system clock inside the class you are asked to write, which makes it hard to test.
• Designing for the happy path and forgetting failure.
• Not asking the recruiter what each round covers. They usually tell you.