What this prompt does
This prompt helps you plan your approach to a take-home coding assignment without writing the solution for you. Given the [assignment_description], [time_limit], and [language], it produces a time-boxing plan across research, implementation, testing, and polish, an architecture decision with trade-off analysis, guidance on what to include versus skip under the constraint, a README structure that impresses reviewers, a testing strategy for maximum coverage in limited time, code-organization advice, edge cases worth handling, a git commit strategy, the factors separating "hire" from "no hire," and a self-review checklist.
The structure works because take-homes are judged on judgment, not just working code — and this prompt front-loads the decisions that actually differentiate submissions. The [time_limit] variable drives the time-boxing and the include-versus-skip calls, since a four-hour task demands different scoping than a weekend one. [language] shapes the architecture and testing advice, and [assignment_description] grounds the trade-off analysis in your actual brief rather than a generic template. Crucially, the prompt explicitly refuses to write the solution, so you still demonstrate your own skill while planning like a reviewer reads, which keeps the submission honestly yours.
When to use it
- You received a take-home assignment and want to plan before coding
- You need to time-box research, implementation, testing, and polish realistically
- You want a defensible architecture decision with documented trade-offs
- You need a README structure that respects the reviewer's time
- You want to know what separates a "hire" submission from a "no hire" one
- You need a self-review checklist to run before submitting
Example output
Expect a planning document, not a solution: a time-box allocation across phases for your [time_limit], an architecture recommendation with trade-off reasoning, an include-versus-skip list, a README outline covering approach, trade-offs, and what you would do with more time, a testing strategy, a commit plan, and a pre-submission checklist. It is structured so you do the implementation yourself with a clear map, and it surfaces the specific signals reviewers weigh so you can aim your limited hours at what moves a submission from "no hire" to "hire."
Pro tips
- Set
[time_limit]honestly so the time-boxing and scoping advice matches what you can actually deliver - Describe
[assignment_description]fully, including any reviewer instructions, so the architecture trade-offs fit the real task - Use the README structure literally — approach, trade-offs, and "what I'd do with more time" is what reviewers actually value
- Follow the commit strategy; a sensible commit history signals senior thinking more than one giant final commit
- Lean on the include-versus-skip list to avoid over-building, since polished scope beats half-finished ambition
- Run the self-review checklist before submitting, as the last-mile details often decide "hire" versus "no hire"
