Describe your approach to solving new and unfamiliar problems, including any strategies or methodologies you use.
Asked at:
Microsoft
Try This Question Yourself
Practice with feedback and follow-up questions
What is this question about
Interviewers use this question to assess how you operate when there is no obvious playbook: how you reduce ambiguity, choose a path forward, and keep learning as new information appears. They are usually less interested in a specific methodology name than in whether your approach is structured, adaptable, and appropriate to your level. Strong answers show not just analysis, but ownership, judgment, and evidence that you can make progress without waiting for perfect clarity.
“How do you typically tackle problems where you don't have prior experience or a clear path forward?”
“Tell me about your process for getting traction on something that's new to you.”
“When you're dropped into an unfamiliar problem space, how do you figure out where to start?”
“What's your method for breaking down ambiguous technical or operational problems?”
“How do you make progress when the problem is unclear and there isn't an obvious playbook?”
Key Insights
- You do not need to sound like you always know the answer quickly. A strong answer often starts with how you frame the unknowns, decide what to learn first, and avoid thrashing.
- Don't stop at 'I researched and asked for help.' Explain how you decided what to try, how you validated assumptions, and how you knew you were making progress.
- At higher levels, unfamiliar problems should affect more than just your own task. Show how you created clarity for others, reduced repeated confusion, or set direction under uncertainty.
What interviewers probe atlevel
Top Priority
At the junior level, interviewers want to see that you can turn a confusing task into manageable steps instead of freezing or guessing wildly.
Good examples
🟢I start by clarifying what success looks like, then I break the problem into smaller questions and tackle the least clear part first.
🟢If the problem is new to me, I write down what I know, what I don't know, and one or two safe experiments that can narrow it down.
Bad examples
🔴When I hit something new, I usually just start coding different things until one works because that's the fastest way to learn.
🔴I prefer to wait until someone can explain the right approach, since unfamiliar problems usually mean I don't have enough context yet.
Weak answers treat uncertainty as a reason to either flail or stall; strong answers show a simple but repeatable way to create clarity and momentum.
You are not expected to know everything, but you are expected to show that you learn in a targeted way instead of randomly consuming information.
Good examples
🟢I look for the smallest example that proves I understand the core issue before I apply it to the full task.
🟢I ask focused questions after doing some initial digging, so I can confirm whether my understanding is right instead of starting from zero.
Bad examples
🔴I usually read a lot of documentation and tutorials until I feel comfortable, then I try implementing the whole thing.
🔴If I'm stuck on something unfamiliar, I keep trying different fixes from online examples until one of them solves it.
Weak answers confuse effort with learning; strong answers show fast feedback loops and targeted information gathering.
Valuable
For junior candidates, the goal is to show healthy independence: you try to make progress first, but you don't burn time hiding confusion.
Good examples
🟢I spend some time understanding the problem and trying one or two approaches, then I ask for help with specific questions if I'm still blocked.
🟢When I reach out, I share what I tried and what I learned, so the conversation is about refining my thinking rather than starting from scratch.
Bad examples
🔴I usually ask a teammate pretty quickly because it's more efficient to get the answer from someone who already knows.
🔴I prefer to solve new problems entirely on my own so I can prove I can handle them without relying on others.
Weak answers either over-depend on others or isolate too long; strong answers show judgment about when and how to involve people.
Example answers atlevel
Great answers
When I run into a problem that's new to me, I try to avoid jumping straight into a full solution. On a recent project, I had to add a background job and I hadn't worked with that kind of processing before. I first clarified what success meant with my mentor, then wrote down the parts I understood and the parts I didn't, and built a very small test version just to confirm the basic flow. After that, I read the relevant docs and asked a few specific questions about error handling instead of asking someone to explain everything. Once it was working, I tested it against the original requirements and added notes to our team page so I could reuse the same approach later.
I tackle unfamiliar problems by making the unknown concrete — first I reproduce the issue or write a tiny, runnable example so I can see what actually breaks. For example, when I had to add client-side offline caching at my startup (something I hadn’t done before) I mapped the essential user flows that needed to work offline, built a minimal prototype to observe failures, and used browser logs and a couple of unit tests to pinpoint wrong assumptions. I read one or two well-regarded articles and skimmed a few open-source implementations to pick sensible patterns rather than following a long tutorial. Once the prototype covered the critical flows, I turned it into a focused pull request with tests and a short demo for the team so we could get feedback and iterate quickly.
Poor answers
Usually with new problems I just get hands-on right away because that's how I learn best. In my last internship I had to work with a tool I hadn't seen before, so I tried different examples from the internet until something worked and then I adapted that to our code. If I get stuck for a while, I ask whoever is nearby because it's faster than spending too much time thinking about it. That approach has worked pretty well for me so far.
Question Timeline
See when this question was last asked and where, including any notes left by other candidates.
Late March, 2026
Mid-level
Late January, 2025
Microsoft
Senior
Hello Interview Premium
Your account is free and you can post anonymously if you choose.