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.
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.
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, interviewers mainly want to see that you can distinguish the core goal from nice-to-haves when resources are tight.
Good examples
đ˘We didn't have enough time to polish every edge case before launch, so I focused on the top failure path that would have blocked users and documented the rest for later.
đ˘I wanted to rebuild the whole component, but once I looked at the bug reports I realized a smaller fix to the upload flow solved the urgent customer issue.
Bad examples
đ´We didn't have time to finish every cleanup task I wanted, so I stayed late and did all of them anyway because I felt they were important.
đ´Our team couldn't support my idea, but I pushed for it because I thought it would be cooler for users, even though it wasn't tied to the release goal.
Weak answers confuse personal preference or perfectionism with business need; strong answers show prioritization grounded in impact.
Valuable
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
Hello Interview Premium
Your account is free and you can post anonymously if you choose.