Tell me about an initiative where you had to build a new system, service, or component from scratch
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to see how you operate when there isn't an established path: how you size up an ambiguous need, make foundational decisions, and carry something from idea to usable reality. They are also checking whether the scope of the story matches your level, because "built from scratch" can mean a small internal tool at junior level or a new platform capability at staff or manager level. Strong answers show judgment, not just effort: why this needed to exist, how you approached unknowns, and what happened after launch.
Key Insights
- You do not need a greenfield story with zero dependencies. What matters is that you had to define the approach rather than simply follow an existing pattern.
- Do not spend the whole answer on the technology choices. Interviewers care more about how you framed the problem, reduced uncertainty, and made tradeoffs than about the exact stack.
- You should make clear what was unclear at the start and how you made it tractable. Many candidates accidentally tell a build story that sounds like straightforward execution rather than creating something new.
What interviewers probe atlevel
Top Priority
Own more than writing code: show that you cared whether the thing actually worked for users after you finished building it.
Good examples
🟢After release, I stayed engaged to verify the users could complete the workflow and fixed two small issues that showed up in the first week.
🟢I wrote a short handoff note, checked the logs after launch, and followed up with the teammate using the tool to confirm it really reduced the manual work.
Bad examples
🔴After my pull request merged, the main work was done and the rest of the team handled release details.
🔴I delivered the component and assumed if there were issues, someone using it would tell us.
Weak answers end ownership at code completion; strong answers extend ownership through adoption and validation.
Valuable
Example answers atlevel
Great answers
In my first year, I built a small internal tool to validate CSV uploads before they were imported into our test environment. The request started as 'make uploads less error-prone,' so I first sat with the engineer doing the imports and mapped the few checks that were causing the most rework. I built a simple web page that handled one file format, added clear error messages, and left room to extend the validation rules later instead of trying to support every possible case. When I found that real files had inconsistent headers, I created a few targeted test cases, got quick feedback from a teammate, and updated the parser before release. After launch, I watched the logs and checked back with the user a week later; the manual fixes dropped a lot, which told me the tool was actually helping rather than just existing.
In my second internship at a healthcare startup, I was asked to help build a simple appointment reminder service because the support team was manually sending texts and missing a lot of follow-ups. I worked with one engineer to figure out the basic flow, then I built the first version of the service to read upcoming appointments from our database and send reminders through a messaging provider. I kept the first release small on purpose: one reminder type, one clinic, and a clear status page so the support team could see what was sent and what failed. I ran into an issue where some patient phone numbers were stored in different formats, so I added a cleanup step and tested it with real examples from our data. After we launched, the support team told us they were spending much less time on reminders, and I felt proud that something I built from scratch was helping a team that worked directly with patients.
Poor answers
I built a new settings page from scratch for one of our internal tools. It was mostly straightforward, so I just started coding based on a rough ticket and added a lot of extra options in case people needed them later. There were a few issues with the backend API, but another engineer helped sort those out and then I finished the UI. Once my code merged, the project was basically complete and the team started using it.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Early July, 2026
Hello Interview Premium
Your account is free and you can post anonymously if you choose.