Take-Home Coding Assignments: What Reviewers Actually Check

Key Takeaways

• Turn the brief into a checklist, and clarify ambiguities that would change your implementation.
• Respect the stated time limit. Protect the required behavior, tests, and handoff before adding extras.
• Make the project easy to evaluate: reproducible setup, meaningful tests, an honest README, and readable commits.
• Prepare to explain your decisions, limitations, and next steps. Follow the assignment’s AI policy and understand every line you submit.

A strong take home coding assignment demonstrates working behavior, sensible scope, useful tests, clear documentation, and decisions you can defend. Treat your README, commit history, and follow-up explanation as part of the submission—not cleanup after the coding.

The employer’s rubric comes first; the checklist below is preparation guidance, not a universal scoring system. There’s concrete support for looking beyond feature completion: Monzo’s January 29, 2025 mobile-interview guide explicitly emphasizes prioritization, design instincts, and reasoned trade-offs.

Read the Brief Before Choosing the Architecture

Read the instructions twice: first for the problem, then for the constraints. Before opening an editor, separate what you must deliver from what you merely think would be impressive.

• Required behavior: What must a user or caller be able to do?
• Constraints: Required language, supplied starter project, dependency restrictions, time limit, and submission format.
• Deliverables: Repository, archive, tests, README, screenshots, or deployment, where requested.
• Ambiguities: Unclear validation rules, persistence requirements, expected scale, or failure behavior.

Ask questions whose answers would change the solution. For a hypothetical task tracker, whether tasks must survive a restart matters more than whether you should use your preferred formatter. Send a small, prioritized set of questions rather than outsourcing every implementation decision.

If an answer won’t arrive before you need to start, record a reasonable assumption and isolate the affected decision. Don’t quietly turn an explicit requirement into an assumption because it’s inconvenient.

Clarify the AI Policy Too

Follow the assignment’s stated policy on AI assistants. If it’s silent or ambiguous, ask before using one; don’t assume an exception for autocomplete, generated tests, or documentation. Provide whatever disclosure the instructions require.

If assistance is allowed, you still own the submission. Be ready to explain every line you submit, including generated code, assertions, configuration, and dependencies. Replace anything you cannot explain or verify.

Scope Your Take Home Coding Assignment to the Time Limit

Work backward from the deadline. Aim for a small, complete path through the required behavior before polishing optional features. For the task tracker, that might mean creating, listing, and completing tasks with the required storage behavior—not adding accounts, notifications, and a deployment platform.

For an illustrative four-hour assignment, you could budget:

• 15 minutes: Read, clarify, and outline acceptance criteria.
• 120 minutes: Implement the required behavior.
• 45 minutes: Add and strengthen focused tests.
• 40 minutes: Document setup, decisions, and limitations.
• 20 minutes: Verify the final submission from a clean checkout.

This is a planning example, not an industry standard or a prescribed sequence. Write tests and documentation as you go; the budget simply reserves time for them.

At the midpoint, compare what works against the brief. Cut optional styling, speculative abstractions, and extra infrastructure before cutting required behavior. If the requirements genuinely don’t fit the stated limit, ask which outcomes to prioritize.

Make the Implementation Easy to Review

Use straightforward names, small cohesive modules, and explicit failure paths. Keep business rules distinguishable from input handling and storage so you can explain each responsibility without navigating through unrelated code.

Google’s code-review guidance checks design, functionality, complexity, naming, tests, and documentation. It specifically warns against building generality or functionality that the current problem doesn’t need. Use that as a self-review lens, not as evidence of a particular employer’s hiring rubric.

Before adding a dependency or architectural layer, ask: what requirement does this satisfy, and what complexity does it remove? Prefer a direct implementation when the abstraction has no present job. If you inherit a starter project, avoid unrelated rewrites.

Apply basic care: validate untrusted input, avoid committing credentials, and make failures understandable. Don’t describe the project as production-ready unless you can defend that claim.

Write Tests That Demonstrate the Important Behavior

Choose tests by risk and requirements, not by how quickly you can increase the count. Google’s review guidance asks whether tests make useful assertions and would actually fail when the implementation is broken. That’s a better review question than whether a test merely executes a function.

For the hypothetical task tracker, agree on the behavior first, then cover cases such as:

These are example expectations, not requirements to impose on every assignment. Add focused unit tests for important rules and an integration test where you need confidence that components work together. For a UI, test meaningful interactions rather than private component details; Testing Library’s guiding principles favor tests that resemble real usage.

Keep test data explicit and repeatable. Avoid depending on a live third-party service unless the exercise requires it. When using a substitute for an external dependency, preserve the application behavior you actually want to verify.

Before submitting, deliberately break an important rule and check that its test fails, then restore the implementation. For more on choosing useful checks, see our guide to the benefits of unit testing.

Write a README That Lets Someone Else Run It

GitHub describes the README as a place to explain what a project does and how to get started, and notes that it’s often the first item a repository visitor sees. For an interview submission, make that entry point operational rather than promotional.

Include the information another engineer needs without access to your machine:

1. Overview: What you implemented and where to start reading.
2. Prerequisites: The runtime and tooling you actually tested, plus required services.
3. Setup and execution: Exact installation, configuration, startup, and test commands.
4. Example usage: A short workflow and the expected result.
5. Decisions and assumptions: The important choices and why they fit the brief.
6. Limitations: Known bugs, missing requirements, and deliberately excluded extras, clearly distinguished.
7. Time and next steps: Honest time spent, if requested, and a prioritized improvement list.

Test the instructions from a clean checkout or extraction. Follow only what you wrote: don’t rely on an untracked configuration file, existing local data, or a command you remember but never documented. If configuration is necessary, include safe example values rather than credentials.

Explain trade-offs with consequences. If you chose in-memory storage and the brief permits it, explicitly state that data disappears when the process restarts. If persistence is required, in-memory storage is an unmet requirement—not merely a simpler architectural preference.

Avoid a generic “with more time” shopping list. Identify the next change, the problem it addresses, and why it comes before the others.

Keep Commit History Useful, Not Theatrical

If you’re submitting a Git repository, commit coherent changes as you work. Git’s own contribution guidance recommends logically separate changesets and messages that explain the change and, where useful, its motivation.

An illustrative sequence could be:

Add task creation and listing
Reject empty task titles
Add completion behavior and missing-task tests
Document setup and storage limitations

These are example commit subjects, not a required count or prescribed development order. Prefer messages that describe behavior over labels such as “updates” or “final final.” Keep unrelated formatting changes separate when practical.

Don’t manufacture an elaborate history, backdate commits, or use timestamps as a substitute for an honest account of time spent. Review what you’re submitting, including accidental files and sensitive data.

Follow the requested delivery format. If the employer asks for an archive, don’t assume a repository link is an acceptable replacement. Our Git workflow best practices cover organizing changes beyond the interview setting.

Prepare to Discuss the Assignment in the Follow-Up

Prepare a short walkthrough rather than a file-by-file narration. Monzo’s published mobile-interview guide explicitly tells candidates to justify key decisions and explain what they would do differently with more time. Treat that as a useful rehearsal prompt, while confirming your own interview’s format.

Practice explaining the submission in this order:

1. The problem: Required behavior and the assumptions you clarified.
2. The working path: Demonstrate the main workflow.
3. The design: Trace one operation through input, business rules, and storage.
4. The evidence: Show the most valuable tests and what they don’t cover.
5. The trade-offs: Explain a deliberate omission and your highest-priority next step.

For each important choice, prepare the alternative you considered, why you rejected it, and what new requirement would change your mind. “I prefer this library” is weaker than an explanation tied to the assignment.

Expect to reason about changes: durable storage, a failed dependency, a larger input, or a new validation rule. Don’t add all of those possibilities beforehand. Instead, know which parts of your implementation they would affect.

If someone identifies a bug, investigate it directly. Describe the impact, propose the smallest fix, and explain the regression test you’d add. If you discover a defect before the interview, disclose it; don’t silently replace the submitted artifact without agreement.

Final Submission Checklist

• Compare every required deliverable with the brief.
• Run the documented setup and tests from a clean checkout.
• Check repository access or verify the archive contents.
• Remove credentials, accidental files, and misleading claims.
• Record known limitations and required AI-use disclosures.
• Rehearse the main workflow and your most important trade-off.

FAQ

How long should I spend on a take home coding assignment?

Follow the employer’s stated time limit and clarify whether setup and documentation count toward it. If the requirements don’t fit, ask which outcomes to prioritize rather than silently spending an entire weekend.

What should I include in the README?

Include prerequisites, exact setup and test commands, example usage, key decisions, assumptions, and known limitations. Verify the instructions from a clean checkout so they don’t depend on your local environment.

How many tests should a take-home assignment have?

Choose tests around required behavior and likely failures rather than an arbitrary count. Prioritize the main workflow, important validation rules, boundary cases, and an integration check where components need to work together.

Should I include multiple Git commits?

If you’re submitting a repository, use meaningful commits for coherent changes unless the instructions say otherwise. Don’t manufacture commits to reach a target count; follow the requested submission format.

Can I use AI for a take-home coding assignment?

Use AI assistants only as permitted by the assignment’s policy, and ask if the rules are unclear. Follow any disclosure requirements and be ready to explain and verify every line you submit.

Further Reading

• Google: What to Look for in a Code Review — design, complexity, tests, and documentation.
• GitHub: About the Repository README File — explaining a project and helping readers get started.
• Pro Git: Contributing to a Project — logical commits and useful commit messages.
• Testing Library: Guiding Principles — testing behavior through realistic usage.
• Monzo: Preparing for Mobile Interviews — a published example of timeboxing, prioritization, and follow-up discussion.