Thursday, February 19, 2026
Coding take-home assignment examples that test real engineering work
Most coding take-homes ask for the same thing: build a to-do app, a URL shortener or a weather widget from an empty folder. That's the one situation an engineer almost never faces at work. Most of the job is reading code somebody else wrote, figuring out why it behaves the way it does, and changing it without breaking anything.
There's research behind this. A field study of 78 professional developers by Xia and colleagues (IEEE Transactions on Software Engineering, 2018) found they spent about 58% of their time on program comprehension and only about 5% actually editing code. A take-home that starts from an empty folder skips the part of the job that takes up most of the day.
The examples below all start from existing code.
Six coding take-home examples
Each one runs on a small open-source or purpose-built repo, so you never hand a candidate your production code.
1. Fix a bug, then extend the feature (backend, 3 hours). "The /orders endpoint in this repo occasionally double-charges when two requests arrive at once. Find the cause, fix it, add a test that would have caught it, then add a /refunds endpoint that uses the same pattern." What it shows: whether they read before they type, and whether the fix addresses the race or just the symptom.
2. Review a pull request (any level, 1 to 1.5 hours). "Here's an open PR against this repo. Leave the review you'd leave for a teammate." What it shows: judgment, communication and taste, at a fraction of the candidate's time. It's one of the best signals per hour you can get, and it's very hard to outsource to a chatbot without it showing.
3. Make a slow page fast (frontend, 3 hours). "This product list renders 2,000 rows and takes four seconds to become interactive. Get it under one second on a mid-range laptop. Explain what you measured." What it shows: whether they profile first or guess, and whether they can explain a tradeoff like pagination versus virtualization.
4. Add a feature under a constraint (full stack, 4 hours). "Add CSV export to this admin dashboard. Use the ORM's query builder, not raw SQL, and don't add any new dependencies." What it shows: working inside a codebase's conventions instead of around them. Constraints like this are a fair way to force a real decision.
5. Write the migration (data or platform, 3 hours). "We need to split the name column into first_name and last_name on a table with 40 million rows, with no downtime. Write the migration plan and the code for step one." What it shows: operational thinking, meaning rollback, batching and what happens halfway through.
6. Debug from logs (SRE or senior backend, 2 hours). "Here are 30 minutes of logs and metrics from an incident. Write the incident summary and the one change you'd make first." What it shows: reasoning under ambiguity. Nobody writes much code, but you learn a lot.
How long should a coding take-home take?
Between two and four hours, and say so in the brief. Anything longer turns into a weekend, and the candidates with the most options (usually the ones you want) are the first to decline. If you need more signal than four hours can give, split it into two paid stages instead of one long one.
Saying "please don't spend more than three hours" works better when the brief is tight enough that three hours is realistic. Have someone on your team do it cold first. If it takes them five hours, it'll take candidates eight.
What should you pay?
Pay for the time you're asking for, at a rate that looks reasonable next to what the job pays. For a three-hour task, a flat fee in the low hundreds of dollars is common for experienced engineers. Pay it whether or not you hire them. You're buying the signal, not the code.
Two more rules make this easy for the candidate. First, they keep the rights to what they wrote unless you hire them. Second, they get paid without chasing an invoice. If paying someone $300 means a vendor-onboarding form, a W-9 and 45 days of net terms, the payment stops reading as respect. Pudding handles the payment step for exactly this reason. For more on the case for paying, see Are unpaid take-home assignments exploitative?
How to grade the repo
Agree on the rubric before anyone looks at a submission. Here's a simple one that holds up:
- Does it run? Clone it, follow the README and run it. If that takes 20 minutes of fixing config, that's a finding.
- Is the change correct and contained? Did they fix the cause? Did they touch only what they needed to?
- Tests. Is there a test that fails without the fix and passes with it?
- The README or PR description. Did they explain what they changed, what they didn't do and why? A two-line "I'd do X next with more time" counts for a lot.
- Fit with the codebase. Does the new code look like it belongs?
Leave out things like folder-structure preferences or tabs versus spaces, unless the brief asked for them.
Then ask them to walk you through it
The finished repo is half the signal. Most candidates will use an AI coding assistant on a take-home, and that's fine, because they'll use one on the job too. What you need to know is whether they understand what they shipped.
So follow the take-home with a short recorded screenshare. The candidate opens their own repo, walks through the change, and answers follow-ups: why this approach, what breaks if traffic doubles, what they'd do differently. Twenty minutes of that tells you more than another hour of take-home. This is the format Pudding is built around. There's more on why in How many words does each hiring step give you?
A note on the research
Work samples are a good predictor of job performance, but they aren't magic. A widely cited 2022 re-analysis of selection research by Sackett, Zhang, Berry and Lievens put work-sample validity at about .33, down from the .54 that had been quoted for decades. Structured interviews came out at about .42. The practical lesson is to use both: a short, realistic take-home, then a structured conversation about it.
Related reading
- Work sample automation: how to request, collect, and pay for candidate work samples
- Types of video interviews compared
- Take-home examples for writers, designers, marketers and ops, PM and strategy roles
Josh Priollaud
Founder @ Pudding
Josh Priollaud is the founder and CEO of Pudding, a Siligo Ventures portfolio company. Josh has worked in business development roles at Cloud9 IDE, Webgility, MuleSoft and Adobe. Before his Silicon Valley career, Josh served as an Economic Development Adviser in the Peace Corps. Josh holds an MBA from the Leavey School of Business at Santa Clara University and a BS in Business Administration from Portland State University. Josh has been a full stack developer (Ruby on Rails, React) since 2020.