Building New Projects

This module covers practical coding interviews where you're expected to build something from scratch. You'll usually start with a specification, some sample data, and an empty or partial repository. From there, you need to turn the requirements into a working project. Reported interview prompts include:

• Build a web crawler in 45 minutes.
• Create an AI agent that can answer questions about company documents.
• Write a library to parse and validate CSV files.

These problems appear in live coding rounds and take-home projects. They test whether you can independently own and execute a problem from start to finish. With no existing architecture to guide you, you'll need to research unfamiliar pieces, structure the solution, and test the result.

How these rounds are evaluated

Interviewers still evaluate communication, problem solving, and coding ability. When you're building a new project, pay particular attention to the following:

• Research effectiveness. You may need a library or helper function you've never used. Time-box the research, compare the relevant tradeoffs, and make a decision you can explain.

• Functionality. Get a proof of concept running end to end, then improve it. An elaborate architecture will not help if you discover too late that the basic path does not work.

• Extensibility. Expect the interviewer to add larger inputs, constraints, or features. Separate the parts most likely to change, and write enough tests to refactor safely.

• Handling ambiguity. Every specification leaves something out, sometimes deliberately. Ask about scope and inputs before you build, then keep clarifying as new questions emerge.

Communication tips to keep in mind

Read the problem fully before you choose an approach. Clarify the scope, inputs, and definition of "done." If you need to research something, time-box it. You can tell the interviewer, "I'll start with the simpler library and swap later if we need more." Make a reasonable choice, explain it, and get the smallest complete path working before you optimize.

Using AI effectively

When AI is allowed, use it to brainstorm options and compare tradeoffs. Give the agent the context it needs. If the task depends on a specification file, include that file before asking it to act. Boilerplate setup is often safe to delegate, but you should reason through the central logic yourself and be able to defend every generated choice.

Here are a few example prompts you can use, depending on the degree to which you're permitted to use AI in the interview:

Research-only. Use it to choose, not to build. Asking for tradeoffs and sources turns a lookup into a decision you can defend out loud.

Pseudocode
I need to resize and re-encode a few thousand images in Python. What are
the 2-3 standard libraries for this, and what are the tradeoffs between
them for batch processing? Point me at the docs for each so I can check.

Limited context. Let it write the shape and keep the substance for yourself. A skeleton with the bodies left empty gives you the typing speed without giving away the part being evaluated.

Pseudocode
Here's my spec. Generate the module skeleton only: function signatures,
docstrings, and type hints, with every body left as
`raise NotImplementedError`. I'll write the logic myself.

Full use. When you're expected to delegate execution, scope the task carefully and review the result. Ask for tests alongside the code, and have the agent identify every gap it filled in.

Pseudocode
Implement the crawler's fetch-and-parse stage from the spec above. Write
the tests first, then the implementation, then run them. When you're done,
list every place you had to guess at something the spec didn't say.

Do not copy generated output wholesale. Explain how the code works, test it as you go, and check unfamiliar APIs against their documentation.

What to include in a take-home

Take-homes give you more time, so reviewers expect a more complete result. Include the following:

• Alternatives and tradeoffs, written down. Note what else you considered and why you chose this approach. A small tradeoffs table in the README is enough.
• A README that documents assumptions. When the specification leaves a gap, make a choice and record it.
• Evidence it runs. Include clear run instructions. A short demo video or screenshots can also show the working result, especially when a reviewer may read the project before running it.
• Code that reads well. Modular structure, error handling, and tests that would catch regressions. It doesn't need full comments, but tricky logic deserves an explanation.
• Scale, addressed proportionally. Add a short section explaining what you would change for 100x traffic, even if you did not build those changes.

Treat the provided test cases as a starting point. Your solution should work with inputs beyond the sample files because the evaluator may use different examples. If you're building a web crawler, for instance, do not hard-code the one test URL you received.

Leveling signals

At the mid level, focus on a correct end-to-end implementation and explain the choices you make. At the senior level, surface ambiguity early, research efficiently, and connect implementation choices to product and engineering tradeoffs. Staff-level answers also frame the longer-term constraints without overbuilding the exercise in front of them.

Practice problems in this module

Each of these is a downloadable, multi-file codebase modeled on a reported interview, with a candidate prompt, sample data, and tests. The tests start red on purpose; they define the finish line.

Web CrawlerHardAsked at Anthropic

Build a web crawler against a bundled toy site, then make it concurrent.

Parse CSV TransactionsMediumAsked at Stripe

Build a tool that summarizes payment processor exports, then validates refunds and the links between them.

Find Duplicate FilesMediumAsked at Anthropic

Write a tool that groups files with identical contents across a directory tree, including symlinks and permission errors.

Work at least one of them under a timer as a live round, and one as a take-home with a README. The skills overlap, but the deliverables differ, and it's worth feeling that difference before an interviewer makes you feel it.