In this article
Before you start
This page sits in the interview process path and covers the written pieces some loops set outside the live rounds. For the wider take-home format, see the take-home assignment example.
Why interviewers ask this
A written exercise shows how you think when nobody is in the room to prompt you. A live answer can be rescued by a follow-up question; a document cannot, so the reader sees your reasoning exactly as you left it.
The format has a public precedent. Amazon says it does not use slides and instead writes narratively structured six-page memos, and that a great memo might take a week or more. Candidates on Glassdoor report a written step before the onsite for principal-level Amazon roles, in the principal engineer reports and the principal software engineer reports. These are candidate reports, not company policy.
A weak sample narrates events and ends with a list of lessons. A strong sample opens with a decision, shows the options considered and says what was left out.
Writing samples from first principles
- Writing sample
- A writing sample is a piece of original writing, such as a memo, an essay, a short document or a spec, that a hiring team reads to judge how a candidate reasons, makes decisions and communicates, because it shows that work without a live conversation to guide it.
- Tech spec
- A tech spec is a written plan for how to solve one technical problem. It states the context, the goals, the proposed design, the alternatives that were considered and the trade-offs accepted, so that a reviewer can challenge the decisions before anything is built.
- Non-goal
- A non-goal is a stated item of work that a document deliberately leaves out. Naming non-goals sets the scope, shows the reader which trade-offs were chosen on purpose and stops the reviewer from marking you down for work you never promised.
In plain words
Think of a math exam where you must show your work. The final answer matters less than the steps that lead to it. A writing sample is the same idea. The reader wants to see how you got to the decision. A reader cannot ask you what you meant, so every step you leave out is a step they must guess.
The analogy breaks in one place. A math problem has one right answer. A spec or a memo has several defensible answers, so the reader judges your reasoning, not a match with a key.
In one precise sentence, a writing sample is evidence of your judgment, so each paragraph should either state a decision or defend one.
Step 1: Name the reader and the decision
Name the reader and the decision before you write a sentence. A document with no named reader drifts into background, and background is where weak samples spend their words.
Write two lines on a scratch page first. Line one: who reads this and what they know. Line two: what they must decide or believe after reading. For a take-home spec the reader is usually an engineer who can approve or reject the design. For the question about the most inventive thing you have done, the reader is a hiring panel deciding whether your judgment holds at scope.
Input: the prompt. Output: one sentence that starts "After reading this, the reader will ...". Every later section must support that sentence or be cut. Stack Overflow's guide to technical specs lists background items such as the reasons the problem is worth solving and past efforts that did not work; use them only as far as the reader needs them.
Step-by-step description
- Name who reads and what they decide.
- State the winner and the losers.
- Fit the window and label assumptions.
- Write narrative, set aside, edit.
- Name the reader and the decision before you write a sentence.
- A strong sample states what you chose and what you rejected.
- Size the scope to the window and state your assumptions.
- Write in narrative prose, then set it aside and edit again.
Step 2: Say what you chose and what you rejected
A strong sample states what you chose and what you rejected. This is the line that separates levels, because anyone can describe what they built, while a principal candidate shows the paths they closed and the cost of each.
Give each option one sentence on what it would have bought and one on what it would have cost. Then say why you picked yours for this reader and this constraint. If the prompt is about a judgment call made without complete analysis, say what you knew, what you did not know, and what would have changed your mind.
Add a short list of non-goals. A reviewer reads them as proof that you scoped on purpose. Input: your options. Output: a paragraph that names the winner, the losers and the price you accepted.
You now know the core of the document; the next step makes it fit the time you have.
Step 3: Size the scope to the window and state your assumptions
Size the scope to the window and state your assumptions. Amazon says a great memo might take a week or more and is written and re-written (Amazon, 2018), and a take-home gives you less time than that, so plan a smaller document, not a rushed large one.
Ask how long the window is and whether there is a page or word limit. Candidates report different limits and no official source lists them. Then pick the three decisions that matter most and drop the rest into a short non-goals list.
Where the prompt needs numbers, show a back-of-envelope estimate with every assumption labeled as an assumption. A reviewer can disagree with an assumption; they cannot trust a number with none. The next section works one through.
A worked Fast.com sizing
Candidates report a take-home that asks for Fast.com, an internet speed test page, to be implemented from scratch with a detailed tech spec. The sizing section of such a spec follows from assumptions you state. The values below are illustrative assumptions, not measurements of any real service.1
| Quantity | Value (illustrative) |
|---|---|
| Tests per day (assumption) | 10,000,000 |
| Test duration (assumption) | 10 seconds |
| Download speed per test (assumption) | 100 megabits per second |
| Peak-to-average ratio (assumption) | 3 times |
| Data moved per test | 125 megabytes |
| Daily data moved | 1,250 terabytes |
| Average tests started per second | 115.74 |
| Peak tests started per second | 347.22 |
| Concurrent tests at peak | 3,472 |
| Egress at average load | 115.74 gigabits per second |
| Egress at peak load | 347.22 gigabits per second |
| Servers at peak, ten gigabits per second links used to 70% (assumption) | 50 |
| Servers at average load, same assumption | 17 |
The method is three steps. Concurrent tests equal tests started per second times test duration. Egress, the data leaving your servers per second, equals concurrent tests times speed per test. Servers equal egress divided by what one server can usefully carry. Peak egress is 347.22 gigabits per second against 115.74 at average load. Peak load, not average load, sets the number of servers. With peak-to-average ratios of 1, 2, 3, 4 and 5 the illustrative fleet is 17, 34, 50, 67 and 83 servers.1
Text description of the diagram
- With peak-to-average ratios of 1, 2, 3, 4 and 5 the illustrative fleet is 17, 34, 50, 67 and 83 servers.
- Peak load, not average load, sets the number of servers.
The method, architecture and goals of the spec
A Fast.com-style spec states its measurement method before its sizing. A common design for a browser speed test is to download several files in parallel from test servers near the user, discard the first seconds while the connection ramps up, and report the average speed over the rest. Present this as a design you can defend, not as a description of how any real service works.
The architecture follows from it: a small web page with a script on the client, a service that picks nearby test servers, and test servers placed close to users, for example on a content delivery network (CDN), a network of servers spread across many locations. The goal is one download speed that is stable between runs. State whether upload speed and latency are goals or non-goals. Name the failure modes too: a congested or distant server under-reports the user's speed, so say how the client switches servers or flags a doubtful result.
Step 4: Write it as narrative, then cut and revise
Write in narrative prose, then set it aside and edit again. Amazon says it does not use slide presentations and writes narratively structured six-page memos instead, and says its great memos are written and re-written, shared, set aside for a couple of days and edited again with a fresh mind (Amazon, 2018). A take-home gives you less time, so keep the order and shorten the pause: draft, step away, cut.
Prose forces you to connect each claim to the next with "because" and "so". Bullets let you skip that work. The news network Consumer News and Business Channel (CNBC) quotes a 2004 Bezos email saying that a good four-page memo is harder than a 20-page slide deck because narrative structure forces better thought.
On the final pass, delete background the reader already knows, read the first paragraph alone, and check that it states the decision. Use a table or a diagram only where it carries a number or a structure that a sentence cannot.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →The Staff-level answer
What is the most inventive or innovative thing you've done? Answer it in writing, as a short whitepaper.
Here is how I would open the paper: the decision, not the backstory. The problem was [problem] and the constraint was [constraint]. I considered three options, [A], [B] and [C]. I chose [B] because [reason], and I rejected [A] because of its cost to [cost]. The result was [a measured result from my own work], and the one thing I would change is [lesson]. The paper then states what I left out of scope and why, because those limits show judgment and keep a short document honest. A reader who stops after the first paragraph still knows what I did.
What makes it Staff-level: it leads with the decision, names the options it rejected, uses a real result from your own work and states its own limits. Fill the brackets with true facts only; an invented project fails the first follow-up question.
The rubric
Amazon says the difference between a great memo and an average one is much squishier than a checklist. The table is a self-check built from the steps above, not any company's rubric.
| Dimension | Weak answer | Strong answer | Staff answer |
|---|---|---|---|
| Decision | Describes what happened | States one decision up front | States the decision and what would reverse it |
| Trade-offs | Lists benefits only | Names one cost of the choice | Names the options rejected and the price of each |
| Scope | Tries to cover everything | Lists what is out of scope | Scopes to the window and says why |
| Evidence | Claims without numbers | Gives one real result | Labels assumptions and shows the arithmetic |
| Communication | Bullets and background | Clear prose in a sensible order | First paragraph stands alone; every sentence earns its place |
Three variants of this question
What is the most inventive or innovative thing you've done?
Candidates report this as a pre-loop writing prompt for principal-level roles at a large tech company, sometimes alongside a prompt about making a judgment call without complete analysis. Use the Step 2 structure: the problem, the options you rejected, the decision and a real result.
Implement Fast.com from scratch with a detailed tech spec
Write the spec as a reviewer would read it: goals and non-goals, the test method, the architecture, the sizing arithmetic above with labeled assumptions, and the failure modes, as laid out in the method and architecture section above. Candidates report this across companies; no company has published it.
Write two pages on revenue, tech debt, hiring and architecture
Candidates report a two-page written take-home of this shape for engineering-manager roles at a fintech company. With two pages and four topics, spend a short paragraph on each: one decision, one trade-off and one result per topic, with the non-goals stated.
Common mistakes
- "I wrote it in an evening, so I covered everything." (wrong) Breadth without decisions reads as a list. (right) "I chose three decisions that fit the window and listed the rest as non-goals."
- "I used slides and bullets to keep it tidy." (wrong) Amazon explicitly avoids slide-style presentations in favor of narrative text. (right) "I wrote connected paragraphs, with a table only where a number needed one."
- "The spec is a list of requirements." (wrong) A spec is a plan to solve a problem, with alternatives and trade-offs. (right) "The spec explains the design, the options rejected and the cost of each."
- "My numbers are facts." (wrong) Sizing numbers come from assumptions you made. (right) "I labeled every input as an assumption and showed the arithmetic."
- "Polish matters most." (wrong) Clean prose cannot rescue a missing decision. (right) "I put the decision in the first paragraph and cut everything that did not support it."
Follow-up questions
How long should a writing sample be?
Ask for the limit and follow it. Amazon's own format is six pages (Amazon, 2018), but candidate reports of take-home limits vary and no official source states them. Shorter and decisive beats longer and complete.
What belongs in a tech spec?
Context, goals and non-goals, the proposed design, alternatives considered, trade-offs and how you will judge success. Stack Overflow's guide also lists further considerations and open questions for the reviewers.
Should a writing sample use bullets or prose?
Use prose for reasoning and a table only for numbers or comparisons. Prose makes you connect each claim to the next, which is the skill the reader is checking.
What if the take-home asks for a presentation instead?
Keep the same spine: the decision, the options rejected, a result and the lessons. Candidates report a presentation on a major initiative, what worked and what did not, in some AI-lab manager loops; see how one AI lab's interview process is laid out. The written structure transfers directly to slides.
How do manager loops use writing alongside live rounds?
Written work is one input next to live rounds, and a live round can probe it: expect to defend the options you rejected and the assumptions you stated, so write nothing you cannot explain out loud. Read the Meta engineering manager interview to see how the live parts of a manager loop run, and the broader interview skills page for the communication side.
- A writing sample is evidence of judgment: lead with the decision, not the backstory.
- Show what you rejected and what each rejected option would have cost.
- Fit the scope to the window and list non-goals instead of rushing breadth.
- Label every number in a sizing section as an assumption and show the arithmetic.
- Write connected prose, set it aside, and edit it again before you submit.
Sources
- 2017 Letter to Shareholders (six-page narratives) — Amazon, 18 Apr 2018
- Why Jeff Bezos makes Amazon execs read 6-page memos at the start of each meeting — CNBC, 23 Apr 2018
- A practical guide to writing technical specs — Stack Overflow Blog, 6 Apr 2020
- Amazon Principal Engineer interview questions (candidate reports) — Glassdoor (accessed 2026-10-26), 26 Oct 2026
- Amazon Principal Software Engineer interview questions (candidate reports) — Glassdoor (accessed 2026-10-26), 26 Oct 2026
