How to Approach an Internship Take-Home Assignment

A recruiter just sent you a project prompt with a deadline a few days out, and you're wondering how to fit it around your classes without losing a week. Here's the shift that makes it manageable: you're not graded on finishing everything. You're graded on scoping to the core problem, submitting something polished and partial, and documenting your decisions so a reviewer sees a deliberate engineer, not a rushed one. Finishing every feature is not the bar.

What a take-home assignment actually is

A take-home is a self-paced project you build over one to several days that a human then reads: they open your submission, run it, read your code, and form an opinion about how you think. There's almost always a live discussion round afterward, where they walk through it with you.

It's easy to confuse it with the rounds nearby. It is not the automated online assessment that usually comes earlier, which software grades on a clock. It is not the live coding interview where a human watches you solve a problem live. And it is not a portfolio project you build to apply; a take-home is assigned to you, with a specific prompt and deadline, inside one company's process.

Take-homes are not software-only, either. Data roles hand you a messy dataset and a question, product roles a metric to reason about, design roles a screen to rework. The approach below fits all of them: the trap is the same everywhere, doing too much too broadly and running out of time to make any of it good.

Read the prompt twice and find the core problem

Before you write a line, read the prompt twice. The first read tells you what they're asking for. The second tells you which single part is actually hard: the one piece that needs a real design decision, not boilerplate you could type in your sleep.

Almost every take-home has one core problem wrapped in decoration. Say the prompt is "build a small app that fetches data from this API and displays it." The decoration is the display: rendering a list, styling, a button. The core is the data handling: what happens when the API returns nothing, errors, or a malformed record, and how you structure the fetch so it isn't a tangle. That's where the design choice lives, and what the reviewer looks for.

So on the second read, draw a box around that core and name it in one sentence: "The hard part is handling API failures and empty states cleanly." Everything outside the box is negotiable. Everything inside it is what you build fully, first, before anything else.

Scope to what's graded: a polished partial beats a broad incomplete

Adopt this governing trade-off before you start, not at 2am when panic sets in. A working slice that nails the core beats a sprawling attempt that half-does everything and runs badly. Reviewers see the difference in about a minute, and the polished partial almost always wins.

So build the core end to end first. Get one path all the way through: it runs, it handles the obvious edge case, it does the hard thing correctly. Only once that's solid do you add breadth. What to cut, in order:

• Cut first: extra features beyond the ask, fancy UI and animations, that extra library you'd need to learn mid-project, and anything labeled "bonus" or "nice to have."
• Never cut: it runs from a clean clone, it handles at least one obvious edge case, and it ships with a README. Those three are the floor. Miss any of them and the submission reads as unfinished, no matter how clever the rest is.

How much time to spend, and when to submit

Treat the stated estimate as your target, not a floor. Most take-homes are scoped for a single workday or a few hours of real work. A multi-day window is usually about flexibility around your schedule, not a sign they expect multiple days of effort. Read a two-day deadline as "find a few focused hours in here," not "spend two days."

The heuristic that keeps you out of trouble: stop building at roughly 70% of your allotted time. Set aside six hours, and have the core working by hour four, then use the rest to test, clean up, and write the README. That last third is not slack. It's where a decent submission becomes a good one, and it's the part rushed candidates skip.

Going a little over is normal. If the prompt says three hours and you take four, nobody blinks. But three times the suggested time is both visible and counterproductive: an overbuilt submission hides the core skills a reviewer is assessing and raises the bar for the discussion round. If you cut something for time, don't hide it. Document it, coming up next.

Ask clarifying questions early

Ambiguity in a take-home is often intentional. They want to see whether you'll surface a question or silently guess wrong, so asking a good one reads as proactive, the same instinct a real teammate has.

The catch is timing. Ask within roughly the first quarter of your window, while you still have runway to act on the answer. A thoughtful question on day one looks engaged; the same one the night before the deadline looks like you started late.

Not everything is worth asking. Reserve questions for things that change what you build: "Should this handle multiple users, or is one fine?" is worth an email. Naming, formatting, or which minor library to use is not. Make a reasonable call and note it in your README, which shows you can move without hand-holding.

The README that sells your decisions

Most READMEs just say how to run the project and stop there. Yours should do more, because it's what a reviewer skims first and your best tool for making a partial submission read as deliberate rather than unfinished.

Think of it as a short decision log, not a manual, with these skimmable beats:

• How to run it. The exact commands, from a clean clone. A reviewer who can't run it can't grade it.
• What you focused on and why. Name the core problem and say you built it fully first. This frames everything else.
• Assumptions. The judgment calls you made where the prompt was ambiguous: "I assumed a single user since the prompt didn't mention auth."
• Trade-offs and what you cut. The honest part: "I skipped pagination to spend that time making error handling solid."
• What you'd do with more time. Two or three lines showing you know what a complete version looks like even though you scoped down.

Those last two sections are the magic. A reviewer reading "I cut X deliberately to nail Y, and here's what I'd add next" sees someone who made choices. The same missing feature with no note just looks incomplete.

Before you submit: the 15-minute polish pass

Save the last stretch for a quick cleanup pass. It's low effort and it's what separates a submission that looks cared-for from one that looks dumped.

• It runs from a clean clone. Test this in a fresh folder. "Works on my machine" fails more take-homes than bad logic does.
• No dead code. Delete commented-out blocks, unused files, and debug prints. Clutter reads as careless.
• Sensible names. Variables and functions that say what they do. Reviewers notice immediately.
• One obvious edge case handled. Empty input, a failed request, a missing value. Handling one well beats gesturing at ten.
• README present. The one above. Don't submit without it.

Simple beats clever: a reviewer would rather read plain code than untangle something impressive.

After you submit: prep to defend it

There's almost always a discussion round where someone asks you to walk through what you built. Treat your submission as study material, and be ready to explain every design choice, every trade-off in your README, and every library you pulled in.

That last point is a real filter. If you added a dependency you can't explain, or copied code you don't fully understand, cut it before you submit. Anything you can't defend out loud is a liability, and "I'm not sure why I used that" is a bad answer.

Frequently asked questions

What if I can't finish the core in time?

Submit what runs and be honest in the README about where you stopped and why. A partial core with a clear note still shows your reasoning: "the fetch and error handling work; I ran out of time before the last state." If it won't run at all, get one path working before covering more ground, since a submission that won't run is the hardest to grade.

Is it okay to use AI tools on a take-home?

If the company says whether AI help is allowed, follow that. Where they don't, the safe rule is the one from the defend-it section: only keep code you can walk through in the discussion round. Anything you can't explain is a liability, whether you wrote it or a tool did.

Can you ask clarifying questions?

Yes, and it reads as proactive rather than needy. Ask early, within roughly the first quarter of your window, so you have time to act on the answer. Save questions for things that change what you build, and decide and document the small stuff.

What should the README include?

How to run it, what you focused on and why, your assumptions, the trade-offs and what you cut, and what you'd do with more time. That structure turns a scoped-down submission into a deliberate one and gives you a script for the discussion round.

Three moves for today. Read the prompt twice and box the one part that needs a design decision. Set a stop-time at 70% of your window so you have room to test, clean up, and write the decision-log README. And note every assumption as you go, so defending your work later is just reading your notes back. If this take-home is one of several you're juggling, browse internships so no single result carries too much weight.