Have you written any design docs?
The interviewer wanted to know if I handled any large-scale projects that required detailed planning ahead.
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers ask this to understand whether you use writing as a tool for engineering work, not just whether you have ever produced a document. They are probing for clarity of thought, ability to reason through tradeoffs before coding, and whether your scope matches your level. Strong answers show what kind of design decisions you were responsible for, how the doc improved the outcome, and how you adapted the document to its audience.
Key Insights
- You do not get much credit for merely saying a document existed. Explain what problem it was meant to solve, what decisions it clarified, and what happened because you wrote it.
- If you were not the primary author, say that plainly and then describe your actual contribution. Honest scope calibration is much stronger than implying ownership you did not really have.
- A good answer usually includes at least one meaningful tradeoff or uncertainty. If the story makes the design doc sound like obvious paperwork, you are leaving out the part that demonstrates engineering judgment.
What interviewers probe atlevel
Top Priority
Even at junior level, the best answers show the document affected what happened next, not just that it was written.
Good examples
🟢The review caught an edge case around duplicate processing before I coded it, so I updated the plan and avoided rework later.
🟢Writing the doc helped us simplify the change enough that I could implement it safely in one release instead of splitting it after problems showed up.
Bad examples
🔴After I wrote it, we moved ahead with implementation, so it served its purpose.
🔴The doc was approved and then I built the feature the way I had planned.
Weak answers stop at document completion; strong answers show the document improved the design, reduced risk, or saved work.
Valuable
Example answers atlevel
Great answers
Yes. On my current team I wrote a short design doc for a small change to an internal reporting job that I was implementing. I drafted the problem, my proposed approach, and a couple of open questions, especially around how to handle bad input and retries. In the review, my mentor pointed out that my first version could reprocess the same file twice, so I updated the design before I wrote the code. It was a small document, but it helped me think through the edge cases early and made implementation smoother.
Yes, but only for smaller pieces of work. At my last internship, I wrote a short design doc for adding a date filter to a customer support dashboard I was helping with. I wasn’t the final decision-maker, so I focused on laying out the user need, a couple of implementation options, and the tradeoffs in plain language so my manager and the backend engineer could weigh in quickly. They suggested changing how we handled time zones and adding a note in the UI to avoid confusion, which I hadn’t thought about at first. I liked writing the doc because it gave me a chance to learn how the team makes decisions, and it saved us from going straight into code with an unclear plan.
Poor answers
Yes, I've written design docs. Usually if I'm assigned a feature, I put the approach into our template and send it to my lead so they can approve it before I start coding. For my last one, the architecture was already pretty clear, so I mostly documented the classes, endpoints, and the steps I was going to take. After that I built it as written.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Early June, 2025
The interviewer wanted to know if I handled any large-scale projects that required detailed planning ahead.
Hello Interview Premium
Your account is free and you can post anonymously if you choose.