How to Handle a Problem You've Never Seen Before in a Live Interview

TL;DR

• Unknown problems are tests of process, not memory.
• Use the Unknown Problem Framework: pause briefly, restate the problem, ask clarifying questions, brainstorm approaches starting from brute force, propose your direction, code carefully while narrating, test with examples, discuss complexity, then optimize.
• Communication and structured uncertainty matter more than landing the optimal solution.
• Most strong candidates do not solve novel problems perfectly either.

Introduction

This is the scenario every candidate fears: the interviewer presents a problem, and your mind goes blank. You've never seen this pattern before. There's no clear LeetCode problem that matches it.

This happens to about 50% of strong candidates. It's not a sign you're not smart. It's a sign the interviewer is testing how you think, not what you've memorized.

Here's the good news: there's a systematic approach to unknown problems that works remarkably well.

The Reality Check

First, accept this truth: you might not solve the unknown problem perfectly. That's okay. Interviewers don't expect perfection on novel problems. They evaluate:

1. How you approach the unknown (more important than the solution)
2. How you think systematically (can you decompose the problem?)
3. How you handle pressure (do you panic or stay logical?)
4. Your communication (can you think out loud clearly?)

A partially correct solution with excellent communication beats a correct solution with no communication.

The Unknown Problem Framework (UPF)

When you encounter a problem you don't recognize, follow this framework:

Step 1: Pause and Breathe (10 seconds)

Don't panic. Don't jump into solving. Take a moment.

"Okay, this is a new problem for me. Let me think through it systematically."

This buys you time and signals composure.

Step 2: Restate the Problem in Your Own Words (60 seconds)

Make sure you understand what's being asked:

"So if I understand correctly, I need to find [X] given [constraints], and return [output]. Is that right?"

This:

• Confirms understanding
• Buys thinking time
• Shows communication
• Catches misunderstandings early

Step 3: Ask Clarifying Questions (60-90 seconds)

Don't assume. Ask about:

• Edge cases (empty input, single element, null values?)
• Constraints (size limits, value ranges, time/space requirements?)
• Output format (return indices or values? Single answer or all answers?)
• Assumptions (is input always valid? Can I modify the input?)

Example questions:

"Are the values always positive or can they be negative? Does the input always have a solution or could there be no valid answer? Can I use extra space or do I need to optimize for space?"

Step 4: Think Out Loud About Approaches (3-5 minutes)

Don't jump to the optimal solution. Start with brute force:

"The simplest approach: [brute force]. This would be O(n²) time and O(1) space. Not great.

Better: [optimized approach]. This would use [data structure] to [achieve goal] in O(n) time and O(n) space."

Articulate multiple approaches, even if you only implement one. This shows:

• You can think of multiple solutions
• You understand trade-offs
• You're not just pattern-matching

Step 5: Propose Your Approach (60 seconds)

Get confirmation before coding:

"I think the best approach is [X] because [reasons]. This gives us [time/space complexity]. Does this sound reasonable?"

This is critical. If your approach is wrong, the interviewer can redirect you before you code 20 minutes down a dead end.

Step 6: Code Carefully (8-15 minutes)

Write clean code while narrating:

"I'm going to declare [variable] to [purpose]. Now I'm iterating through [collection]..."

Don't worry about being slow. Being correct and clear is better than fast and buggy.

Step 7: Test With Examples (3-5 minutes)

Trace through your code with examples:

"Let me test this with the example. Input is [X]. First iteration: [trace]. Second iteration: [trace]. Final result: [expected output]. Correct!"

Try an edge case:

"Edge case: what if input is empty? The function returns [result]. Good."

Step 8: Discuss Complexity and Trade-offs (2-3 minutes)

"The time complexity is O(n) because we iterate once. Space complexity is O(n) for the hash map. This is optimal for this problem because we need to examine each element."

Step 9: Optimize If Time Allows (2-5 minutes)

Only if you have time:

"One optimization: if space was a hard constraint, we could [alternative approach] in O(n log n) time and O(1) space. But the hash map approach is better for time complexity."

Real Example: An Unknown Problem

Let's walk through a real scenario:

Interviewer: "Given a list of meeting times, determine if a person can attend all meetings."

What you're thinking: "I don't remember this pattern..."

What you should do:

Step 1: Pause (10 sec)

"Okay, let me think about this."

Step 2: Restate (60 sec)

"So I have a list of meetings, each with a start and end time. I need to determine if one person can attend all of them. I assume a person can't attend overlapping meetings. Is that right? Good."

Step 3: Clarify (90 sec)

"A few clarifications: If one meeting ends at 10 and another starts at 10, can they attend both? [Interviewer: No, they overlap.] Got it. Can the input be empty? [Yes.] What if there are duplicate meetings? [Possible.] Should I return true/false or can I modify the input?"

Step 4: Brainstorm (3-5 min)

"The brute force approach: check every pair of meetings to see if they overlap. That's O(n²).

Better approach: Sort the meetings by start time. Then iterate through the sorted list and check if each meeting starts before the previous meeting ends. If they do, there's overlap. This is O(n log n) for sorting, O(n) for checking. Much better.

I think the sorting approach is the way to go."

Step 5: Confirm (60 sec)

"So I'll sort by start time, then iterate and check for overlaps. This should be O(n log n) time and O(1) space (if we can sort in place). Does that sound good?"

Step 6: Code (8-15 min)

def can_attend_all_meetings(meetings):
    if not meetings:
        return True

    # Sort by start time
    meetings.sort(key=lambda x: x[0])

    # Check for overlaps
    for i in range(1, len(meetings)):
        # If current meeting starts before previous ends, overlap
        if meetings[i][0] < meetings[i-1][1]:
            return False

    return True

While coding:

"I'm sorting by start time. Then I'm iterating from the second meeting onward. If the current meeting starts before the previous one ends, there's an overlap, so I return False. If I get through the whole list, return True."

Step 7: Test (3-5 min)

"Let me test with an example: [[0, 30], [5, 10], [15, 20]]. After sorting: [[0, 30], [5, 10], [15, 20]]. Wait, that's not sorted by start time. Let me retrace. [0, 30] starts at 0. [5, 10] starts at 5. So sorted: [[0, 30], [5, 10], [15, 20]].

Check overlaps: Does 5 < 30? Yes. So return False. Correct—the person can't attend all meetings because [0, 30] and [5, 10] overlap."

Step 8: Discuss Complexity (2-3 min)

"Time complexity is O(n log n) for sorting. Space complexity is O(1) if we sort in place. This is optimal because we need to sort to check for overlaps efficiently."

This candidate handled an unknown problem by:

1. Pausing and thinking systematically
2. Asking clarifying questions
3. Proposing an approach
4. Coding cleanly
5. Testing thoroughly
6. Discussing complexity

Perfect approach.

Key Principles for Unknown Problems

Principle 1: Start with Brute Force

Don't try to jump to the optimal solution. Starting with a clear brute force approach shows:

• You understand the problem fundamentally
• You can think of an approach even if not the best
• You understand trade-offs

Principle 2: Communicate Constantly

The more you explain, the less pressure you feel. And the better the interviewer understands your thinking.

Principle 3: Don't Guess

If you're unsure about something:

"I'm not sure about [X]. Let me think about this... Actually, I think [Y] makes sense because..."

Or ask directly:

"Is [assumption] correct?"

Principle 4: Focus on Logic, Not Language

The programming language matters less than the logic. If you're struggling with syntax:

"I want to check if an element is in the list. In Python, that's if x in list. Let me do that..."

Principle 5: Treat Edge Cases Early

Don't solve the happy path and add edge cases later. Handle them as you code:

def solve(input):
    # Handle edge case upfront
    if not input:
        return None

    # Then handle main logic
    ...

What NOT to Do on Unknown Problems

Don't panic

Don't say "Oh no, I don't know this" or "This is hard." Stay calm.

Don't jump into coding immediately

Take time to think. The first 5 minutes are for understanding, not coding.

Don't assume you know the approach

Verify with the interviewer: "Does this approach sound right?"

Don't go silent

Always be narrating your thinking. Silence = confusion (in the interviewer's mind).

Don't give up

If your first approach doesn't work, try another. Iterating is fine.

Don't over-optimize prematurely

Get it working first. Optimize later if time allows.

Advanced Techniques for Unknown Problems

Technique 1: Pattern Recognition

Even unknown problems usually fit a pattern. Ask yourself:

• Is this a sorting problem? (Is the order important?)
• Is this a search problem? (Am I looking for something?)
• Is this a graph problem? (Are there relationships between items?)
• Is this a string manipulation problem? (Am I working with text?)
• Is this a math problem? (Are there patterns or formulas?)

Technique 2: Reduce the Problem

If the problem seems complex, reduce it:

"What if there were just two items instead of a list? How would I solve it? Okay, now what if there were three? Can I extend the pattern?"

Technique 3: Use Concrete Examples

Work through examples to discover patterns:

"Let me try a few examples and see if I can find a pattern..."

Technique 4: State Assumptions Explicitly

"I'm assuming [X]. If that's wrong, the approach might change. Is that correct?"

Practice for Unknown Problems

The best practice for unknown problems is mock interviews. You can't fully prepare without facing novel problems.

But here's what you can do:

1. Solve problems you haven't seen (don't rely on solutions you've memorized)
2. Record yourself and review how you approach problems
3. Force yourself to articulate approaches before coding
4. Practice thinking out loud on paper problems (not just coding)
5. Do timed practice under pressure

The Real Edge on Unknown Problems

Here's a secret: candidates who get offers on unknown problems aren't necessarily smarter. They're more systematic and communicate better.

By following the framework:

1. Understand the problem
2. Propose an approach
3. Code carefully
4. Test thoroughly

You'll handle unknown problems better than 80% of candidates.

Getting Feedback on Your Approach

The challenge with unknown problems is that you don't know if your approach is right until you hear feedback. Most candidates practice alone, so they don't get feedback on whether their approach is optimal or even correct.

PhantomCodeAI (phantomcodeai.com) listens to your problem-solving approach via audio and provides real-time feedback. When you're stuck on an unknown problem, the AI can guide you toward better thinking—helping you discover if your approach is on track, or redirecting you if you're heading toward a dead end.

Final Thoughts

Unknown problems are where the real interview happens. Candidates memorize solutions for known problems, but you can't memorize something you've never seen.

What you can control:

• How you think systematically
• How you communicate your approach
• How you handle pressure
• How you test your solution

Master these, and unknown problems become your competitive advantage—not your weakness.

Master unknown problems with real-time guidance from PhantomCodeAI (phantomcodeai.com). Get feedback on your problem-solving approach as you think through novel problems. Available for Mac and Windows, starting at ₹1,599.

Frequently asked questions

Pause for 10 seconds, restate the problem in your own words, ask 2-3 clarifying questions, then brainstorm out loud starting from a brute-force solution. Most strong candidates also do not recognize their problem; the differentiator is structured exploration, not pattern matching from memory.

Yes, and it is often expected. Stating a brute-force approach with its complexity, then explicitly trading up to a better one, signals algorithmic maturity. Skipping straight to an optimal solution can look memorized; deriving it shows real reasoning.

Aim for 5-8 minutes of clarification, brainstorming, and approach articulation before typing. Coding too early on a hard problem is the most common reason candidates blow past their time budget. The interviewer expects this thinking phase.

Pause, narrate what you noticed, and explain why the approach breaks. Then propose a fix or a different approach. Recovering visibly is a positive signal; silently scrapping code or pretending the issue is not there is a negative one.

Have a default script: 'Let me restate the problem, list constraints, try a few small examples, and start from a brute force.' Practicing this script on novel problems trains your brain to fall back on process rather than emotion when something looks unfamiliar.