What does it mean when you bomb a technical round?
It usually means one part of the round went badly enough that you left unsure of the result. You froze, ran out of time, wrote code that failed a test case, or went quiet for long stretches. One rough round rarely tells you everything, so the first job is to write down what happened while you still remember it.
Technical rounds are often short. Meta's technical screen page describes "a 45-minute conversation with an engineer" designed to assess your technical skills. A 2018 Google guide for technical internship interviews lists "2 x 45-minute Technical Interviews with a Google Engineer." In 45 minutes, a ten-minute freeze is a large share of the round, which is why it feels worse than it may have looked.
You may not get a verdict for days, and you may never get detailed feedback. The plan below works either way. It turns the round into a short list of fixes you can practice before the next loop, whether that loop is with the same company or another one.
What should you write down in the first hour?
Write the problem as you remember it, what you asked, what you tried first, and where you got stuck. Note the time you started coding, whether you tested, and any hint the interviewer gave you. Ten minutes of notes now is worth more than an hour of replaying the round in your head tonight.
Use plain questions so the notes stay factual:
- What was the exact problem, including the input and expected output?
- Which clarifying questions did I ask, and which did I skip?
- What was my first approach, and did I say it out loud?
- When did I start writing code, and how much time was left?
- Did I run through an example or an edge case before saying I was done?
- What did the interviewer say or hint, and did I use it?
The interview debrief template gives you a free layout for these notes. If you feel the round went badly in a way you can't name, the page on how to tell you lost the room helps you find the moment it turned. The evening after a bad interview covers the hours right after the call.
Which part of the round went wrong?
Sort the problem into one of five buckets: understanding the question, choosing an approach, writing the code, testing it, or talking through it. Each bucket has a different fix. It is easy to grind more practice problems when the real gap was in testing or explaining, so name the bucket first.
Employers say plainly that the process counts along with the answer. Google's guide tells candidates to "Explain your thought process and decision making throughout the interview" and says its engineers look at "how you approach problems and how you try to solve them" along with technical ability. Microsoft's interview tips page says it wants to see how you think as well as what you know.
Amazon's SDE II interview prep page is just as direct about the code itself. It says the most important thing an engineer does there is write code that scales and is well tested, and it calls these "the main evaluation criteria." It also says to "Expect to be asked to write syntactically correct code" with no pseudocode.
| What went wrong | What it looked like in the round | What to practice before the next loop |
|---|---|---|
| Misread the problem | You solved a different problem or missed a constraint | Restate the problem and ask two clarifying questions before any code |
| No approach | Long silence, then a guess | Say a brute force answer first, then improve it out loud |
| Code fell apart | Syntax errors, lost track of variables | Timed problems in a plain editor with no autocomplete |
| Skipped testing | Said "done" and the interviewer found a bug | Walk one normal case and one edge case through every solution |
| Went quiet | The interviewer could not follow you | Narrate each step while solving, even alone |
| Ran out of time | Half a solution at the 40 minute mark | A 45 minute timer with a hard stop at 35 minutes for coding |
How do you fix freezing and going quiet?
Practice talking while you solve, because silence is a habit you can change. Start every problem by restating it, then say your first idea even if it is slow. Google's guide says "You can start with a brute force solution" and then discuss how to make it faster or use less memory.
Microsoft's page gives the same order. It says to "start by asking clarifying questions and stating your assumptions," and then "Talk us through your approach." If you are stuck, say what you have ruled out and why. That gives the interviewer something to respond to, and a hint is more useful than a minute of silence.
Here is an example script you can adapt when you freeze mid-problem:
"Let me say where I am. The brute force version checks every pair, which is O(n squared). I think a hash map could get this to one pass, but I'm not sure how to handle duplicates yet. Can I talk through that case with a small example?"
Google's guide also says to "take interviewer tips seriously because they're trying to give you helpful hints." When a hint comes, repeat it back in your own words and use it. Ignoring a hint to follow your own plan is one of the easier habits to break with practice.
How do you fix code that broke or was never tested?
Practice in conditions close to the real round, then make testing a fixed last step. Google's guide says to practice writing code "on paper, a whiteboard, or code in an interview coding document" and to "test your own code." If the round used a plain shared document, practice there instead of in an editor that fixes errors for you.
Amazon's prep page suggests that if you are rusty without an IDE, "it's a good idea to dust off the cobwebs" and get comfortable coding in its LiveCode tool. It also says to "check for edge cases and validate that no bad input can slip through" and to test so your solution "passes all test cases." Then it says to "consider the runtime complexity" of the solution.
A simple testing routine you can say out loud at the end of every practice problem:
- Run one normal input through the code line by line.
- Run an empty or smallest input.
- Run an input with duplicates, negatives or the largest size you were given.
- State the time and space complexity in one sentence.
If you can't remember a library method, say so. Google's guide says that is acceptable "as long as you let the interviewer know" and suggest a substitute with a matching interface.
What should you study before the next loop?
Study what the company publishes for your role, then fill the gaps your notes showed. Google's 2018 guide lists topics such as Big-O analysis, sorting, hash tables, trees, graphs and recursion. It says hash tables are "arguably the single most important data structure" and that you should know their performance in your chosen language.
Read the prep page for each company before its loop, because each one publishes different detail. Meta points candidates to a downloadable technical screen guide and describes its full loop as several different conversations designed to assess technical skills. Amazon's page lists data structures and algorithms, problem solving, logical and maintainable code, and best practices.
Keep the study plan narrow. If your notes say you never tested, more graph problems won't help much. Pick the one bucket from the table that cost you the most, practice it for a week with a timer, and only then add new topics.
Technical loops often include a behavioral round too. Have a short answer ready for tell me about a time you failed, since a bad technical round can be an honest example later, once you have fixed what went wrong.
Should you follow up or ask for feedback?
Send a short thank you note if you would normally send one, and keep it about the role. Don't reopen the problem or send a corrected solution unless the interviewer asked for it. If you get a rejection, one polite request for feedback is fine, but you may not get an answer.
An example note you can copy after a rough round:
"Thanks for the time today. I enjoyed the problem on merging intervals and the discussion about tradeoffs. I'm still very interested in the role and look forward to hearing about next steps."
If the answer is no, the guide on asking for feedback after a rejection has scripts. Ask the recruiter when you can apply again, because waiting periods are set by each company and few publish them. If the topic comes up in a later interview, mentioning a past rejection shows how to keep it short.
How do you prepare for the next loop without repeating the same round?
Run at least two timed mock rounds that copy the real format: 45 minutes, a shared document, and someone watching. Have the person note where you went quiet and whether you tested. Then compare the notes with your first round to check the fix held under pressure.
If you have now had two or three rough technical rounds, look at them together. The page on patterns across interviews shows how to spot the same mistake showing up in different rooms. The guide to preparing for round two covers the gap between rounds, and the final round interview guide covers a full loop.
Saying your reasoning out loud is the part people practice least. Prept's Mock room lets you answer interview questions out loud on a clock and scores each answer out of 10, checked against your resume, and it is included in the free plan. Use it for the behavioral half of the loop, and use a timer and a friend for the coding half.