I've been on both sides of the interview table. I've sweated through LeetCode at 11pm with a toddler finally asleep in the next room. I've also run interviews at big tech companies and watched smart engineers torpedo themselves, not because they couldn't code, but because they forgot how to think out loud.
This article is not about grinding 300 problems until your brain leaks. It's about what actually happens inside the interview room, and how to not blow it.
Let's walk through the anatomy of a coding interview, step by step.
Step 1: The Intro. Keep It 90 Seconds. Seriously.
Most interviews open with: "Tell me about yourself."
This is not a TED Talk. It is not an invitation to walk the interviewer through your entire LinkedIn profile starting from college.
You have a coding problem waiting. Every second you spend over-explaining your resume is a second you're not spending on code.
Have a 90-second version ready. Name. Current role. One or two sentences on what you've built. One line on what excites you technically. Done.
End it with: "Happy to expand or talk more about anything you'd like."
That's it. You've signaled confidence, given them an opening, and protected your time. Move on.
Step 2: Understand the Problem Before You Touch the Keyboard
The interviewer gives you a question. Your brain goes: "Oh, I've seen this before. Two pointers. Let's go."
Stop.
Do not code yet.
I cannot stress this enough. Jumping to code before you understand the problem is one of the most common, and most expensive, mistakes candidates make. Even if it looks familiar. Especially if it looks familiar. Problems that look like sliding window problems are sometimes graph problems in disguise. Problems that look like BFS are sometimes DP. You don't know yet.
Read the problem. Actually read it.
Now ask questions. Good ones.
- What are the valid inputs? Any guarantees on input size?
- What does "invalid" look like here? Do I handle it or can I assume clean input?
- What should I return if the array is empty? If it has one element?
- Is this case-sensitive? Sorted? What if there are duplicates?
These are not checklist questions. These are the same questions you'd ask a PM before you started a ticket. You're scoping the work.
And here's the thing most candidates miss: the interviewer's answers often contain clues about the expected approach. Listen carefully.
Step 3: On Comments, Write What Helps You, Not What Impresses Them
A lot of candidates waste five minutes writing comments like a screenplay:
// Step 1: Initialize a hashmap
// Step 2: Iterate over array
// Step 3: Check if complement exists
Nobody asked for the director's commentary.
Write a comment if it will genuinely help you stay on track or if the logic is genuinely non-obvious. Otherwise? Skip it. The interviewer doesn't award points for narrated pseudocode. They care about your approach, which you can demonstrate verbally, and your actual code.
Save the time. You'll need it.
Step 4: Start with Brute Force. Out Loud. On Purpose.
You know the optimal solution. Maybe. But start with brute force anyway.
Say it out loud: "The naive approach here would be O(n²), nested loops, compare everything. That works, but let's see if we can do better."
This does three things:
1. It proves you can solve the problem. Some interviewers on hard questions will stop you and say "let's just code the brute force." That's actually a win. You're not being asked to be perfect; you're being asked to be functional.
2. It shows your mental model. Walking through Big O complexity on the brute force, then saying "okay, where's the bottleneck?" is exactly how engineers think. You're not just typing, you're reasoning.
3. It creates space for the interviewer to help you. If you dive straight into optimization and get stuck, you're stuck. If you've already laid out the brute force, you've given the interviewer something to work with. They can nudge you without handing you the answer.
Now, when you shift to optimization, keep a mental catalog of your data structures and algorithms. What structure reduces lookup time? Where can you trade space for speed? Do I need sorting first? Is there overlapping subproblem structure here?
You don't need to recite every algorithm. You need to know why each one exists and when it shows up.
Step 5: It's Okay to Think. Actually Think.
You don't have to fill every second of silence with words.
Some candidates think silence means failure. So they talk constantly, stumbling through half-formed thoughts, confusing themselves and the interviewer. Don't do this.
It is completely legitimate to pause and say: "Give me just a moment to think through this."
Or: "I'm not totally sure yet, but I'm thinking along the lines of using a monotonic stack here, let me work through whether that holds."
That's not weakness. That's calibration. That's what engineering looks like.
Silence is better than noise. Own it.
Step 6: When You Code, Write Like You're Shipping
You've agreed on an approach. Now code.
And please, for the love of all that is maintainable:
Use real variable names.
i, j, temp, arr2, these are fine in a 2AM script you'll delete. In an interview, they make your code harder to follow, for you and for the interviewer.
leftPointer, maxFrequency, currentWindow, these take two more seconds to type and make your logic self-documenting.
Also know your language. Not surface-level know, actually know.
- Is this string mutable or immutable in your language?
- Are you passing this by reference or by value?
- What's the time complexity of that
.sort()call? - What happens when you modify a list while iterating over it?
These aren't trick questions. They're things you use every day at work. The interview is just the one moment where you have to be conscious about it.
Step 7: Before You Hit Run, Do a Dry Run
You're done. You're about to run the code.
Don't.
Not yet.
Take 60 seconds and trace through your code with a small, concrete example. Out loud. Step by step.
# Input: [2, 7, 11, 15], target = 9
# left=0 (2), right=3 (15) → sum=17 > 9 → right--
# left=0 (2), right=2 (11) → sum=13 > 9 → right--
# left=0 (2), right=1 (7) → sum=9 == 9 → return [0, 1] ✓
Two reasons this matters:
First, you catch bugs before they become bugs. Off-by-one errors, wrong base cases, a misplaced <= instead of <, dry runs catch all of these before the console does.
Second, some companies don't let you run the code. The interviewer is mentally executing your solution in their head. Do it with them. Make it easy. The interviewer who can follow your logic is the interviewer who gives you the benefit of the doubt.
Don't run too many examples. One happy path. One edge case. You're not writing test coverage here.
Step 8: When You're Stuck, This Is Not a Disaster
You're stuck. You've been staring at the same loop for three minutes. Your mind is blank.
First: don't panic. Panic is the fastest way to make a blank mind stay blank.
Talk to your interviewer. Genuinely. Not performatively.
"I'm a bit stuck, I can see that I need to track state across iterations but I'm not sure yet what structure makes sense here."
Interviewers are trained to give clues without handing out answers. Listen to those clues. Actually listen, don't just nod along pretending you understood when you absolutely did not.
Ask back: "So when you say 'think about what changes and what stays the same', are you pointing me toward something like a sliding window? I'm trying to think about how that would handle the case where..."
This is not defeat. This is collaboration. And it's a direct simulation of your actual job, the engineer who can take feedback, integrate it, and move forward is far more valuable than the one who goes dark for an hour and surfaces with the perfect solution.
Step 9: The Close, Be Human, Not a Robot
At the end: "Do you have any questions for me?"
Yes. Always yes.
This is a real person doing a real job at a company you want to work at. Ask them something genuine. What does the team look like? What's the hardest technical problem they've worked on recently? What does success look like in the first six months?
I'll write a dedicated piece on this, the "do you have questions" portion of an interview is underrated and deserves its own treatment.
And when the interview wraps:
"I genuinely enjoyed brainstorming and solving this with you. Thank you so much for your time."
Genuine. Brief. Warm.
Not: "Oh wow, that was such a great question, I learned so much from you today."
False flattery doesn't get you a return call. Your performance does.
The TL;DR (For Those of Us Who Are Sleep-Deprived)
The coding interview isn't a memory test or a performance. It's a compressed simulation of what you're like when a system is on fire at 2am and you have to think clearly, communicate under pressure, and ship something that works.
The interview is a skill. And like any skill, it compounds with practice. Start building it now.
Oshin is a Senior Software Engineer with 8 years of experience at Salesforce, Microsoft, and Amazon, and a Hackernoon Life-Hacking Top 5 writer. She mentors engineers from non-traditional backgrounds breaking into big tech. Read more from Oshin on HackerNoon.
