AI coding interview examples: published tasks and what to practice

A published example is not always an interview question

Some employers publish an illustration of their interview style. Others name a type of project without releasing its requirements. Occasionally, a company releases an old assessment that you can run yourself. These are all useful, but they answer different questions. A description of an airport controller tells you something about the expected work; it does not tell you the exact airport question in your next interview.

The sections below label each example before discussing it. The suggested requirements and follow-up questions are our preparation ideas unless a source says otherwise. The linked nrml exercises teach related skills in their own repositories. They are not copies of a company’s assignment, and completing one does not predict how an employer will score your work.

Canva: an airport control system

Official illustration: Canva’s engineering announcement uses a system for coordinating aircraft departures and arrivals to illustrate its AI-assisted format. It does not publish a full assignment. Canva’s example.

For your own rehearsal, begin with one runway and a queue of requested movements. Decide whether priority changes the order, whether a movement can be cancelled, and what happens when the runway becomes unavailable. Pick a small set of rules before building a user interface. Otherwise you can produce an attractive screen without knowing whether two aircraft can occupy the same resource.

Try Stop Double Claims in the Job Scheduler. The useful connection is exclusive ownership of work, not aviation. Explain which worker currently holds a job and when that right ends. Once you can reason about that boundary, ask a partner to change the scheduling rule and explain which parts of your solution need to change.

DoorDash: dispatch, menus, and support workflows

Official task families: DoorDash names order dispatch, menu composition, and support-resolution automation as possible engineering tasks. These are examples of the work, not complete public prompts. DoorDash’s format announcement.

Use dispatch as a practice topic. Suppose a service receives order-created, restaurant-ready, and courier-assigned events. Ask what happens when an event arrives twice or an older update arrives after a newer one. Before requesting a patch, write a short event sequence and the state you expect after each step. That makes it possible to judge a generated reducer without trusting its explanation.

The closest nrml exercise is Rebuild State from Out-of-Order Events. It covers duplicate deliveries, stale versions, and deletion markers. Focus on preserving the newest valid state when the delivery order changes. For the full company format and a separate pickup-readiness exercise, read the DoorDash guide.

CoderPad: build a backend API, then explain it

Official project examples: CoderPad’s account of hiring its own engineers names backend API projects, SQL exercises, and a video explanation of completed work. It does not release every task specification. CoderPad’s hiring account.

A useful API rehearsal is a paginated activity endpoint. Decide how results are ordered, what identifies the next page, and how the caller knows they reached the end. Include two records with the same timestamp. If you test only distinct timestamps, an implementation that skips or repeats tied records can look correct.

Practice that with Make Activity Pagination Stable. When you finish, explain the cursor format without reading the implementation. Describe one input that broke the original behavior and the assertion that now protects it. Then answer a change request: what happens if the caller adds a filter? This tests whether you understand the API you built, not just whether a sample response looks right.

Anthropic: a released performance-engineering take-home

Released historical assessment: Anthropic published a version of its performance take-home as an open repository. Its engineering account describes optimizing code for a simulated accelerator and explicitly permits AI for that take-home. This is a take-home example, not evidence of permission in Anthropic’s live interviews. Engineering account, public repository.

The repository is an older public challenge, not the current private hiring test. Its README warns that agents have produced invalid improvements by modifying the tests. Use the supplied submission checks and keep the test directory unchanged. Repository instructions.

For a smaller optimization exercise, try Collapse the Order Report Query Storm. Its database batching problem is different from accelerator optimization, but the discipline transfers: preserve the output while reducing unnecessary work. Measure the same thing before and after each change, and verify ordering, missing records, and repeated inputs before celebrating a faster result.

Turn a broad example into a manageable question

A broad product brief contains too many decisions for a first rehearsal. “Build an airport system” could involve scheduling, authorization, maps, storage, or notifications. Select one behavior and make it observable. For example: given pending jobs and existing leases, return one job that this worker may claim. Write down what must stay true if two workers try at almost the same time.

Use three examples to define the boundary: an ordinary success, an input that must fail, and an input that looks like the failure but should succeed. A valid lease, an expired lease, and a stale worker attempting a write make a useful set. Ask the assistant to trace these cases through the existing repository before it edits anything.

Stop adding requirements when the exercise already contains a meaningful decision. You do not need authentication, a message broker, and a polished dashboard to practice lease ownership. Those additions can hide the part you intended to learn under setup work.

Help me narrow this practice brief to one observable behavior.
Propose a normal case, a failure case, and a boundary case.
List decisions I need to make before implementation.
Keep the exercise small enough to finish and verify in one session.
Do not claim it reproduces any company interview question.

Use candidate reports for variety, not certainty

A first-person report can suggest another kind of problem to practice, especially when a company publishes little detail. Check whether the author actually took the round, whether they identify its format, and whether AI permission is stated. A traditional pair-programming question reported under a company name does not become an AI-assisted question because the company later changed its process.

Our Meta guide includes a clearly labeled candidate account alongside official process information. Keep those two kinds of evidence separate. A reported question can help you vary your rehearsal, but your recruiter’s instructions still determine the tool rules, language options, and timing of your own interview.

Finish the practice session by checking your explanation

After solving one example, close the assistant and explain the change to a partner. Start with the behavior that was wrong, then show the smallest input that demonstrates it. Describe why the repair works and which test would catch a regression. If you cannot explain a condition in the generated code, read or remove it before moving to another exercise.

On the next attempt, keep the technical topic but change the failure. A duplicate delivery and an out-of-order delivery may look similar while requiring different handling. An expired lease and a lease belonging to another worker are also different. Practicing these distinctions is more useful than memorizing the same solution with a different company name.

Keep a short note after each session: one assumption you corrected, one suggestion you rejected, and one behavior you verified independently. Use that note to choose the next problem. It turns a collection of published examples into a preparation plan you can actually follow.