Lessons from a 2020 intern assignment

In this blog post, I want to explain the details of the full-stack take home exercise that we sent out to our 2020 internship applicants.

K

KristianCloudflare

·June 23, 2020

An Originless A/B Testing Challenge

Cloudflare doubled its Summer 2020 intern class and, like everything else that year, the program ran remotely. Rather than rely on timed coding exercises to evaluate engineering applicants, the team designed a take-home project built on Cloudflare Workers. The goal was twofold: give candidates a realistic, self-contained task and simultaneously gather feedback on the Workers platform and its documentation from thousands of fresh eyes.

The exercise is open source on GitHub. While applications for that internship cycle are closed, the project remains a useful way to explore Workers.

The Project: An A/B Test at the Edge

The exercise asks applicants to build an A/B test application. Workers code makes a request to an API and returns one of two possible variant URLs. Since the application doesn't route through an origin but instead serves responses directly from an API, it's considered an originless application—everything is handled by Workers.

A/B testing was chosen deliberately. It's simple enough to focus attention on core Workers APIs—fetching, parsing, response modification—while still requiring a working deployment via the wrangler CLI. The self-contained nature of the task meant applicants didn't need to provision servers or host files elsewhere.

The provided base application includes three routes: an API route returning an array with two URLs and two HTML pages, each slightly different. Completing the exercise requires four steps:

Fetch the API URL provided in the instructions
Parse the response and transform it to JSON
Randomly pick one of the two URLs from the variants array
Fetch that URL and return the response to the client

The task sits just past beginner-level JavaScript. Familiarity with fetch requests, JSON parsing, and array manipulation is sufficient. Since it's a take-home test, applicants could consult documentation and reference material freely, but because the variant URLs aren't hard-coded into the prompt, a correct implementation still requires the API interaction to work.

Deployments were made to a workers.dev subdomain via wrangler, which fits within the Workers free tier. This process surfaced a number of GitHub issues on the docs and wrangler repos—helpful feedback for the broader Workers ecosystem.

Going Further with Workers APIs

Several extra credit sections were included, explicitly optional but worth attempting for those who finished the core task quickly. They explore more advanced runtime APIs and design considerations.

Content Rewriting

The first optional challenge asks developers to modify page content returned to the client. Two approaches are possible: simple text replacement or the Workers runtime's HTMLRewriter API.

JavaScript's string .replace works for straightforward substitutions in the response body. However, this approach is fragile—strings must match exactly—and reading response.text() into memory holds the entire payload, which can be problematic at scale.

The runtime-native HTMLRewriter API offers a better path. It provides a streaming, selector-based interface for transforming responses as they pass through the Worker. Developers compose handlers as JavaScript classes or functions, testing both API understanding and code organization. A sample implementation rewrites the title tag plus three content elements: h1#title, p#description, and a#url.

A proper A/B test doesn't just randomly route users. It should remember which variant a user saw on subsequent visits. Applicants were encouraged to use Workers' integration with the Request and Response classes to set a cookie, then parse it on later requests to return the same variant consistently.

Cookie handling is a fundamental web concept but one many developers haven't implemented directly. Example code shows how to persist a chosen variant using cookies across sessions.

Custom Domain Deployment

workers.dev removes the need to own a domain for basic deployment, but wrangler also supports deploying to a domain. Applicants who owned one could complete this optional section, which teaches more than Workers itself: deploying to a domain requires a zone in the Cloudflare Dashboard, giving interns exposure to the onboarding process. Applicants were explicitly told not to purchase a domain for this—no financial burden for candidates.

Common Missteps in Submissions

The most frequent issue across submissions wasn't technical—it was readability. Many applicants submitted technically correct code that was nearly impossible to parse due to inconsistent indentation. Running code through a formatter, such as VS Code's "Format Document," would have resolved most of these cases.

A more serious pattern involved rushing into extra credit before the base implementation worked. Some applicants opened the API URL in a browser, copied one of the variant URLs, and hard-coded it into their application. That approach doesn't satisfy the core exercise, and layering optional enhancements on top made the flaw obvious to reviewers. This happened frequently.

Among incorrect implementations, common errors included copying the entire JSON array into code, mishandling the random selection between two values, and failing to account for the possibility of a third value being added to the array. Another frequent mistake was fetching both variant URLs up front rather than parsing the API response and fetching only the selected URL. In a larger application, that means wasted bandwidth and longer request times—exactly the kind of inefficiency to avoid in serverless code.