Take-Home Assignment Examples From Real Job Interviews
By
Samara Garcia
•
A take-home assignment is a scoped project a candidate completes on their own time, then submits and usually defends in a later interview round. The most common mistake is reading the submission window as the expected hours of work: a 48-hour window is a deadline, not a budget. Across a September 2026 review of 17 companies that publish an explicit take-home stage in their hiring process on Fonzi, every single one scheduled another round after submission. None of them ended the process at the take-home.
Documented take-home formats vary widely even among AI companies: Anthropic runs a two-hour accelerator optimization test, OpenAI gives forward-deployed engineering candidates about a week to ship a working semantic search system, and smaller startups like Vendra and AZX scope assignments to their own day-to-day work. It covers how much time to actually spend against a stated deadline, what happens in the review or walkthrough that typically follows, how to think about AI-tool use when the policy is not spelled out, and the warning signs that separate a fair assessment from unpaid production work.
Key Takeaways
A take-home is one stage in a longer process, not the finish line: every documented process in the sample scheduled a further interview stage after submission, so candidates should hold energy in reserve to discuss and defend the work later.
A stated submission window (48 hours, three days) describes the deadline, not the expected hours of work. Anthropic originally used a four-hour performance-engineering take-home, later shortened it to two hours, and then replaced that version after Claude Opus 4.5 matched the strongest human applicants under the time limit.
Only a small fraction of documented processes state an explicit AI-use policy, so silence should never be read as blanket permission or prohibition. When in doubt, ask, and be ready to explain how you directed and verified anything AI-assisted.
What Is a Take-Home Assignment in a Job Interview?
A take-home assignment is a self-contained project a candidate completes asynchronously, then submits for review. In AI and software engineering hiring, the artifact is usually a scoped version of the team's actual work rather than an abstract puzzle. Anthropic's performance engineering team, for instance, asks candidates to optimize code running on a simulated accelerator, a challenge the team has used since early 2024. More than 1,000 candidates have completed it and dozens now work at Anthropic, including engineers who brought up the company's Trainium cluster and have shipped every model since Claude 3 Opus, according to Anthropic's engineering team. Anthropic has since released the retired version publicly, so anyone can attempt it: beat 1,487 cycles, the best Claude Opus 4.5 managed at launch, and the team invites you to email performance-recruiting@anthropic.com with your code, with the repository hyperlinked. OpenAI's Forward Deployed Engineer loop takes a different shape: candidates build a semantic search system over a product catalog, then defend their approach in a live technical walkthrough where interviewers press on why one path was chosen over another.
Other documented formats include extending an API endpoint, wiring a retrieval call, or producing a small product demo for a described customer scenario, and candidates may be asked to propose solutions to a specific user-engagement problem rather than to solve a generic data-structures puzzle. The common thread across these formats is fidelity to real work: a good take-home mirrors a problem the team actually faces but narrows it to a scope the candidate can complete, explain, and defend.
Where Take-Home Assignments Fit In The Interview Process
Take-home assignments are never the final stage in the documented processes reviewed here; every one of the 17 companies scheduled at least one further interview round after submission. Placement in the loop varies. At the YC-backed manufacturing startup Vendra, candidates move from a founder conversation into a take-home challenge with a short, multi-day window, then into a walkthrough of the work before a final culture conversation. Vendra says its Full Stack ML Engineer interview process can be completed in four to five days, depending in part on how quickly the candidate completes the take-home challenge.
The practical implication is to plan for another evaluation stage after you submit. Retain enough familiarity with your own work to discuss or extend it later, and if the documented process includes a paid trial or an onsite build day after the take-home, avoid exhausting your effort on the asynchronous stage alone. Distribute energy across the full loop rather than treating the take-home as the only opportunity to make your case.
How Long to Spend: Interpreting Stated Time Limits
A stated submission window describes a deadline, not an expected hour count, and conflating the two is one of the most common mistakes candidates make. OpenAI's SWE take-home, sometimes called a Work Trial, is the rare take-home that is paid, reported at roughly $1,000 for a 48-hour window under NDA. Prep guides that collect candidate reports put the actual work closer to three to six hours depending on seniority. Reviewers consistently describe reliability, testing, and a clear README as weighing more than feature count, and OpenAI's current published interview guide does not list a Work Trial as a default stage, so confirm with your recruiter whether it applies to your loop.
Companies express timing differently. Some state a numeric effort estimate, some give a hard deadline, and some leave it open with language like "take the time you need," which is not an invitation to gold-plate the submission. If a company leaves timing open, ask the hiring manager for an expected range, and if none is offered. If no expected effort is provided, ask the hiring manager for guidance and set a personal cap based on the assignment's stated scope rather than treating the entire submission window as working time.
Decide on a time budget up front, aligned with whatever range the company states, and stop once the work satisfies the assignment's scope and you can coherently explain every decision in it. If an assignment is taking substantially longer than the company led you to expect, pause and clarify the scope rather than assuming additional hours are required.
The Debrief: What Happens After a Take-Home Assignment
Of the 17 documented company processes on Fonzi, six explicitly describe a live review, debrief, or walkthrough of the submitted work, and the other 11 route candidates into a different interview stage instead. The Anthropic, OpenAI, Vendra, and AZX examples in this article come from public documentation rather than that sample. When a debrief exists, it carries real weight: it shows how well a candidate understands, explains, and adapts their reasoning under questioning, which a static artifact cannot fully capture on its own. Candidates may be asked to walk through their solution, discuss key assumptions, explain alternatives they rejected, and answer questions about failure cases or how they would measure the system's effectiveness after launch.
For AI infrastructure and LLM-platform roles in particular, expect questions about reliability, cost, latency-quality tradeoffs, maintainability, and observability, framed as preparation topics rather than universal scoring criteria. A few concrete ways to prepare:
Re-read your own code or artifact the night before. Ensure you can explain every decision.
List design decisions and the alternatives you rejected, with reasoning.
Prepare to reason about data quality assumptions and edge cases.
Draft a short list of "if I had another two hours, here is what I would improve" talking points.
The goal is to understand and explain your own implementation, not to over-polish work you cannot confidently defend afterward. The absence of a formal debrief is not itself a warning sign, since 11 of the 17 documented processes simply route candidates into a different stage instead, but it is worth knowing which kind of process you are in so you can prepare accordingly.
Comparing Real Take-Home Formats Across AI Companies
Publicly documented take-home formats differ in scope, stated time expectations, and the interview stage that follows submission.
Company / Source | Role | Take-Home Scope | Stated Time Limit | What Follows The Assignment |
Anthropic | Performance Engineering | Optimize code for a simulated accelerator | 2 hours (originally 4, later reduced) | Additional live technical interview rounds |
OpenAI | Forward Deployed Engineer | Build a semantic search system over a product catalog, with code, a running app, and a recorded video walkthrough | About a week to submit, roughly five hours of reported work (candidate reports; not OpenAI-published) | Live technical deep-dive, then further technical rounds |
OpenAI | Software Engineer (Work Trial) | Extend or build a functional system component | 48-hour window, roughly 3 to 6 hours of actual work | Reviewed against production-readiness criteria alongside correctness |
Vendra (YC-backed) | Full Stack ML Enginee | Take-home assignment related to Vendra's day-to-day tasks | Multi-day submission window | Walkthrough of the work, then a founder or culture conversation |
AZX | Senior ML Engineer (Client Solutions) | Written take-home assignment | Not publicly specified | Live two-hour technical session with the engineering team |
Take-Home Versus Paid Work Trial or Build Day
A take-home and a paid work trial serve different purposes inside a hiring process. The take-home gives a candidate an asynchronous, self-paced assessment, while a paid trial creates a higher-commitment opportunity for both sides to evaluate collaboration, debugging behavior, and cross-functional communication under conditions closer to real work. When a documented process places a paid trial after the take-home, candidates first need to clear the earlier assessment stages, and the presence of a paid trial is itself a positive signal about how a company treats candidates' time, since it means the team is investing in evaluating fit rather than leaning on unpaid labor alone.
For candidates navigating both stages, aim for work that is clean, discussable, and honest on the take-home, and save demonstrations of broader ability, architectural thinking, collaboration, and live debugging for the work trial that follows. Not all of a candidate's effort should go into the first stage.
Using AI Tools On A Take-Home Assignment
There is no safe default for AI-tool use on a take-home, and treating silence as permission is a common mistake. Only two of the 17 Fonzi processes state an explicit AI-use policy. Employers that do publish one are usually unambiguous: Anthropic tells candidates to complete take-home assessments without AI unless the instructions say otherwise, and Vendra's Full Stack ML Engineer posting simply says Use everything.
The other 15 say nothing about it in their structured interview plan, which should be read as an open question to ask the hiring manager rather than as tacit approval or prohibition either way.
When AI use is explicitly permitted or required, be ready to explain how you chose, directed, verified, and understood whatever the tool produced, since that explanation is often what a live review is actually testing. A few practical habits:
Note in your readme where AI helped and what you verified manually.
Double-check generated code with tests and a manual read-through rather than trusting it as-is.
Be ready in any follow-up discussion to explain how AI was used and show you understand the resulting code.
Avoid pasting proprietary prompts, customer data, or problem-statement details into third-party models without checking the company's guidelines first.
The underlying idea is to use AI to move faster, not to replace your own understanding of the system you are submitting.
When A Take-Home Assignment Is A Warning Sign
The assignment itself is a data point about the company running it, and a few patterns are worth watching for. A scope that would take a week of full-time work with no compensation or clarity on expected effort is one red flag. A request to solve a live production problem the company could directly reuse blurs the line between candidate evaluation and unpaid production work. Ambiguous ownership of the submitted work, with no explanation of how it will be used, is another, as is a vague or absent explanation of how the work will actually be evaluated.
Before starting, ask what stage follows the take-home so you know whether to prepare for a walkthrough, another technical interview, or a different form of evaluation. The more useful test is whether the company gives clear answers about evaluation, ownership, and expected effort when asked. At senior levels especially, it is reasonable to withdraw politely from a process that treats the take-home as free talent acquisition, and to prioritize companies that respect their own stated time limits and build the assignment into a thoughtful overall loop.
How To Prepare Strategically For A Take-Home Interview Assignment
The most useful thing a candidate can do before starting is clarify scope and constraints directly with the hiring manager: expected working time, allowed tools, evaluation criteria, submission requirements, and what stage follows. From there, a short execution checklist tends to hold up well across roles:
Design a minimal but realistic solution that addresses the problem statement directly, rather than one that reaches for extra scope.
Write a short readme focused on key assumptions, tradeoffs, and what you would improve with more time.
Include tests or evaluation hooks where the assignment supports them, and reserve part of your time budget for cleanup and documentation rather than only new features.
If a live review follows, practice a concise walkthrough and be ready to answer questions about decisions, tradeoffs, limitations, and extensions.
Keep a running list of "what I would do next" items, both to show awareness of production constraints and to evaluate your own work honestly.
Reasoning you can clearly explain is worth more than polish you cannot defend under questioning. That is the quality good take-home assignments are actually built to reward.
How Fonzi Can Help Candidates and Companies Get the Take-Home Stage Right
Designing a take-home that actually reflects real work, and reviewing what comes back from it, takes real time from an engineering team, which is part of why scope and expectations vary so widely from one company to the next. Fonzi is a curated AI engineering hiring marketplace that connects companies with pre-vetted AI and software engineers through structured technical assessments.
For candidates, a more structured evaluation process can make it clearer what will be assessed before they start writing code. Fonzi also runs Match Day, where companies meet batches of pre-vetted AI and software engineers which gives candidates who have already been through a structured assessment a faster path to multiple conversations at once. It is one way to reduce friction for candidates moving through a multi-stage technical hiring process.
Summary
Treat ambiguity about time, allowed tools, and evaluation criteria as something to clarify before you begin rather than something to guess at while you work. Every documented process reviewed here scheduled another stage afterward, so the candidates who do best tend to be the ones who match their effort to the stated scope, keep enough energy in reserve to defend their work later, and treat ambiguity, whether about time limits, AI-tool policy, or evaluation criteria, as something to clarify rather than guess at.
The company running the process reveals itself in how it handles that ambiguity. A team that states a clear time expectation, explains how it will evaluate the work, and builds a genuine debrief or next stage into the loop is telling candidates something useful about how it operates day to day.
FAQ
How much time should I actually spend if a company gives a vague take-home assignment time estimate?
How should I respond if a take-home assignment looks like unpaid production work?
Is it acceptable to reuse snippets from past projects or open source in a take-home coding assignment example?
What are some real take-home coding assignment examples?
Should I handle an ML researcher take-home differently from a software engineer take-home assignment?
