how to run an effective mock interview (with a peer or mentor)

Mock interviews are one of the highest-payoff things you can do before a real interview—if you run them well. A sloppy practice session can give false confidence, while a structured mock will reveal weak spots and build muscle memory.

This guide walks you through setting up realistic mocks with a peer or mentor, choosing prompts for different roles, timing rounds, and using a short feedback and scoring routine that you can apply immediately.

who should you practice with and how often

Pick someone who can replicate the interview experience you expect. That doesn’t always mean a hiring manager—good options are a more senior peer, a mentor familiar with the role, or a fellow candidate who’s also preparing. The key is credibility: they should know the role’s core skills and the interview format (behavioral, technical, whiteboard, case, product, etc.).

Frequency depends on timeline. If you have a month, aim for two solid mocks per week: one focused on content (answers, coding, case structure) and one replicating the full loop under time pressure. If you have less time, do at least three targeted mocks in the final week.

• Ideal practice partner: someone who understands the interview format and can play the interviewer role.
• Alternate partners: peer for frequent practice, mentor for higher-fidelity critique, coach for targeted issues.
• Goal cadence: twice weekly when you have several weeks; three focused sessions in the final week.

set a clear brief before each session

Start every mock with a five-minute brief so both people know expectations. Clarify the role, the interview stage you’re simulating (screen, technical pairing, on-site), and the success criteria. This keeps the mock realistic and prevents drift into vague practice.

Example brief: “We’re doing a 45-minute technical phone screen for a backend engineer role at a mid-stage startup. Focus on system design and algorithms. I’ll act as the hiring manager. Use a plain-text editor—no internet.”

• State role, stage, and timebox (e.g., 30m screen, 60m coding).
• Decide allowed resources (whiteboard, laptop, internet, notes).
• List 2–3 core competencies to test (e.g., API design, tradeoffs, coding correctness).

use realistic prompts and role-specific scripts

Generic questions are fine for quick warm-ups, but real value comes from role-specific prompts. Prepare a short script with 3–5 questions that mirror what the company or role will likely ask. For engineers include bug fixes, complexity tradeoffs, and a short coding task. For product roles include a product design prompt and a prioritization tradeoff. For sales or customer-facing roles include a mock pitch and an objection-handling scenario.

Scripts help the interviewer stay consistent across multiple practice runs and let you compare performance over time.

• Software engineer example: one system-design (15–20m), one algorithmic problem (20–25m), one behavioral (5–10m).
• Product manager example: one product-sense prompt (20m), one prioritization case (15m), one stakeholder conflict behavioral (10m).
• Designer example: portfolio walkthrough (20m), whiteboarding a UX flow (25m), critique session (10m).

timeboxing and the ‘real interview’ constraints

Treat the mock like the real thing: enforce time limits, realistic tools, and interruption patterns (e.g., 'the interviewer needs to leave in 5 minutes'). That builds pacing skills—knowing when to pivot from deep coding to summary, or when to give a quick, structured answer instead of rambling.

If the real interview will be remote with a shared editor, use the same setup. If it’s in-person whiteboard, stand up and use a whiteboard or paper. Small details matter: sitting with a laptop at a table feels different from standing at a board.

• Use actual time limits (e.g., 45 minutes) and a visible timer.
• Mimic allowed resources (e.g., no internet, single monitor).
• Simulate interruptions or ambiguous prompts to practice clarifying questions.

feedback that actually helps you improve

Most feedback sessions go one of two ways: vague praise or harsh critique without a path forward. Make feedback actionable by combining a quick scorecard with 3 specific suggestions. Keep the session under 15 minutes so it’s focused and you can do more mocks without burnout.

Ask your interviewer to name: (1) one thing you did well, (2) one thing that cost you time or clarity, and (3) one concrete fix. That last item should be something you can try in the next mock (e.g., 'open your thought process by restating the problem and listing edge cases').

• Use a 1–5 scale for 4 categories: clarity, structure, technical correctness, communication.
• Record timestamps of issues (e.g., 12:30 you started coding before confirming constraints).
• Agree on one micro-action for the next mock (e.g., ask two clarifying questions before coding).

a simple scoring rubric you can reuse

Keep scoring minimal so you actually use it. Four dimensions, 1–5 each, is enough: problem understanding, solution approach, execution (coding/design), and communication. Total score helps track progress across mocks; per-dimension notes highlight persistent weak spots.

Don’t overfit to the score. Use it as a compass, not a verdict. Two consecutive +1 improvements in execution probably matter more than a single high score.

• 1–2: needs work; 3: acceptable with flaws; 4: strong; 5: excellent.
• Write one sentence per dimension explaining the score.
• Keep a short log of mock date, role, and scores to see trends.

Mock interviews become far more effective when they’re repeatable and focused. Run short, frequent sessions with clear briefs, realistic constraints, and a short, actionable feedback loop.

Use the simple rubric and micro-action system above: pick one concrete improvement each session and track your scores. You’ll find weak spots faster, get comfortable under time pressure, and increase your odds of doing the real interview well.