How to run a mock technical interview with a friend

Why mock interviews with friends go wrong

The problem isn’t your friend’s skill. It’s the relationship. People who like you don’t want to watch you struggle, so they fill silences, nod at half-finished ideas and end with “that was great”. A real interviewer does none of those things. The fix is to make the session less personal: a clock, a written scorecard, and an agreement that the interviewer’s job is to find the weak spots.

Before the session

1. Pick the round you’re actually facing. Coding, system design, a general technical round or a behavioral interview each need a different setup and different questions. Don’t practice coding the week before a design round.
2. The interviewer picks the question. The candidate must not see it in advance. If you’re trading sessions, each person prepares the question they’ll ask the other.
3. Agree on three rules out loud. No hints for the first five minutes of being stuck; the clock is not paused for any reason; feedback must include at least two things to improve.
4. Decide who takes notes. The interviewer writes timestamped notes during the session. If a third person joins as an observer, they can take notes too and compare afterwards.

How long each round should take

Real interviews run 30 to 60 minutes. Keep the same length, and always leave time for feedback.

Trading sessions? Do one round each, back to back, with feedback after each. Two 45-minute sessions in an evening is plenty; quality drops after that.

During the session: the interviewer’s script

Opening (2 minutes)

Introduce yourself as you would to a stranger, explain the format (“45 minutes, one problem, then feedback”) and read the prompt once. Don’t add clarifications the candidate didn’t ask for: asking good clarifying questions is part of what you’re assessing.

While they work

• Stay quiet while they think. Write down the time whenever something notable happens.
• Answer questions about the problem precisely and briefly. Don’t volunteer the approach.
• When they’re stuck for a few minutes, use a hint ladder: first ask a question (“what’s slow about this?”), then a nudge (“could sorting help?”), and only then a direct hint. Note which rung they needed.
• Ask at least one follow-up that changes the problem: bigger input, a new constraint, a failure.

Closing (2 minutes)

Stop on time even if they’re close. Unfinished solutions happen in real interviews, and how someone summarises where they got to is worth practicing.

How to give feedback that actually helps

1. Score before you talk. Fill in the scorecard alone first. Once the conversation starts, the candidate’s explanations will soften your judgement.
2. Use the criteria for that round. A design interview is judged on requirements, high-level design, deep dive and trade-offs; a behavioral one on structure, impact and self-awareness. The feedback rubric lists them all with a 1–5 scale.
3. Give evidence, not adjectives. “At minute 18 you changed the data structure without saying why” beats “communication could be better”.
4. Commit to a hire signal. Pick one of Strong hire, Hire, Lean hire, Lean no hire, No hire, Strong no hire. “It depends” teaches nothing; a clear “lean no hire, because…” does.
5. End with the one thing to fix next time. Two or three improvements, with the most important first.

Then swap: the candidate rates the interviewer on clarity, helpfulness and professionalism. Being a good interviewer is a skill, and it’s the side of the table where you learn what strong answers look like.

After the session

• Write down the two improvements somewhere you’ll see them before the next session.
• Look at the saved code or whiteboard and find the moment things went sideways.
• Schedule the next session now, with the same partner or a new one. Different interviewers catch different things.
• Track scores per criterion over several sessions; a single score is noise, a trend is signal.

Common mistakes

What you need to run it

At minimum: a video call, something you can both type or draw in, a timer and a place to write feedback. InnerViewHub puts those in one room: video, a shared editor you can run code in, a shared whiteboard for design rounds, private notes for the interviewer and the scorecard at the end. You invite your partner; nobody else gets in unless you let them.