I've reviewed somewhere around 150 take-home coding assignments as a senior engineer. Want to know a secret? About 70% of them look almost identical -- same structure, same mistakes, same missed opportunities. The assignments that stood out were rarely the most technically complex. They were the ones that showed clear thinking and professional polish.

I've also submitted plenty of my own. Some I nailed, some I botched. Here's everything I've learned from both sides of the table.

Read the Requirements Three Times (Seriously)

This sounds obvious, but I've rejected candidates who built beautiful applications that completely missed the requirements. One candidate built an entire REST API when we asked for a CLI tool. Impressive engineering, but it showed they didn't read carefully.

My process: read the requirements once to get the big picture. Read them again to identify specific deliverables. Read them a third time to catch any constraints or preferences they've mentioned -- things like "we value clean commit history" or "bonus points for testing."

If anything is ambiguous, ask. Seriously. Email the recruiter or hiring manager. "Should the API support pagination?" or "Do you want me to include deployment instructions?" Asking smart questions shows maturity, and I've never seen it count against a candidate.

The README Is Half Your Grade

I'm barely exaggerating. When I open a take-home assignment, the first thing I look at is the README. If it's the default create-react-app README or completely empty, I'm already forming a negative impression before I've read a single line of code.

Your README should include:

• Setup instructions that actually work. Clone, install, run -- three commands max. I test this. If your app doesn't start, it's an automatic rejection at most companies I've worked at.
• Design decisions and why you made them. "I chose SQLite over PostgreSQL because the assignment doesn't require concurrent writes and it simplifies setup." That's the kind of thinking we want to see.
• What you'd improve with more time. This shows self-awareness and technical maturity. "Given another day, I'd add integration tests and implement caching on the search endpoint."
• Time spent. Be honest. If it took you 8 hours on a "4-hour assignment," that's fine. If you pretend it took 2 hours when it clearly took 10, reviewers can tell.

Code Quality Over Feature Quantity

Here's the trap: many candidates try to add every bonus feature mentioned in the assignment at the expense of code quality. Don't do this. I'd rather see a core solution with clean architecture, good error handling, and a few tests than a feature-complete mess with no structure.

Specific things I look for: consistent naming conventions. Proper error handling (not just try-catch everything and swallow errors). Separation of concerns. A few meaningful tests -- not 100% coverage, but tests that show you know how to test the important stuff.

Your git history matters too. Don't make one massive commit with everything. I want to see your thinking process. "Set up project structure" then "Implement user authentication" then "Add input validation and error handling." It shows you work methodically, which is exactly what we want from a teammate.

Common Mistakes That Kill Good Submissions

Overengineering is the number one killer. I once reviewed an assignment where someone implemented a microservices architecture for a todo app. Three separate services, a message queue, Docker Compose with five containers. The assignment said "build a simple task manager." Know your audience.

Leaving in debug code, console.logs everywhere, commented-out blocks of experimental code -- clean it up. It takes five minutes and the impression it leaves is massive. I've seen otherwise strong submissions get dinged for sloppy cleanup.

Not handling the unhappy path. What happens when the API returns a 500? When the user submits an empty form? When the database connection drops? I specifically test for these, and candidates who handle errors gracefully stand out immediately.

The follow-up interview after a take-home is where you really seal the deal. You'll be asked to walk through your code, explain decisions, and discuss alternatives. Practice explaining your technical decisions out loud before that call. Use mock interview tools if you don't have a friend to practice with.

One last thing -- respect the time boundary. If they say 4-6 hours, don't spend 20. It's not fair to other candidates, and hiring managers will wonder about your time management. Do your best work within the given window, document what you'd improve, and submit with confidence.