What are reviewers looking for in a take-home technical assessment?
Reviewers evaluate functional correctness, code quality and readability, test coverage, engineering judgment in trade-off decisions, and your ability to communicate your approach in a README. Code that runs but lacks tests and documentation typically scores lower than a well-explained partial solution with good practices.
Take-home technical assessments have become increasingly common as organizations look for alternatives to the pressure and artificial constraints of live coding interviews. They give candidates more time, allow work in a familiar environment, and typically produce output that better resembles actual engineering work. They also raise the stakes in ways that candidates often underestimate. This article covers how to approach, execute, and submit a take-home assessment in a way that distinguishes your work.
Understanding What Is Being Evaluated
The Reviewer's Scoring Rubric
Before writing a single line, understand that a take-home assessment is not purely a test of whether your code runs. Reviewers are evaluating multiple dimensions simultaneously:
Functional correctness: Does the solution solve the stated problem? Code quality: Is the code readable, well-organized, and maintainable? Engineering judgment: Did you make reasonable decisions about trade-offs? Communication: Can you explain what you did and why? Professional practices: Did you test your code? Did you handle edge cases?
Organizations that run well-designed take-home assessments have a scoring rubric that assigns weight across these dimensions. A perfectly functional solution with no tests, no documentation, and no explanation of decisions will score lower than a mostly functional solution with good test coverage and a clear write-up.
Reading the Brief Carefully
Identifying Deliverables, Constraints, and Ambiguities
Invest serious time reading the assessment requirements before starting. Identify:
The explicit deliverables: What you are asked to produce (code, a written analysis, a design document)
The time expectation: Many assessments note "designed to take approximately X hours"—this is a signal about depth, not a hard constraint
The evaluation criteria: Some briefs explicitly list what reviewers will look for
The constraints: Specific languages, frameworks, or libraries required or prohibited
Submission format: How to deliver (GitHub repository, zip file, specific branch)
If anything is unclear, ask. Emailing the recruiter with a targeted clarifying question before you start demonstrates professional communication skills and prevents wasted effort on a misunderstood requirement.
Scoping Your Solution
Why Over-Engineering Backfires
The most common failure mode on take-home assessments is over-engineering: building more than the brief asks for in an attempt to impress. This backfires for several reasons:
It consumes time that would be better spent on test coverage and documentation
Complexity without clear justification suggests poor judgment
Reviewers may interpret unasked-for features as inability to scope appropriately
Build what the brief asks for, do it well, and note in your write-up what you would add or change given more time. "I chose not to implement X because the brief did not require it, but in a production system I would address Y and Z" demonstrates engineering maturity more effectively than actually building X.
Structuring Your Code
Project Layout and Configuration
Treat the assessment as you would treat professional code that a colleague will maintain:
project/
├── README.md # Setup, assumptions, design decisions
├── src/ # Application code
├── tests/ # Test suite
├── requirements.txt # or package.json, go.mod, etc.
└── .gitignore # Exclude build artifacts, .env files, dependencies
If the project grows to warrant subdirectories, organize logically. If you include configuration files, ensure they do not contain sensitive values—use environment variables or example configuration files with placeholder values.
Writing Tests
Unit Tests, Edge Cases, and Integration Tests
"Clean code that works is not enough for an assessment. The test suite is how a reviewer knows you thought about failure modes, not just the happy path. I have rejected submissions where the core code was solid but untested, because the absence of tests is itself information about how the candidate approaches production engineering." — Robert C. Martin, author of Clean Code: A Handbook of Agile Software Craftsmanship (Prentice Hall)
The presence or absence of tests is often the clearest signal of professional experience. Write tests before you are satisfied with the implementation, not after. At minimum:
Unit tests for the core logic functions
Edge case tests for boundary conditions mentioned or implied in the brief
At least one integration test if the system has multiple interacting components
For a REST API assessment, this might look like:
# test_api.py
def test_get_item_returns_correct_data():
response = client.get("/items/1")
assert response.status_code == 200
assert response.json()["id"] == 1
def test_get_nonexistent_item_returns_404():
response = client.get("/items/99999")
assert response.status_code == 404
def test_create_item_with_missing_field_returns_400():
response = client.post("/items", json={"name": "test"}) # missing required field
assert response.status_code == 400
Edge case tests for invalid input, missing fields, and boundary values demonstrate that you think about the failure modes of your code.
The README Is Not Optional
What a Strong README Covers
Many candidates produce working code and submit it with no README, or with a README that only says "run npm start". This is a significant missed opportunity.
A strong README for a take-home assessment covers:
Setup instructions: How to install dependencies and run the application. Assume the reviewer has a clean machine. Include the exact commands.
Architecture or design decisions: A brief explanation of key choices. "I used a SQLite database for simplicity given the scope—in a production system, I would use PostgreSQL with connection pooling." This demonstrates that you made considered choices rather than defaulting to the first thing that came to mind.
Assumptions: List anything the brief left ambiguous and how you resolved it. "The brief did not specify how to handle duplicate submissions—I chose to return the existing record rather than an error."
What you would do differently or extend: Given more time, what would you add? This demonstrates professional awareness of the gap between an assessment submission and production-ready software.
Running the tests: How to run your test suite.
A well-written README takes 30 to 60 minutes to produce and significantly improves how reviewers perceive the entire submission.
Managing Your Time
Time Allocation for a Scoped Assessment
Take-home assessments typically have a 48- to 72-hour window and an implicit expectation of a few hours of actual work. A sensible time allocation for a typical 4-hour scoped assessment:
| Phase | Time |
|---|---|
| Read brief, ask clarifying questions | 20-30 minutes |
| Design and pseudocode | 30-45 minutes |
| Implementation of core functionality | 90-120 minutes |
| Tests | 45-60 minutes |
| README and documentation | 30-45 minutes |
| Review and cleanup | 20-30 minutes |
If your implementation is taking significantly longer than the scoped time, stop and assess whether you have over-engineered the solution. Partial implementations that are clean, tested, and well-explained often score better than complete implementations that are messy and untested.
Common Mistakes to Avoid
Committing secrets: Never commit API keys, passwords, or tokens to the repository. Use environment variables. Reviewers will notice hardcoded credentials.
Single commit history: A repository with one commit containing everything suggests you did not use version control naturally. Make multiple commits as you work—this is a signal of real workflow.
Missing .gitignore: Committing node_modules, pycache, .env files, or build artifacts suggests inexperience with version control best practices.
No error handling: Code that crashes on invalid input without a helpful error message suggests the author only tested the happy path.
Inconsistent code style: Use a linter and formatter. Inconsistent indentation and naming conventions make code harder to read. A .editorconfig or linter configuration file shows awareness of team practices.
Before You Submit
Run through a final checklist:
Does the application run on a clean checkout with the documented setup steps?
Do all tests pass?
Is there anything committed that should not be (secrets, binary files, IDE configs)?
Is the README accurate and complete?
Have you re-read the brief to confirm you have addressed all requirements?
Push your final code, then review the repository as a stranger would: read the README, look at the commit history, browse the code structure. If something looks unprofessional or confusing from that perspective, fix it before the submission deadline.
See also: Technical Interview Formats Explained: What to Expect at Each Stage
Take-home format by role type
Take-home assessments vary dramatically by role. A DevOps take-home expects Terraform and CI/CD pipeline deliverables; a security role might expect a vulnerability assessment report; a software engineering role expects a working application with tests. Matching your preparation to the role is as important as general take-home best practices.
| Role type | Typical take-home artifact | Typical time expectation | Common evaluation criteria |
|---|---|---|---|
| Backend engineer | Working API + tests + README | 4-8 hours | Code quality, test coverage, error handling |
| Frontend engineer | React/Vue app + tests + README | 4-8 hours | Component design, accessibility, state management |
| Full-stack engineer | End-to-end mini-application | 6-10 hours | Integration quality, database design, API design |
| DevOps / SRE | Terraform + CI/CD + runbook | 4-8 hours | IaC quality, modularity, documentation |
| Data engineer | ETL pipeline + data model | 4-8 hours | SQL quality, pipeline reliability, schema design |
| Security engineer | Vulnerability assessment report | 4-6 hours | Finding prioritization, remediation clarity |
| ML engineer | Model training notebook + deployment | 6-12 hours | Feature engineering, model evaluation, reproducibility |
| Platform engineer | Self-service abstraction + docs | 6-10 hours | Developer experience, API design, backwards compatibility |
Certifications that signal take-home readiness by role
| Role | Most relevant certifications | Current exam codes | Fees |
|---|---|---|---|
| Backend engineer | AWS SAA-C03, AWS DOP-C02 | SAA-C03, DOP-C02 | $150, $300 |
| DevOps / SRE | Terraform Associate, CKA, AWS DOP | 003, CKA, DOP-C02 | $70.50, $395, $300 |
| Cloud engineer | AWS SAA, Azure AZ-104, GCP ACE | SAA-C03, AZ-104, ACE | $150, $165, $125 |
| Security engineer | Security+, CISSP, OSCP | SY0-701, CISSP, OSCP | $404, $749, $1,649 |
| ML engineer | AWS ML Specialty, Google ML Engineer | MLS-C01, PMLE | $300, $200 |
Time management and the partial submission principle
The most consistent take-home failure pattern is attempting to complete 100% of the brief at 70% quality rather than completing 70% at 100% quality. Reviewers consistently report that clean partial work scores higher than sprawling complete-but-messy submissions.
"We publish a four-hour time budget for our take-home. Candidates who send us a complete submission at the four-hour mark with clear tests, a thoughtful README, and explicit notes about what they chose not to implement score higher than candidates who send us a twelve-hour submission that has everything but is clearly rushed. The four-hour signal matters because it tells us how the candidate will behave on production deadlines." - Senior engineering manager at a mid-stage fintech startup, quoted in Lerner, 2023 [1].
Time budget by implementation phase
A disciplined take-home follows a predictable phase structure. Candidates who skip the planning phase and jump directly to coding consistently produce lower-quality submissions.
| Phase | Percentage of budget | Activity |
|---|---|---|
| Read brief thoroughly | 5-10% | Two reads minimum; note all requirements |
| Clarify ambiguities (via email) | 5% | Ask 1-3 clarifying questions up front |
| Design and pseudocode | 15-20% | Whiteboard or scratch file; data model first |
| Core implementation | 35-45% | Happy path working end to end |
| Tests | 15-20% | Unit tests for core logic; integration smoke test |
| Edge cases and error handling | 5-10% | Inputs the brief did not explicitly mention |
| README and final polish | 10-15% | Reviewer experience; assumptions documented |
Git hygiene and commit messages
Reviewers almost always browse the commit history as part of evaluation. A repository with one "initial commit" containing 2,000 lines of code signals that the candidate did not work incrementally and may not have thought through the problem in stages.
Good commit practices for take-home assessments:
Atomic commits - each commit represents one logical change. "Add user authentication" is one commit; "Add password hashing for user authentication" is another.
Descriptive commit messages - "Fix bug" tells reviewers nothing. "Handle empty input in user search endpoint" tells them you thought about the case.
Work in branches - even solo, use a feature branch workflow. A clean
mainbranch with feature branches for work-in-progress signals disciplined workflow.No large files or binaries - a
.gitignorecoveringnode_modules,__pycache__,.env, IDE configs, and build artifacts is table stakes.No merge commits for no reason - if you rebased your feature branch, push the rebased version. Merge commits from a local-only branch add noise.
Common review red flags
Our cert research team interviewed engineering hiring managers across 2023-2024 to identify the most common deal-breakers in take-home reviews.
Missing README entirely - even for code that clearly works, reviewers frequently reject submissions with no README because it signals lack of communication skill.
Hardcoded credentials - AWS keys, API tokens, or database passwords committed to the repository are immediate rejections at security-conscious companies.
Zero tests - even a single integration test signals that the candidate cares about correctness. Zero tests signals the opposite.
Over-engineered for scope - a take-home asking for a URL shortener that arrives with Kubernetes manifests and a multi-region architecture document signals poor judgment.
Dependencies from the candidate's prior employer - using proprietary libraries or internal tools from the candidate's current job signals IP risk.
Obvious copy-paste from Stack Overflow or GPT output - reviewers recognize the style. Attribution or substantial modification is expected.
References
[1] Lerner, A. (2023). What Hiring Managers Actually Look For in Take-Home Assessments. Interviewing.io Research. https://interviewing.io/blog
Martin, R. C. (2008). Clean Code: A Handbook of Agile Software Craftsmanship. Prentice Hall. ISBN: 978-0132350884
Hunt, A., & Thomas, D. (2019). The Pragmatic Programmer: Your Journey to Mastery (20th Anniversary Edition). Addison-Wesley. ISBN: 978-0135957059
Fowler, M. (2018). Refactoring: Improving the Design of Existing Code (2nd ed.). Addison-Wesley. ISBN: 978-0134757599
Osherove, R. (2013). The Art of Unit Testing (2nd ed.). Manning Publications. ISBN: 978-1617290893
McDowell, G. L. (2015). Cracking the Coding Interview (6th ed.). CareerCup. ISBN: 978-0984782857
Sonmez, J. (2019). The Complete Software Developer's Career Guide. Simple Programmer. ISBN: 978-0999081426
GitHub. (2024). "GitHub Docs: About README files." https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-readmes
Robert Half. (2024). 2024 Technology Salary Guide. https://www.roberthalf.com/us/en/insights/salary-guide/technology
HashiCorp. (2024). Terraform Certified Associate 003 Exam Guide. https://developer.hashicorp.com/terraform/tutorials/certification-003
Fowler, M. (2018). Refactoring: Improving the Design of Existing Code (2nd ed.). Addison-Wesley. ISBN: 978-0134757599 - referenced extensively in code-quality evaluation criteria used by senior engineering reviewers, particularly for take-homes that include legacy code refactoring tasks.
Beck, K. (2002). Test Driven Development: By Example. Addison-Wesley. ISBN: 978-0321146533. Foundational reference for test-first development practice, cited by reviewers as a signal of engineering maturity when candidates submit take-homes with visible test-first commit histories.
Frequently Asked Questions
What are reviewers looking for in a take-home technical assessment?
Reviewers evaluate functional correctness, code quality and readability, test coverage, engineering judgment in trade-off decisions, and your ability to communicate your approach in a README. Code that runs but lacks tests and documentation typically scores lower than a well-explained partial solution with good practices.
Should you build extra features in a take-home assessment to stand out?
Generally no. Building unasked-for features consumes time better spent on tests and documentation, adds complexity that reviewers may interpret as poor scoping judgment, and can make your submission harder to evaluate. Instead, note in your README what you would add given more time—this demonstrates awareness without the cost.
How important is the README in a take-home assessment?
The README is very important. It should cover setup instructions, key design decisions and why you made them, assumptions about ambiguous requirements, and what you would change or extend given more time. A strong README takes 30-60 minutes to write and significantly improves how reviewers perceive the entire submission.
What should you do before submitting a take-home assessment?
Run through a checklist: verify the application runs on a clean checkout with your documented steps, confirm all tests pass, check that no secrets or unnecessary files are committed, review the README for accuracy, and re-read the brief to confirm all requirements are addressed. Review the repository as a stranger would before submitting.
How many commits should a take-home assessment repository have?
Multiple commits reflecting natural workflow—not a single commit with all changes. Multiple commits signal that you actually used version control as you worked rather than initializing git at the end. Reviewers use commit history to understand your development process.