What is the best process for solving coding interview problems under time pressure?
Start by reading the problem in full and asking clarifying questions before writing any code. Identify the input and output types, constraints, and edge cases. Then discuss your approach aloud before implementing, starting with a brute force solution and optimizing from there. Writing code before you understand the problem is the most common reason candidates fail solvable problems.
The technical difficulty of a coding interview problem is only one dimension of the challenge. The other dimension — often underestimated — is the pressure. Performing algorithmic problem-solving in real time, under observation, with limited time, while explaining your thinking aloud requires a different preparation strategy than solving LeetCode problems alone at your desk. This guide provides a systematic approach to performing well under interview pressure.
The Psychology of Interview Pressure
Interview pressure affects performance through predictable mechanisms. Working memory — the cognitive resource used for active problem-solving — is impaired by anxiety. Candidates who are highly anxious make more errors, overlook edge cases they would normally catch, and struggle to communicate clearly even when they know the underlying concepts.
"The candidates who perform best under pressure are not the ones who are never nervous. They are the ones who have internalized a systematic process so thoroughly that the process itself runs on autopilot, freeing cognitive resources for the actual problem-solving." — Engineering Manager and interview trainer, technology company
Understanding this gives you an actionable strategy: develop a systematic interview process and practice it until it is automatic. The process itself should not require cognitive effort.
The Five-Phase Interview Problem-Solving Process
Phase 1: Understand the Problem (2-4 minutes)
Before writing a single line of code, invest time in fully understanding what is being asked.
Read the problem statement in full. Do not start solving while still reading. Finish reading, then start thinking.
Ask clarifying questions:
- What are the data types of inputs and outputs?
- What are the constraints? (Array size, value ranges, string lengths)
- Is the input always valid, or do I need to handle malformed input?
- Are there edge cases I should handle? (Empty array, single element, all identical elements, negative numbers)
- Is there a space or time complexity requirement?
Restate the problem in your own words. This confirms your understanding and signals to the interviewer that you are thinking carefully. "So if I understand correctly, I need to find the two numbers in this array that add to the target value, and return their indices. The array is not sorted and there's guaranteed to be exactly one solution — is that right?"
Phase 2: Generate Examples (1-2 minutes)
Work through one or two concrete examples by hand before thinking about code. This serves multiple purposes:
- Confirms you understood the problem correctly
- Reveals patterns that might suggest a solution approach
- Produces test cases you can use to verify your implementation
Interviewers provide examples for a reason — they often contain hints about the expected behavior in edge cases.
Phase 3: Plan Your Approach Before Coding (3-5 minutes)
Describe your approach at a high level before writing code. This is non-negotiable. The candidates who skip this phase and start coding immediately almost always fail.
Start with the brute force approach even if you know it is not optimal. "The brute force approach would be to check every pair, which is O(n²). I can do better by..." This demonstrates that you understand the problem domain and can reason about trade-offs.
Then describe your optimized approach. Identify the data structure you plan to use and explain why. Identify the key operation you are performing in each iteration. Estimate the complexity.
Get the interviewer's confirmation that you are on the right track before you start coding.
Example dialogue: "Before I start coding — my plan is to use a hash map to store each number and its index as I iterate. For each number, I'll check if its complement (target minus current) is already in the map. If yes, I have my answer. If no, I add the current number to the map and continue. This is O(n) time and O(n) space. Does that approach make sense to start with?"
Phase 4: Code the Solution (10-15 minutes)
Now write the code. During implementation:
Think out loud. Narrate what you are doing and why. This gives the interviewer insight into your reasoning and allows them to help you if you are going wrong.
Write clean, readable code. Use meaningful variable names. Add a comment for complex logic. You are not optimizing for brevity — you are optimizing for clarity.
Handle edge cases during implementation, not after. When you hit a moment where edge case handling matters, address it inline rather than leaving a TODO.
Pause when stuck. If you are stuck, pause and think through the problem from first principles. Interviewers are generally willing to give a hint if you are stuck and have demonstrated good thinking up to that point. Flailing code in random directions is worse than asking for a nudge.
Phase 5: Test and Optimize (3-5 minutes)
After writing the solution, do not immediately hand it over and say "I think this is correct." Test it yourself.
Trace through your example. Walk through the code step by step with a specific input and verify that you get the expected output.
Test edge cases:
- Empty input
- Single element
- All identical elements
- Maximum and minimum values
- Already sorted or reverse sorted (for sort-based solutions)
- Negative numbers (if applicable)
Then state complexity. "This solution is O(n) time and O(n) space. The space could be reduced to O(1) if we allowed sorting the input, but that would require returning values rather than indices, which the problem doesn't allow."
Managing Time Under Pressure
Time management is a critical skill in coding interviews. A common failure mode is spending too long in Phase 1-3 (understanding and planning) and running out of time in Phase 4. The opposite failure — coding too quickly without planning — is more common but equally damaging.
| Phase | Target Time | Warning Sign |
|---|---|---|
| Understand problem | 2-4 min | Still uncertain about requirements at 5 min |
| Generate examples | 1-2 min | Skipping this entirely |
| Plan approach | 3-5 min | Starting to code before stating approach |
| Code solution | 10-15 min | Code incomplete at 12 min mark |
| Test and optimize | 3-5 min | Declaring "done" without testing |
Total target: 20-30 minutes for a standard 45-minute interview, leaving time for follow-up discussion.
When You Are Stuck: A Decision Tree
| Situation | Action |
|---|---|
| Don't understand the problem | Ask the interviewer to repeat or restate it |
| Understand the problem but have no approach | Work through a concrete small example manually |
| Have a brute force but can't optimize | Describe the brute force, implement it, then ask if they want to see the optimal approach |
| Have the algorithm but stuck on implementation | Describe the algorithm in pseudocode and ask if you can start there |
| Totally stuck after 5+ minutes of effort | Ask for a hint — do it explicitly and gracefully |
| Bug you can't find | Print/trace every variable through a small example |
"I would rather give a hint to a candidate who has demonstrated strong thinking throughout the interview than watch them flounder in silence for five minutes. If you are stuck, say so and ask. It does not automatically hurt your evaluation." — Senior Software Engineer, FAANG interview panel
Communication Patterns That Signal Strong Performance
Narrating your thinking: "I'm considering whether to use a set or a map here — I'll need the indices later, so I should use a map."
Acknowledging trade-offs: "This uses extra space, but it takes the time complexity from n² to n."
Catching your own errors: "Wait, I need to check if i equals j here — I don't want to return the same index twice. Let me add that condition."
Self-testing: "Let me trace through this with the second example: target is 6, array is [3, 2, 4]. First iteration: 3 is not in the map, so I add 3 → index 0. Second iteration: complement of 2 is 4, not in map yet, add 2 → index 1. Third iteration: complement of 4 is 2, 2 is in map at index 1, so return [1, 2]. That matches the expected output."
Frequently Asked Questions
What should I do if I go completely blank at the start of a problem? Start with what you do know. Write down the input and output types. Write down an example. Ask a clarifying question even if you do not strictly need the answer — the act of forming a question gets your brain back into analytical mode. Begin with the brute force approach regardless of whether you think it is good enough. Starting is the most important step.
How much should I talk during a coding interview? You should be communicating almost continuously — not necessarily about the code itself, but about your thinking. Silent coding for extended periods leaves the interviewer with nothing to evaluate. If you have no thoughts to articulate, describe what you are doing mechanically: "I'm initializing the hash map here, then I'll start my iteration."
Should I ask about the time limit if the problem seems very hard? Yes, always understand the scope. Asking "Is this intended to be solved in 20 minutes or is this a longer problem?" is completely appropriate at the beginning. Some companies use very hard problems specifically to see how candidates handle problems they cannot fully solve.
References
- Gayle Laakmann McDowell. (2015). Cracking the Coding Interview (6th ed.). CareerCup.
- Aziz, A., Lee, T. H., & Prakash, A. (2018). Elements of Programming Interviews. CreateSpace.
- Mehta, A., & Sahni, S. (2004). Handbook of Data Structures and Applications. CRC Press.
- Beilock, S. L., & Carr, T. H. (2005). When high-powered people fail: Working memory and choking under pressure in math. Psychological Science, 16(2), 101-105.
- Ramirez, G., & Beilock, S. L. (2011). Writing about testing worries boosts exam performance in the classroom. Science, 331(6014), 211-213.