How to approach a coding interview problem you have never seen

In a live coding round, the interviewer is not only checking whether you reach the right answer. They are watching how you get there: how you understand the problem, how you handle uncertainty, and how clearly you explain your thinking. That is good news, because process is something you can practise. A consistent method helps most when you face a problem you have never seen before, which is exactly the situation that causes panic.

Step 1: understand the problem

Before you write anything, restate the problem in your own words and check it with the interviewer. Then ask clarifying questions:

• How large can the input be? This tells you whether a slow solution is acceptable.
• What types are the inputs? Can numbers be negative? Can strings contain spaces or special characters?
• What should happen with an empty input, duplicates, or no valid answer?
• What exactly should the output look like?

Interviewers often leave details out on purpose to see whether you ask. Clarifying questions are a strength, not a sign of weakness.

Step 2: work through examples by hand

Take the example given and trace it manually. Then create one or two of your own, including an edge case such as an empty array or a single element. Working examples by hand often reveals the pattern you need, and it gives you test cases to use later.

Step 3: start with a simple solution

Describe the most straightforward approach first, even if it is slow, and state its time complexity. For example: "The simplest approach is to check every pair of numbers, which is O(n²)." This shows you can solve the problem at all, gives you something to improve on, and gets the interviewer engaged in the conversation. Do not code it unless the interviewer asks you to; move on to improving it.

Step 4: optimise

Look for repeated or unnecessary work in your simple solution. Most interview problems are variations on a small set of patterns, so ask yourself which one fits:

• Hash maps and sets for fast lookups, counting and detecting duplicates.
• Two pointers for sorted arrays, pairs and reversing.
• Sliding window for the longest or shortest subarray or substring meeting a condition.
• Binary search for sorted data, or for searching over a range of possible answers.
• Breadth-first and depth-first search for trees, graphs and grids.
• Heaps for "top k" and scheduling problems.
• Prefix sums for repeated range-sum queries.
• Dynamic programming when a problem breaks into overlapping subproblems.

Take the classic "two sum" problem: find two numbers in an array that add up to a target. The simple approach checks every pair in O(n²) time. The better approach walks through the array once, and for each number checks whether its complement (target minus the number) is already in a hash map, giving O(n) time. Spotting that "have I seen this before?" can be answered by a hash map is the kind of step interviewers want to hear you reason through.

Step 5: write clean code

Once the interviewer agrees with your approach, write the code. Use meaningful variable names, break logic into small helper functions where it helps, and keep talking as you write: "Now I'm handling the case where the window shrinks." Handle the edge cases you identified earlier. Clean, readable code matters even under time pressure, because it shows how you would write code on the job.

Step 6: test your code

Do not announce that you are done the moment you stop typing. Trace through your code with the examples from step 2, line by line, tracking variable values. Then try the edge cases. If you find a bug, fix it calmly and explain the fix. Finding your own bugs is a positive signal; interviewers expect bugs in code written live.

Step 7: state the complexity

Finish by giving the time and space complexity of your solution and mentioning any trade-offs. For example: "This is O(n) time and O(n) space because of the hash map. If memory were tight, we could sort first and use two pointers for O(n log n) time and O(1) extra space."

When you get stuck

Everyone gets stuck sometimes. What matters is how you handle it:

• Keep talking. Explain what you have tried and why it does not work. Silence gives the interviewer nothing to assess and nothing to help with.
• Simplify. Solve a smaller version of the problem first, such as a sorted input or only positive numbers.
• Go through the pattern list. Ask yourself whether a hash map, two pointers or a different data structure could help.
• Accept hints gracefully. Interviewers often nudge candidates. Using a hint well is far better than ignoring it.

Thinking out loud, in practice

Here is what a good running commentary sounds like:

"My first idea is to compare every pair, but with up to a hundred thousand elements that's around ten billion comparisons, which is too slow. What I'm really asking for each number is whether its partner appeared earlier, so if I store numbers I've seen in a hash map, I can answer that in constant time. Let me walk through the example to check that works before I code it."

How to practise

• Practise by pattern, not at random. Solve several sliding-window problems in a row until the pattern feels natural, then move on.
• Time yourself. Most interview problems should be solvable in 20 to 40 minutes.
• Explain solutions out loud as if to an interviewer, even when practising alone.
• Revisit problems you failed a few days later and solve them from scratch.
• Do mock interviews with friends, taking turns as interviewer. Being the interviewer teaches you what good communication looks like.

LeetCode, HackerRank and GeeksforGeeks all have large problem sets organised by topic and difficulty. Two or three problems a day, solved properly and reviewed, beat ten rushed ones.

Mistakes to avoid

• Jumping straight into code before understanding the problem.
• Ignoring the input constraints, which tell you what complexity is acceptable.
• Optimising before you have any working approach.
• Declaring the solution finished without testing it.
• Memorising solutions instead of understanding them. Interviewers often change one detail to check.

For a structured schedule covering data structures, your core stack and mock interviews, follow our 30-day technical interview plan. To see which other questions come up for your role, read the software engineer or backend developer interview guides.