Describe a time when you had to get a project or initiative completed with limited resources.
Asked at:
Amazon
Anthropic
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 the ideal plan is not available: not enough time, people, budget, tooling, or authority. They want evidence that you can prioritize, adapt, and still deliver meaningful outcomes rather than simply describing constraints. At higher levels, they also want to see whether you changed the shape of the work itself to fit the reality of the resources.
“Tell me about a time you had to deliver something important without the people, time, or budget you wanted.”
“Describe a situation where you had to make real progress even though resources were tight.”
“What's an example of a project where the original plan didn't match the capacity available? How did you handle it?”
“Have you ever had to scale back an initiative because you couldn't get all the support you needed? What did you do?”
“Walk me through a time when you had to do more with less and still get to a meaningful outcome.”
Key Insights
- You should name the constraint clearly and early. 'Limited resources' is not automatically impressive; what matters is whether you recognized the real bottleneck and adjusted the plan intelligently.
- Don't make this a story about heroics or overwork. Strong answers usually show tradeoff judgment, focus, and reuse of available leverage, not just working nights to brute-force the problem through.
- You should explain what success looked like under the constraint. Interviewers listen for whether you delivered the most important outcome possible, not whether you stubbornly tried to preserve the original plan.
What interviewers probe atlevel
Top Priority
You do not need to own the whole project at junior level, but you should sound like someone who helped move the work forward instead of passively waiting for direction.
Good examples
🟢I flagged the risk early, suggested a simpler implementation for my part, and took on the follow-through to get that version ready.
🟢Even though I wasn't leading the project, I gathered the missing details, confirmed what could be cut, and made sure my piece landed in time for the release.
Bad examples
🔴The project was under-resourced, so I just finished the ticket I was given and left the rest for the team to sort out.
🔴I told my lead we probably couldn't finish on time, and after that I mostly waited to hear what the new plan was.
Weak answers stop at awareness; strong answers show personal initiative and follow-through within an appropriate junior scope.
For junior candidates, the key is demonstrating that you understood some work was more important than other work and acted accordingly.
Good examples
🟢I asked which user scenarios were most important and made sure those were reliable before spending time on lower-priority polish.
🟢When we had to choose, I kept the validation that protected data quality and deferred a convenience feature that users could live without temporarily.
Bad examples
🔴To save time, I cut the documentation and some edge-case handling without checking whether those were important.
🔴I focused on the parts I already knew well because that was the fastest way for me to make progress.
Weak answers make convenience-based cuts; strong answers make importance-based cuts tied to user or project value.
Valuable
Interviewers want to see that you stayed resourceful under pressure, tried reasonable alternatives, and didn't freeze when the initial path stopped working.
Good examples
🟢When my first approach took too long, I asked for quick feedback, simplified it, and got a working version in place.
🟢After realizing the environment limitations would keep delaying me, I switched to a smaller test setup so I could still validate the core behavior.
Bad examples
🔴When the original approach seemed too slow, I mostly waited for my lead to suggest a different way to do it.
🔴After hitting blockers from the resource constraints, I kept retrying the same implementation because I didn't want to change direction late.
Weak answers show passivity or stubbornness; strong answers show flexible persistence and sensible course correction.
You don't need giant business metrics at junior level, but you should be able to say what happened and why the result was good enough for the situation.
Good examples
🟢We shipped the reduced version on time, and it covered the main workflow our team had prioritized, with only one deferred edge case left documented for later.
🟢The simpler approach let us complete the release, and after launch we saw the support requests on that issue drop noticeably.
Bad examples
🔴We got it out by the deadline, so I consider it a success, although I'm not sure how much it was used.
🔴I finished my part and nobody complained, which meant the limited-resources approach worked.
Weak answers define success as activity completed; strong answers define success as a real outcome achieved under the constraint.
Example answers atlevel
Great answers
In my internship, I was helping add an export feature to an internal dashboard, and about a week before the deadline we learned the engineer mentoring me had to switch to a production issue, so I had much less support than expected. I listed the pieces that were actually required for the first release and checked with my lead which ones mattered most to users. Instead of building every export option we had talked about, I focused on the CSV path, basic validation, and a clear error message, and I used a smaller test data set so I could verify the flow without waiting on a full environment setup. I sent short updates each day so there were no surprises and asked targeted questions when I got stuck rather than waiting. We shipped the limited version on time, and it covered the main workflow the operations team needed. The other formats were added later, but the urgent need was solved with the time and support we had.
At a small non-profit where I’m the only developer, I was asked to build an online registration page for a community workshop with just two weeks and no budget for a designer or paid tools. I mapped out the absolute must-have fields with the program manager, picked a clean open-source template, and integrated a free payment provider’s basic form instead of trying to customize a full checkout flow. To keep it accessible, I made the page mobile-first and reduced the questions to essentials so staff could easily process signups by hand if needed. I enlisted a couple of volunteers to run quick usability checks on different phones and iterated based on their feedback. I also wrote a one-page guide so non-technical staff could edit copy and export attendee lists. The page launched on time, the workshop filled to capacity, and staff appreciated having something low-maintenance they could keep using for future events.
Poor answers
In school I worked on a team app project where we didn't have enough time near the end, so I took on most of the coding myself to make sure we finished. I skipped some of the cleaner structure we originally wanted and just focused on getting all the screens built. We did get the demo done on time, and the professor was happy that everything was there. For me that showed I can handle limited resources by stepping up and doing whatever it takes.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Early June, 2025
Amazon
Senior
Mid April, 2025
Anthropic
Staff
Late December, 2024
Amazon
Mid-level
Hello Interview Premium
Your account is free and you can post anonymously if you choose.