Take-home assignment tips: scope, document and present your work

Read the brief twice before you start

Most candidates skim the brief and dive in. That is how you spend four hours solving the wrong problem. Read the brief once for the big picture, then read it again to pull out every constraint: time limit, format, tools allowed, and the specific question being asked.

Write down what you think the company is trying to learn about you. A product brief asking you to 'improve retention' is really asking whether you can prioritise, use data and communicate trade-offs. A coding task is rarely just about the code; it is about readability, testing and how you handle edge cases. Knowing the underlying goal shapes every decision you make.

• Note the stated time limit and treat it as a hard cap, not a suggestion
• Identify the deliverable format: slide deck, written doc, working code, or a combination
• Flag any ambiguous terms and decide how you will interpret them, then state that interpretation in your submission
• Check whether the company has said what they value most, for example 'we care more about reasoning than polish'

How to scope the work so you finish on time

Scope creep is the most common reason candidates submit late or submit something half-finished. Before you write a single line or slide, list every thing you could do, then cut it to what you can do well inside the time limit.

A useful rule: spend roughly 10 percent of your time planning, 70 percent executing and 20 percent reviewing and packaging. For a four-hour task that is about 25 minutes planning, 2 hours 45 minutes doing, and 50 minutes reviewing. Adjust for your own pace, but protect the review time. Rushed endings are the most common flaw reviewers mention.

1. List every section or feature you could include
2. Mark each as must-have, nice-to-have or out of scope
3. Cut everything that is not must-have unless time allows
4. Write one sentence describing what your submission will and will not cover, and include it in your opening

Documenting your reasoning as you go

Reviewers often care more about how you think than what you built. A candidate who ships a simple solution and explains every trade-off clearly will usually beat one who ships something complex with no explanation.

Keep a short running log while you work. Note the decisions you made and why, the options you rejected and why, and any assumptions you had to make. This log becomes the backbone of your write-up and stops you from forgetting your own reasoning by the time you sit down to present.

• Write assumptions at the top of your document before anything else
• For each major decision, note the two or three alternatives you considered
• If you ran out of time on something, say what you would do next and why
• Avoid phrases like 'I would have done X if I had more time' without explaining the approach; be specific

Structuring your submission for easy review

Reviewers often look at ten or more submissions in a sitting. A clear structure is a courtesy that also signals professional communication skills. Lead with a one-paragraph summary: what you were asked to do, what you did, and the main finding or recommendation. Everything after that is supporting detail.

For written documents, use headings that match the sections of the brief. For slide decks, put your recommendation on slide two, not slide ten. For code, include a README that explains how to run it, what it does and what you would improve. Never make the reviewer hunt for your conclusion.

1. Opening summary: problem, approach, recommendation in three to five sentences
2. Assumptions and scope: what you included and what you left out
3. Your work: analysis, design, code or whatever the task required
4. Trade-offs and alternatives: what you considered and why you chose this path
5. Next steps: what you would do with more time or data

Presenting the assignment in a follow-up interview

Many companies schedule a 30 to 60 minute debrief where you walk through your submission. This is not a defence; it is a conversation. The interviewer wants to see that you understand your own work and can discuss it under light pressure.

Prepare a two-minute verbal summary you can deliver without looking at your slides. Anticipate the three most obvious weaknesses in your approach and have honest answers ready. If you made a simplifying assumption that a reviewer might question, address it before they ask. Saying 'I knew this was a limitation and here is how I would address it in production' is far stronger than being caught off guard.

• Practice saying your summary out loud at least twice before the call
• Have your document or slides open and ready to share before the meeting starts
• If asked something you did not consider, say so directly and then reason through it live
• Ask the interviewer at the end what they would have done differently; it shows curiosity and gives you useful signal

Common mistakes that cost candidates the role

Ignoring the format requirement is the fastest way to signal poor attention to detail. If the brief asks for a one-page summary and you send a ten-page report, you have already failed one part of the task. Match the format exactly, or explain in a cover note why you deviated.

Over-engineering is equally common, especially in technical roles. A working solution with clear tests and a readable README will almost always score higher than a complex architecture that is hard to follow. Simplicity is a skill. Show it.

• Submitting without proofreading: typos in a written assignment signal carelessness
• No cover note: a short email explaining what you are sending and any context the reviewer needs takes five minutes and is often the first thing read
• Copying a public solution without disclosure: reviewers recognise common datasets and templates; if you used one, say so and explain what you added
• Missing the deadline without communicating: if something comes up, email before the deadline, not after

How Break-In Bad can help before and after the assignment

Take-home assignments usually come after a screening call, which means you have already passed one filter. Break-In Bad's on-screen interview assistant can help you prepare for the debrief that follows your submission. It listens to the interviewer's questions during the live call and shows you suggested answers only you can see, even on a shared screen. That can be useful when a reviewer asks an unexpected question about a trade-off you made or a direction you did not explore.