To answer “what is your greatest accomplishment?”, pick one recent, work-related result that you personally drove, that fits the level you're interviewing for, and that you can back with a number or a concrete outcome. Lead with the result in one sentence, explain why it was hard and why it mattered, spend most of the answer on what you did, and finish with the impact and why you're proud of it. Two minutes is plenty. The question isn't asking for your most impressive-sounding project; it's asking what you count as success and whether your part in it was real.
Below: what the question checks, how to choose the accomplishment, a result-first structure, how to size impact honestly, three example answers, mistakes and follow-ups. If the prompt is about difficulty rather than pride, see our guide to “describe a challenging project”, which focuses on obstacles and trade-offs.
What “what is your greatest accomplishment” is really checking
The story you choose says as much as the way you tell it. Interviewers are looking at:
- Your yardstick. What you call your greatest accomplishment shows what you value: user impact, quality, speed, helping others. Make sure it's something this team values too.
- Scope for your level. A new grad's best work and a staff engineer's best work look different. The story should show you already operate close to the level you're applying for.
- Ownership. Was it your result, or were you nearby when the team got it?
- Impact you can explain. Can you say what changed, for whom, and how you know?
- Humility. Pride is expected. Giving credit where it's due keeps it from tipping into bragging.
| Wording you might hear | What it emphasizes |
|---|---|
| “What is your greatest accomplishment?” | Your peak result, and your judgment in choosing it |
| “What are you most proud of?” | Your values: why you're proud matters as much as the result |
| “What's the biggest achievement in your previous projects?” | Scale and measurable impact |
| “What's the most impactful thing you've built?” | Technical depth plus outcome |
| “Tell me about a project you're proud of.” | Often the opener for a deep dive, so expect detailed follow-ups |
At Amazon, the question maps naturally onto two of the Leadership Principles: Deliver Results, which asks leaders to deliver the key inputs “with the right quality and in a timely fashion,” and Ownership, which opens with “Leaders are owners.” Our Amazon Leadership Principles examples show how to map a story to them.
How to choose the right accomplishment
List four or five candidates before you pick. Good raw material for engineers: a launch, a performance or cost win, a reliability fix, a migration, a developer-tooling improvement, someone you mentored, an open-source contribution or a hard bug. Then test each one:
| Test | What to check | Why it matters |
|---|---|---|
| Recent | Ideally from the last two or three years | Older wins invite “what have you done lately?” |
| Relevant | Uses skills this role needs | The answer doubles as evidence for the job |
| Yours | You can name decisions you made, not just tasks you did | Follow-ups will probe your part |
| Measurable | A number or a concrete before-and-after | Specific impact is easier to believe |
| Hard | Something real stood in the way | Easy wins don't show much |
| Meaningful to you | You can say why you're proud of it | That's the part interviewers remember |
What “big enough” means depends on your level:
- New grad or intern: an internship project, a capstone, an open-source pull request merged upstream, a hackathon build people actually used. Non-work accomplishments are fine if they show traits the job needs.
- Mid-level: a feature or service you owned end to end, a performance or reliability win, an incident you led to resolution.
- Senior and above: a result that crossed teams, a technical direction you set, or making a whole team more effective.
A result-first structure
Most behavioral answers build up to the result. This one works better when you lead with it: the interviewer asked for your best result, so give it to them in the first sentence, then earn it.
- Headline (one sentence). The result, plainly: “My greatest accomplishment was moving our payments service to a new database without downtime.”
- Stakes (two or three sentences). Why it was hard and why it mattered: the risk, the constraint, who depended on it.
- Your moves (most of the answer). Three or four decisions or actions that were yours. Use “I” for your actions and “we” for the team's.
- Impact. What changed, measured honestly.
- Why it matters to you (one sentence). The reason you're proud of it, which reveals your values.
Underneath, this is STAR with the result moved to the front. Our STAR examples cover the base format, and the free STAR story builder helps you draft yours.
Sizing the impact honestly
- Before and after: “Build time went from about 20 minutes to under 8.” Approximate is fine if you say so.
- Proxies when there's no dashboard: tickets closed, pages per week, hours saved per release, teams onboarded.
- Concrete outcomes when there's no number: “The team no longer needed a weekend release window.”
- Never round up. If a follow-up asks how you measured it, you need a real answer.
Three example answers
These are example answers we wrote for this guide, not real candidates' answers. The numbers are illustrative; use your own, and only ones you can explain.
Example 1: new grad, an internship tool the team kept using
Headline: “My greatest accomplishment so far is a test-data tool I built in my internship that the team kept using after I left.”
Stakes: “Engineers on my team built test accounts by hand for every feature, and mistakes in that data caused flaky tests. My project was scoped as an exploration, so nothing forced it to ship.”
Your moves: “I asked four engineers what they built by hand most often, wrote a small command-line tool that generated those setups from templates, and added it to the team's test helpers so it ran in CI. I wrote the docs and gave a ten-minute demo at a team meeting.”
Impact and why: “By the end of the summer most new tests on the team used it, and my mentor told me months later it was still in use. I'm proud of it because I found a real problem by asking people, not by guessing.”
Example 2: mid-level engineer, a reliability win
Headline: “My greatest accomplishment was cutting on-call pages for my team's order service by more than half in one quarter.”
Stakes: “The service paged several times a week, often at night, and two engineers had asked to leave the rotation. Feature work kept slipping because of the interruptions.”
Your moves: “I pulled three months of page history and grouped it by cause. Most pages came from a few noisy alerts and one retry bug. I fixed the bug, rewrote the alerts around user-facing error rates instead of raw CPU, and added a runbook link to every remaining alert. I reviewed each change with the team so nobody felt their alert had been quietly deleted.”
Impact and why: “Pages fell by more than half the next quarter, and both engineers stayed on the rotation. I'm proud of it because it improved the team's working lives, not just a graph.”
Example 3: senior engineer, a cross-team migration
Headline: “My greatest accomplishment was moving 30 services off a deprecated authentication library before it lost support, with no customer-facing incidents.”
Stakes: “Every team was busy, and a forced last-minute migration would have been risky.”
Your moves: “Instead of migrating services myself, I built a codemod that handled most of the change automatically, wrote a one-page migration guide, and migrated the three hardest services with their owners to flush out edge cases. A weekly status note let leadership see progress without chasing teams.”
Impact and why: “All 30 services moved ahead of the deadline, and most teams finished in an afternoon with the codemod. I'm proudest that other teams could do it themselves. That's the kind of leverage I want to keep building.”
Mistakes that weaken the answer
- Picking something too old. A senior engineer leading with a college project suggests nothing since has measured up.
- A team result with no “I”. If you can't name your decisions, the interviewer can't credit you.
- Numbers with no story. “Improved latency by 40%” invites “how?”, so answer that before they ask.
- Too much architecture. Give enough detail to show the difficulty, then move on; they'll ask for more.
- False modesty. “I don't really have one” reads as unprepared. Pick something and own it.
- Overclaiming. Taking credit for a group outcome is easy to expose with one follow-up.
Follow-up questions to expect
- “What was your specific role?” Name two or three decisions that were yours.
- “How did you measure that?” Say where the number came from: a dashboard, a log query, a before-and-after test.
- “What would you do differently?” Have one real improvement ready.
- “Who else contributed?” Credit people by role. It strengthens your story rather than diluting it.
- “Why this one over everything else?” Your reason reveals your values, so make sure they fit the team.
- “What do you want to accomplish next?” A bridge to your goals; our guide to “where do you see yourself in 5 years?” covers it.
How to prepare your answer
The hardest part is remembering what you did. Julia Evans' post on writing a brag document describes keeping a running list of your accomplishments so you and your manager remember them at review time; the same list makes this question easy.
- List five candidates from your brag document, performance reviews, design docs or commit history.
- Score them against the six tests above. Choose a main story and a backup from a different area, such as one technical win and one people win.
- Draft the five beats as bullets, not a script, so it doesn't sound memorized.
- Say it out loud in under two minutes and record it. Cut setup that drags.
- Practice the follow-ups with a friend, or run a free AI mock interview: CoPilot Interview's Mock Interview builds questions from your résumé and the job description, reads them aloud, and scores each spoken answer out of 10 with what to fix and a model answer.
A strong accomplishment also gives you evidence for “why should we hire you?”: same facts, different framing.
Rehearse your accomplishment story out loud
Paste your résumé and the job description, answer an AI interviewer out loud, and get a score out of 10 for each answer with what to fix and a model answer, then a report card. Free for 15 minutes every day, no credit card.
Try a free AI mock interviewFAQ
Can my greatest accomplishment be from outside work?
Yes, if you are early in your career or if it shows traits the job needs, such as finishing a hard project or leading people. Experienced engineers should usually choose a work result, because interviewers want evidence of how you perform in a job like this one.
What if my biggest accomplishment was a team effort?
That is normal in software. Describe the team's goal, then focus on the decisions and work that were yours, and credit others by role. Interviewers want to see what you contributed, not that you did everything alone.
How long should my greatest accomplishment answer be?
About 90 seconds to two minutes for the first telling. Lead with the result, keep the setup short, and let follow-up questions pull out the technical detail.
What if I don't have exact numbers?
Use honest approximations such as “roughly half”, proxies such as tickets, pages or hours saved, or a concrete outcome like a manual step that disappeared. Say how you know, and never round up.
Is this the same as “describe a challenging project”?
They overlap but differ in emphasis. The challenging-project question centers on obstacles and how you handled them; the accomplishment question centers on the result and why it matters to you. One project can serve both with different framing.
Should I pick my most impressive accomplishment or my most relevant one?
Usually the most relevant one that is still genuinely strong. A result that uses the skills this role needs does double duty, while an impressive story from an unrelated area leaves the interviewer guessing how it transfers.