Practising Well: Mock Interviews, Feedback Loops and Nerves

You can know every algorithm and still struggle in a real interview. The interviewer cannot see your thoughts, the clock is running, and you are nervous. Mock interviews, a scoring sheet and a mistake log are how you practise those parts. This lesson explains the four things interviewers score, the techniques to use before, during and after coding and when you are stuck, how to run a mock with a friend, and how to keep a mistake log.

This is the third lesson of the career series. The first was the resume guide and the second the study plan mapped to this site. For live-coding tasks in detail see Full-Stack Lesson 37, and for the system design version see Full-Stack Lesson 36. For how the interviewer thinks about the same signals, see Team Lead, Lesson 9.

Words used in this lesson

• Rubric is the list of things an interviewer scores, with a description of strong and weak work for each.
• Signal is evidence from the interview that tells the interviewer something about you.
• Think aloud means saying your reasoning as you work, so the interviewer can follow and help.
• Dry run means tracing your code by hand with a small example, line by line.
• Mistake log is a notebook or file where you record each error, its cause and the fix.
• Feedback loop means you do something, get information about how it went, and change what you do next time.

What interviewers score: the four dimensions

The handbook's rubric page says coding interviews are scored on four dimensions, usually on bands such as strong hire, hire, no hire and strong no hire. The final decision comes from overall performance, not from a strict mathematical cutoff. The same four appear in the preparation page. In simple words:

Notice how little of the score is "knows the trick". Three of the four are about how you work. That is good news, because how you work can be practised.

Techniques for the interview

The handbook's techniques page groups its advice by time. These points are from it, in my words:

Before you code

• Ask clarifying questions and discuss a few possible approaches with the interviewer.
• Work through more examples to understand the problem and spot a pattern. Do not start coding too early. These examples can later become your test cases.
• Choose an approach by drawing the problem, solving it by hand, breaking it into smaller functions, or applying common data structures and routines.

While you code

• Start with a high-level structure and fill in smaller functions separately. The page says this shows the interviewer you have an approach, even if you do not finish.
• Communicate your reasoning. Mentioning the best theoretical time complexity is described as a positive signal.
• Write efficient code: avoid redundant checks, cache repeated function calls, keep work out of loops, stop early when you can, and delay work you do not need yet.

After you code

• Verify the solution with your earlier examples used as test cases.
• If the interviewer asks "can we do better?", check the best theoretical time complexity, look for repeated computation, try a different data structure and remove redundant work.
• To reduce space, consider changing data in place (carefully, so you do not destroy input you still need) or switching to a more suitable data structure.

(The handbook page does not spell out dry runs or an edge-case checklist. The rubric page does mention tracing line by line and corner cases, and my list below adds a checklist.)

When you are stuck

The page gives a list you can learn by heart:

1. Draw the problem and its internal states.
2. Solve it by hand, then turn the manual rules into code. A working solution earns credit even if it is not optimal.
3. Generate more examples to find a pattern.
4. Break the problem into smaller independent parts.
5. Systematically try common data structures and routines (hash map, sorting, stack, two pointers and so on).

And say what you are doing: "I am stuck on the fast part, so I will write the slow correct version first."

Mock interviews

The handbook's mock-interview page says the steps of an interview can be rehearsed until they become second nature. Its practical suggestions are: partner with a friend and take turns interviewing each other, or use a practice platform where you can interview engineers anonymously and give and receive feedback. It names interviewing.io as the author's experience. (I did not use any platform, and platform features change.) The study-plan page says to start scheduling mocks when you are about 60% through your plan.

How to run a mock with a friend (my routine)

1. Pick a role each: interviewer and candidate. Swap after 45 minutes. Being the interviewer teaches you a lot, because you see what a clear explanation looks like from the other side.
2. The interviewer picks an unseen problem of the right difficulty, and does not tell the answer. Use the same time limit as the real round (the handbook says rounds last 30 to 45 minutes).
3. The candidate follows a fixed routine: restate, ask questions, give two examples, outline the approach with cost, code, test, optimise.
4. The interviewer stays silent while the candidate is thinking, and gives a small hint only after a real attempt, as a real interviewer would. They write down every hint they gave.
5. Score with the sheet below right after, in writing, before you talk about the result.
6. Spend 10 minutes on feedback. The candidate says first what they think went well and badly. Then the interviewer adds.
7. Write the lessons in your mistake log (below).

A scoring sheet (my version of the rubric)

Score each line from 1 (weak) to 4 (strong). Write one sentence of evidence for each.

The totals do not matter. The lowest line is what you work on this week.

Talking while you code

Many people can solve the problem silently and fail the round, because the interviewer has nothing to score. Habits that help:

• Narrate decisions, not keystrokes. Say "I will use a hash map so lookups are constant time", not "now I type a for loop".
• Name what you are unsure about. "I am not sure about duplicates; I will assume there are none and check later" is a good sentence.
• Pause on purpose. "Give me a minute to think" is fine. Ten silent minutes are not.
• Practise in the open. Solve practice questions out loud even when alone. It feels odd; that is the point.
• Record yourself. The handbook page does not cover this. My suggestion: record one practice solution and listen once. You will hear long silences, "um" and skipped reasoning that you cannot hear while you are working.

The mistake log

A mistake log turns each error into a lesson and shows your pattern over weeks. After every practice question or mock, write one row:

| Date | Question | What went wrong | Why (root cause) | What I do differently ||---|---|---|---|---|| 12 Oct | Longest substring without repeats | Used a Set but moved the left pointer one step too far | I did not trace a small example before coding | Always trace one example by hand first || 14 Oct | Merge intervals | Forgot to sort first | I jumped to code | Write the plan with "sort?" as step 1 || 15 Oct | Valid parentheses (mock) | Missed the empty-string case | No edge-case pass | Test empty and single element every time |

Rules for using it:

1. Write the root cause, not the symptom. "Off by one" is a symptom. "Did not trace an example" is a cause.
2. Read it every week (see the weekly routine in Lesson 1). Re-solve two old mistakes.
3. Count the causes after a month. If "did not trace an example" appears five times, you have found your habit to fix, and it is worth more than learning one more algorithm.
4. Keep it short. One line per mistake, or you will stop writing.

The last ten minutes of an interview

• Do not stop at "it works". Say: "Let me test it" and run two normal examples and two edge cases (empty, one element, duplicates, very large).
• State the complexity in words: "This is linear in the length of the string and uses a hash map, so extra space is linear in the number of distinct characters."
• If you have time, offer an improvement or name the trade-off you did not take.
• If time is nearly out and the code is unfinished, say what the missing parts are and how you would write them. A clear plan earns more than a silent scramble.
• Then use your prepared final questions (see Full-Stack Lesson 38).

Handling nerves (modest advice)

Feeling nervous before an interview is normal. These habits are common sense and general experience, not medical advice:

• Practise the format, not only the content. Mocks make the real interview feel familiar. That is the main reason to do them.
• Have a routine for the first two minutes. For example: greet, restate the problem, ask two questions. A fixed start gives your mind something to hold on to.
• Slow down your voice and your typing when you notice you are rushing.
• If you freeze, return to the "when stuck" list above. Say what you see in the problem; then draw a tiny example.
• Prepare the basics: sleep, food, a quiet room and working audio for remote rounds.
• Treat a bad interview as data. Write what happened in the mistake log. Many strong engineers fail some interviews. If anxiety is affecting your life beyond interviews, talk to a qualified person.

Learning from rejection

• Ask for feedback politely. Some companies will not give it. Do not argue with a decision.
• Write down what you remember within a day: the question, where you got stuck, what you would change.
• Look for the lowest rubric dimension (communication, problem solving, technical competency or testing) and make it next week's focus.
• Keep the loop going. One more mock and one more log entry is more useful than worrying about one result.

Self-check

1. Which four things does a coding rubric score? Communication, problem solving, technical competency and testing.
2. Name three "before you code" techniques from the handbook. Ask clarifying questions, work through more examples, and choose an approach by drawing, solving by hand, splitting into small functions or applying common data structures.
3. What are the "when stuck" steps? Draw the problem, solve it by hand then turn the rules into code, generate more examples, break it into parts, and try common data structures and routines.
4. When should you start mock interviews, according to the handbook's study plan? At about 60% through the plan.
5. Why swap roles in a mock? Being the interviewer shows you what a clear, easy-to-follow explanation looks like.
6. What belongs in a mistake log row? Date, question, what went wrong, the root cause and what you will do differently.
7. What should you do in the last ten minutes? Test normal and edge cases, state the complexity, offer an improvement, and if time is short explain the missing parts and your plan.
8. What is one piece of advice in this lesson that the handbook pages do not cover? Recording yourself and listening once, or keeping a mistake log with root causes. Both are my suggestions.

Key takeaways

• Interviewers score communication, problem solving, technical competency and testing. Three of the four are about how you work.
• Use a fixed routine: clarify, examples, approach with cost, code, test, optimise. When stuck, draw, solve by hand, add examples, split the problem, try common tools.
• Mock interviews make the format familiar. Swap roles, use a real time limit, score in writing, then give feedback.
• A mistake log with root causes finds the habit you most need to change.
• Talk about decisions, not keystrokes. Silence gives the interviewer nothing to score.
• Treat nerves with preparation and routine, and treat a bad round as data, not a verdict.

What's next

You have finished the career series. Next steps: run your first mock with a friend this week and fill in the scoring sheet, then start your mistake log. For the live-coding and take-home formats see Full-Stack Lesson 37, and for the people side of interviews see Full-Stack Lesson 38.