Take-home assignments divide the hiring world. Candidates either love them (no whiteboard pressure) or hate them (unpaid labor). Companies either swear by them (real work signal) or avoid them (completion rates tank).

The difference is execution. A well-designed take-home gives better signal than any whiteboard interview. A poorly-designed one wastes everyone's time and damages your employer brand.

After testing dozens of formats, here's what actually works.

When Take-Homes Make Sense

Use Take-Homes When Avoid Take-Homes When
Role emphasizes code quality Hiring at high volume (>50/quarter)
Candidates have flexibility Role requires real-time collaboration
You'll review thoroughly Timeline is very compressed
Problem can be realistic Candidates are passive (limited time)

The data: Companies using well-designed take-homes report 35% higher correlation with job performance compared to whiteboard interviews[^1]. But completion rates average only 60-70% vs 95%+ for live interviews.

The Take-Home Framework

Time Investment Rules

Candidate Level Max Time Compensation
Junior (L3) 2-3 hours Optional
Mid (L4) 3-4 hours Recommended
Senior (L5+) 3-4 hours Expected

Never exceed 4 hours. If your assessment requires more, your scope is wrong.

Compensation options:

  • $200-500 flat fee
  • Gift card on completion
  • Donation to charity of choice

What to Include

Every take-home should have:

  1. Clear problem statement (not vague or open-ended)
  2. Explicit requirements (what "done" looks like)
  3. Time expectation (be honest)
  4. Evaluation criteria (what you're assessing)
  5. Questions welcome (how to reach you)

What NOT to Include

  • Problems requiring specific domain knowledge
  • Setups that take >30 minutes
  • Vague scope that invites over-engineering
  • Anything resembling free consulting

Assignment Templates by Role

Backend Engineer Take-Home

Problem: Build a simple REST API

Build a REST API for a URL shortener service with the following endpoints:

  • POST /urls - Create a short URL
  • GET /urls/:code - Redirect to original URL
  • GET /urls/:code/stats - Return click statistics

Requirements:

  • Persist data (your choice of storage)
  • Handle concurrent requests correctly
  • Include basic input validation
  • Write tests for key functionality

Time: 3-4 hours

Evaluation criteria:

  • Code organization and clarity (30%)
  • Correctness and edge case handling (25%)
  • Testing approach (25%)
  • API design decisions (20%)

Deliverable: GitHub repo with README explaining your decisions

Frontend Engineer Take-Home

Problem: Build a data display component

Build a React component that displays a paginated, filterable table of users.

Data source: [provided mock API endpoint]

Requirements:

  • Display user name, email, signup date
  • Filter by name (text search)
  • Sort by any column
  • Pagination (10 items per page)
  • Loading and error states
  • Responsive design

Time: 3-4 hours

Evaluation criteria:

  • Component design and reusability (30%)
  • State management approach (25%)
  • UX polish and attention to detail (25%)
  • Code clarity and organization (20%)

What we're NOT evaluating:

  • Visual design (we have designers)
  • Test coverage (nice to have, not required)

Deliverable: GitHub repo + deployed demo (Vercel, Netlify, etc.)

Full-Stack Take-Home

Problem: Build a mini feature

Build a simple bookmark manager with the following functionality:

Backend:

  • API to create, read, update, delete bookmarks
  • Each bookmark has: URL, title, tags, created date

Frontend:

  • Display bookmarks in a list
  • Add new bookmark form
  • Filter by tag

Time: 4 hours (strict limit)

What matters most:

  • Working end-to-end solution
  • Clean code on both ends
  • Reasonable technical choices

What doesn't matter:

  • Visual design
  • Authentication
  • Deployment

Deliverable: GitHub repo with setup instructions

Senior/Staff Take-Home

For senior roles, focus on decision-making over implementation:

Option A: Design Document

We're building [real problem your company faces]. Write a technical design document covering:

  • Problem analysis and requirements
  • Proposed architecture
  • Key technical decisions and alternatives considered
  • Potential risks and mitigations
  • Rough implementation plan

Time: 3-4 hours

Evaluation: Decision quality, communication clarity, consideration of trade-offs

Option B: Code Review

Review this pull request [link to PR] as if you were the senior engineer on the team.

  • What feedback would you give?
  • What concerns do you have?
  • What would you want clarified before approving?

Time: 1-2 hours

Deliverable: Written review (can be in a doc, doesn't need to be on the PR)

Evaluation Rubrics

Code Quality Rubric

Score Description
4 Exceptionally clean, well-organized, production-ready
3 Clean and clear, minor improvements possible
2 Functional but has organization or clarity issues
1 Difficult to follow, significant quality concerns

Technical Decisions Rubric

Score Description
4 Excellent choices with clear reasoning, considers trade-offs
3 Good choices that work well for the problem
2 Acceptable choices but missing consideration of alternatives
1 Questionable choices or unable to explain decisions

Completeness Rubric

Score Description
4 All requirements met with thoughtful extras
3 All core requirements met
2 Most requirements met, some gaps
1 Significant requirements missing

The Follow-Up Discussion

Take-homes are only half the assessment. The debrief is equally important:

Questions to Ask (30-45 min)

On their approach:

  • "Walk me through your thinking when you started. What did you decide first?"
  • "What would you do differently with more time?"
  • "What trade-offs did you make and why?"

On their code:

  • "I noticed you did X here. Can you explain that choice?"
  • "How would this scale to 100x the data?"
  • "What edge cases were you thinking about?"

On extensions:

  • "If we added requirement Y, how would you modify your solution?"
  • "How would you add authentication to this?"

Red Flags in Debrief

Red Flag What It Might Mean
Can't explain their own code Didn't write it themselves
Very defensive about choices Difficulty receiving feedback
No awareness of limitations Over-estimates their work
Took much longer than stated Time management issues

Increasing Completion Rates

Typical completion rate: 60-70%. Here's how to improve:

Tactic Impact on Completion
Compensate candidates +15-20%
Send warm intro before assignment +10-15%
Provide a deadline (5-7 days) +10%
Offer to answer questions +5-10%
Clear, specific requirements +5-10%

The combination: Companies that compensate + send warm intros + have clear requirements see 85%+ completion rates.

Want help designing your take-home process? Contact SmithSpektrum for interview design consulting.

References

[^1]: Hiring assessment validity research, Journal of Applied Psychology 2024