Tell me about a time when you didn't have enough resources to do something you felt was important but found a creative way to get it done anyway.
Asked at:
Amazon
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
This question tests whether you can make progress when the obvious path is blocked by limits like time, headcount, budget, tools, or authority. Interviewers want to see resourcefulness, but not recklessness: can you identify what really matters, find a practical workaround, and still manage risk responsibly? At higher levels, they also want to see whether you can reshape scope, align others, and create leverage rather than just working harder yourself.
“Describe a time you had to deliver something important without the budget, people, or tools you really wanted.”
“Tell me about a situation where a lack of resources could have stopped a project, but you found another path forward.”
“Have you ever had to make meaningful progress on something critical with very limited support? What did you do?”
“What's an example of an important problem you solved by being resourceful rather than waiting for ideal conditions?”
“Can you walk me through a time when constraints forced you to get creative to achieve a goal?”
Key Insights
- You do not get extra credit for heroics alone. The strongest answers show that you first clarified what was truly important, then found a creative path that matched the constraint instead of just overextending yourself.
- Be explicit about the constraint and why it was real. If the story sounds like you simply bypassed process or grabbed help you were not entitled to, the answer can read as poor judgment rather than creativity.
- You should close the loop on outcome and tradeoffs. Interviewers listen for whether your workaround actually solved the important part of the problem and whether you understood what risks, quality limits, or follow-on work your approach created.
What interviewers probe atlevel
Top Priority
At junior level, ownership means you took concrete steps within your scope instead of stopping at 'we didn't have enough support.'
Good examples
🟢After realizing the team lacked bandwidth, I proposed a simpler approach, implemented the first version, and checked in with my mentor to make sure it was useful.
🟢I gathered the missing information myself, outlined two options for my lead, and then owned the smaller solution once we agreed on it.
Bad examples
🔴I told my lead we didn't have the tools we needed and then waited until someone found an alternative.
🔴I kept reminding the team that the task was important, but there wasn't much I could do without more resources.
Weak answers escalate the problem and stop; strong answers pair escalation with forward motion.
A good junior answer shows initiative, but also respect for quality, process, and the limits of what you can safely improvise.
Good examples
🟢We didn't have a full test setup, so I built a small local simulation and asked a teammate to review the assumptions before I relied on it.
🟢I couldn't get the reporting tool in time, so I pulled the needed data manually for a limited period and clearly marked it as a temporary process.
Bad examples
🔴We didn't have the right test environment, so I just skipped testing and deployed because we needed to move fast.
🔴I couldn't get access to the internal tool, so I used production data from a teammate's screen share to finish my task.
Weak answers mistake shortcut-taking for creativity; strong answers find bounded workarounds and manage the associated risk.
Valuable
Even at junior level, a strong answer ends with what you learned and how you avoided repeating the same scramble.
Good examples
🟢Afterward I wrote down the setup steps we had improvised so the next person wouldn't lose the same time.
🟢I shared what I learned with the team and added a simple check earlier in development so we could catch the issue before it became urgent.
Bad examples
🔴The workaround worked, so we moved on and I didn't think much more about it.
🔴I was glad I got it done, and I would probably use the same shortcut again if needed.
Weak answers treat the incident as isolated; strong answers turn a one-off save into better future practice.
Example answers atlevel
Great answers
On a recent feature, I noticed users were dropping off because our file upload error messages were confusing, but our team was focused on a bigger launch and didn't have much design time available. I still felt it was important because support tickets on that flow were increasing. Instead of proposing a full redesign, I reviewed the ticket patterns, mocked up a very small set of clearer messages, and asked a senior engineer and our designer for a quick review in one short meeting. I implemented only the highest-impact cases and added a simple checklist so we could test them locally without needing the full staging setup. The result was that support tickets on that issue dropped the next release, and we later used the same checklist for similar form changes. What I learned was that when resources are tight, a smaller fix tied to a real user pain point is much easier to get done than a broad improvement idea.
At my last startup we were hiring fast, but there was no dedicated onboarding plan and senior engineers didn’t have bandwidth to hand-hold every new joiner—so new hires were stuck for days and the team spent lots of time answering the same questions. I cared because the interruptions slowed product work and made the new engineers feel lost. With no budget or official time to build a program, I spent an evening recording five short screencasts, wrote a one-command setup script, and put a concise checklist in a repo README that walked someone from checkout to their first PR. I asked two recent hires to try it and incorporated their feedback; after that new engineers were able to run tests and open meaningful PRs in their first week rather than the second, and the number of “how do I set up?” messages dropped substantially. What I learned is that small, reusable automation plus focused documentation can substitute for a lot of dedicated training time and immediately reduce team friction.
Poor answers
At my last job I thought our internal dashboard looked outdated, but we didn't have design support for it. I felt it was still important, so I spent extra time after my assigned work and refreshed a lot of the screens myself. People said it looked nicer, and I was happy I didn't wait for approval because that would have slowed things down. It showed me that if something matters, it's usually better to just do it.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late December, 2024
Amazon
Mid-level
Hello Interview Premium
Your account is free and you can post anonymously if you choose.