Take-Home Assignment Examples From Real Job Interviews
By
Samara Garcia
•
A 48-hour submission window for a take-home assignment is not a 48-hour deadline for work, but plenty of candidates burn the whole window anyway, then arrive at the next interview stage too drained to defend what they built. 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.
This article walks through what take-home assignments for AI and software engineering roles actually look like in practice, drawing on documented examples from Anthropic, OpenAI, the YC-backed manufacturing startup Vendra, and the client-solutions ML team at AZX. 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's own performance-engineering take-home shows how differently a company can define what "enough time" means, having cut its limit from four hours to two.
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 A Take-Home Assignment Looks Like
A take-home assignment is a self-contained project a candidate completes asynchronously, then submits for review, and 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 a number of them, including engineers who worked on Anthropic's Trainium cluster, went on to join the team. 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 solve a generic data-structures puzzle. The common thread across formats is scope: a good take-home mirrors real problems the team faces, sized down to something a candidate can complete, explain in depth, and stand behind, rather than a portfolio piece that reaches past the assignment's boundaries.
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, and the company's own job postings note that a candidate's speed on the take-home can compress the whole process down to a few days.
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, typically gives candidates a 48-hour window but scopes the actual work to roughly three to six hours depending on seniority, and instructions commonly note that clean, tested code matters more than feature completeness.
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, set a reasonable personal cap based on the assignment's scope, commonly somewhere in the two-to-four-hour range for many startup take-homes.
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. A take-home stretching past ten hours is usually a sign the scope was poorly defined, not a standard to aim for.
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; the remaining 11 move directly into a different interview stage instead. 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
The table below compares several publicly documented take-home formats for AI-focused engineering roles, illustrating how scope, stated time expectations, and the stage that follows all vary in practice even among companies in the same industry.
Company / Source | Role | Scope of Take Home | 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 walkthrough | About a week to submit | Live walkthrough and defense, 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 Engineer | Assignment related to the startup's day-to-day ML engineering work | 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. Among the documented processes reviewed, only two of 17 state an explicit AI-use policy: one requires AI tools within a short time block, and one permits any tools, references, or AI assistants a candidate wants to use. 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.
None of this means an assignment without a formal debrief is automatically suspect: only six of the 17 documented processes in this sample include one, and the rest simply move to a different interview stage. 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, built around structured technical assessments rather than one-off assignments each hiring manager has to design from scratch.
For companies, that structure means less time spent reinventing scope and evaluation criteria for every open role, and for candidates, it means a clearer picture of what is actually being assessed before they start writing code. Fonzi also runs Match Day, a recurring hiring event where companies meet batches of pre-vetted AI and software engineers during scheduled hiring windows, which gives candidates who have already been through a structured assessment a faster path to multiple conversations at once.
It is one practical way to reduce the friction on both sides of a process that, as the data above shows, rarely ends at the take-home stage anyway.
Summary
A take-home assignment is a checkpoint, not a finish line. 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?
