Receiving a technical case or take-home assignment does not mean you should immediately open your editor, spreadsheet or Figma. Before producing anything, turn the brief into a small execution agreement: what must be delivered, how much time the company expects you to invest, the calendar deadline, which tools are allowed, how the work will be evaluated and what will happen to the material afterward.
This alignment is not unnecessary formality. The Indeed employer guide recommends explicit instructions, room for questions, clear evaluation criteria and a reasonable due date; it also warns against turning the exercise into free work tied to the company’s real problems. The 2026 Final Round AI guide reinforces timeboxing, documenting decisions and asking about AI when the policy is not stated. For candidates, the practical consequence is simple: reduce ambiguity before spending hours guessing what the reviewer wanted.
Before you start, separate the deadline from the timebox
“Submit by Friday” and “we expect you to spend three hours” are different pieces of information. The first is a calendar deadline; the second is an effort budget. A case may give you several days to submit while still being designed for only a few hours of work.
If the company provides a timebox, treat it as a constraint of the problem, not an invitation to polish indefinitely. Final Round AI recommends respecting the stated window and documenting what was left out when time runs out. From the employer side, Indeed even suggests considering simple projects that may take around an hour or less, specifically to respect candidates’ time. That is not a universal duration rule, but it shows why asking about expected effort matters.
If you receive only a submission date, ask: “How much working time do you expect candidates to spend on this exercise?” That answer helps calibrate depth, level of polish and how many alternatives you should explore.
Questions worth asking before you start the case
| Topic | What to clarify | Why it changes your execution |
|---|---|---|
| Scope | What is the minimum required deliverable and what is optional? | Prevents spending time on extras that are not part of the evaluation. |
| Timebox | How many hours of work are expected? | Defines depth, polish and the amount of testing or alternatives you can reasonably cover. |
| Deadline | What are the exact date, time and time zone? Is there flexibility? | Separates calendar availability from actual work time. |
| Data and assumptions | What data may be assumed? Can I create hypotheses when information is missing? | Reduces the risk of being evaluated against assumptions that were never agreed on. |
| AI and tools | Are generative AI, copilots, libraries, templates and external research allowed? Must usage be disclosed? | Avoids breaking an implicit rule or unnecessarily avoiding tools that would be part of the actual job. |
| Criteria | What matters most: solution quality, reasoning, communication, technical quality, speed or polish? | Helps allocate the timebox according to the real rubric. |
| Format | Which files, links, README, presentation or demo are expected? | Prevents a good solution from being difficult to open, run or review. |
| Follow-up | Will there be a presentation or discussion afterward? How long? | Lets you prepare to defend decisions, not only produce the final artifact. |
| Use of the work | Is the exercise hypothetical? Can the company reuse the material? Are there confidentiality requirements? | Helps you understand the nature of the task and avoid inappropriate exposure of data or real work. |
AI in a take-home: assume neither prohibition nor permission
AI has added a new layer of ambiguity to hiring processes. Some companies prohibit AI in certain stages; others allow limited use; others want to see how a candidate works with the same tools they would use on the job. The right question is therefore not “does using AI look bad?” but “what is the policy for this process?”.
If the brief says nothing, ask directly: “May I use generative AI tools for this case? If so, at which stages and with what level of disclosure?” It is also useful to clarify whether the company expects a list of tools, a note describing where AI was used, or any prompt record.
Final Round AI recommends asking when the policy is not explicit and notes that candidates should be able to explain everything they submit. That is a sound operating rule even when AI is allowed: AI may accelerate research, review, ideation or implementation, but the final material must be defensible by you. If generated output enters the work, review it, test it and understand it before you put your name on the submission.
Evaluation criteria: find out what “good” means
Two reviewers can look at the same case and value different things. An engineering team may prioritize readability, tests and architecture decisions; a product team may care more about prioritization and assumptions; design may assess reasoning, constraints and flow clarity; content teams may focus on voice, audience fit and editing.
Indeed recommends that employers use specific evaluation areas and criteria to make assessment more objective. As a candidate, you can ask for the rubric directly or, when no formal rubric exists, ask which two or three aspects matter most. That is better than assuming that more pages, more features or more polish automatically mean stronger performance.
If the company says it mainly wants to assess reasoning and communication, reserve part of the timebox for documenting decisions. If technical execution matters most, prioritize functionality, testing and usage instructions. If business judgment is central, make assumptions, impact and trade-offs explicit.
Document assumptions instead of hiding gaps
Take-homes often contain incomplete information on purpose. The problem is not working with assumptions; the problem is using invisible assumptions and later discovering that the reviewer imagined something else. Add a small “assumptions and decisions” section to your README, document or presentation.
- Assumption: what you assumed because the brief did not specify it.
- Decision: what you chose to do within the available time.
- Alternative: what you considered and did not choose.
- Trade-off: what you gained and what you sacrificed with the choice.
- Next step: what you would do with more time or data.
This record serves two purposes: it makes the submission easier to review and prepares you for the follow-up. The Final Round AI guide highlights the importance of documenting constraints, decisions and what you would do next because the later discussion often tests whether the candidate understands and can defend their own work.
Data, access and confidentiality: use only what is necessary
If the case involves a dataset, tool account, repository or internal information, confirm which resources were provided and what may be used. Avoid putting data from previous employers, third-party personal data, real credentials or confidential material into a hiring assignment.
When the challenge looks very close to a live business problem, it is reasonable to ask whether the exercise is simulated and how the material will be used. Indeed recommends that employers separate assignments from current company problems so the selection process does not become free work. A candidate can ask neutrally: “Is this exercise for evaluation only, or could the material be incorporated into a real project?”
If there is a confidentiality or assignment-of-rights agreement, read it before starting and treat specific legal questions as a matter for professional advice rather than as a minor execution detail.
Build the submission so it can be reviewed without you in the room
A strong take-home should not depend on an oral presentation to make sense. Before sending it, make sure another person can open, understand and test the material. The structure varies by field, but a lean package often includes:
- a few lines explaining how you understood the problem;
- the main deliverable in the requested format;
- instructions to open, run or navigate it when needed;
- relevant assumptions, decisions and limitations;
- a note about AI and other tools if agreed or required;
- what remained outside the timebox and what you would do next;
- links and permissions tested before submission.
Do not turn documentation into a second project. Its purpose is to reduce the reviewer’s effort, not double yours.
Five-minute checklist before submission
- Is the minimum requested deliverable present?
- Does the file or link open without depending on your personal account?
- Are the instructions to run or review it clear?
- Did you respect the timebox or document where you stopped?
- Are the main assumptions and decisions visible?
- Is your use of AI and tools consistent with the agreed rule?
- Are there any exposed credentials, personal data or confidential information?
- Are incomplete parts acknowledged instead of hidden behind polish?
- Are the date, time and submission channel correct?
- Can you explain every part of the solution in a follow-up conversation?
When the brief is still ambiguous
If you asked reasonable questions and received no answer, document the assumptions you adopted and execute within a defined time limit. The goal is not to eliminate all uncertainty; it is to stop uncertainty from consuming unlimited hours. If the ambiguity affects something critical — for example AI usage, confidentiality, data access or a scope much larger than suggested — it is worth pushing for alignment before investing substantial work.
It is also legitimate to evaluate the process itself. A take-home is a sample of the candidate’s work, but the way a company defines the exercise is also a sample of how it communicates priorities, constraints and feedback.
A short message to align expectations before you start
You do not need to send ten questions if the brief already answers most of them. Focus on the gaps that materially change your execution. A concise example:
Thanks for sending the case. Before I start, I’d like to confirm four points so I can calibrate the submission: the expected timebox, the priority evaluation criteria, the policy for AI and external tools, and whether there is any required format or assumption beyond the brief. I’d also like to confirm whether the exercise is for evaluation only and whether there will be a follow-up conversation to discuss the decisions.
The strongest sign of preparation is not starting faster. It is starting with a clear understanding of what problem is being evaluated, which constraints are part of it and how to make your reasoning verifiable.
