Articles
Free Mock Interview Scorecard Generator for Coding and System Design
Score coding and system design mocks with weighted rubrics, behavior anchors, critical-gap flags, evidence notes, and a clear next-practice plan.
This free mock interview scorecard generator turns a coding or system design practice session into evidence you can act on. Open the scorecard generator workbook, choose the round type, and replace the yellow sample cells. It loads the relevant weighted rubric and generates a 100-point score, critical-gap status, weakest criterion, and specific next-practice action.
The workbook also creates a formula-linked Print Summary for PDF and a rectangular CSV Export sheet for later analysis. The score calibrates practice; it does not predict an employer decision because rubrics vary. A useful result is not "82 means pass." It is "testing scored 1 because I never ran the empty-input case, so the next session needs a written test plan."
What this scorecard generates
For each mock, the generator gives you six outputs:
- A weighted score out of 100 for either coding or system design.
- A short evidence note for every rating, not just a number.
- A critical-gap list that prevents strengths from hiding a missing core skill.
- One repeatable improvement target for the next session.
- A comparable record you can use to measure progress across prompts.
- A print-ready PDF summary and a CSV-ready export view that stay linked to the current ratings.
Do not compare scores from unlike sessions without context. A 45-minute graph problem, a 60-minute senior system design, and a collaborative debugging round test different things. Record the prompt, time limit, role level, allowed tools, and evaluator before scoring.
Step 1: Create the session header
Fill the yellow session cells before the timer starts. It keeps later comparisons honest and stops you from changing the standard after seeing the result.
| Field | What to record | Example |
|---|---|---|
| Interview type | Coding or system design | Coding |
| Prompt | Exact question title or short description | Parallel BFS crawler |
| Target level | Intern, new grad, mid-level, senior, or staff | Mid-level |
| Time box | Planned working time | 45 minutes |
| Environment | IDE, whiteboard, shared editor, or verbal | Shared editor |
| Allowed tools | Documentation, tests, debugger, or none | Tests and debugger |
| Evaluator | Self, peer, mentor, or interviewer | Peer |
| Practice focus | One skill you are deliberately testing | Edge-case discipline |
Use the same environment you expect in the real round when possible. If you change the timer, tool rules, or help level, note it. Otherwise a higher score may reflect an easier setup rather than stronger performance.
Step 2: Use one anchored 0-4 scale
A behavioral anchor describes what was actually demonstrated at each level. The U.S. Office of Personnel Management recommends choosing proficiency levels and creating behavioral or situational examples for them. That is more useful than rating a session by confidence or personality.
| Score | Label | Evidence standard |
|---|---|---|
| 0 | Not demonstrated | The prompt elicited the behavior, but it was absent |
| 1 | Major gap | An attempt appeared, but it was incorrect, unstructured, or required heavy prompting |
| 2 | Partial | The behavior was workable but incomplete, late, or inconsistent |
| 3 | Strong | The behavior was correct, timely, and explained with limited prompting |
| 4 | Exceptional | The behavior was proactive, precise, adaptable, and supported by clear trade-offs |
Score only what happened. A 0 means the criterion was assessed and missing; choose Assessed? = No when the prompt never elicited enough evidence. "Usually good at testing" is not evidence for a mock where no test was run. A polished answer can still score poorly on correctness; a quiet candidate can score strongly when the reasoning is clear and the solution works.
For every row, calculate:
weighted_points = (rating / 4) x criterion_weight
Add the weighted points for a total out of 100. Keep one decimal place during calculation and round only the final score.
Coding mock interview scorecard
Use this version for algorithms, practical coding, debugging, or repository tasks. Adjust the criterion names before the session when the format is materially different, but keep the weights fixed within a comparison set.
| Coding criterion | Weight | Evidence for 0-1 | Evidence for 3-4 | Rating |
|---|---|---|---|---|
| Problem framing | 10 | Starts coding without confirming input, output, or constraints | Restates the task, clarifies ambiguity, and names important cases | __ / 4 |
| Strategy and decomposition | 20 | Guesses, thrashes, or cannot explain why the approach should work | Breaks the problem down, compares alternatives, and states an invariant | __ / 4 |
| Correctness | 25 | Core logic is missing or wrong on ordinary cases | Produces a correct solution and explains why it covers the requirements | __ / 4 |
| Complexity and trade-offs | 10 | Gives no credible time or space analysis | Derives complexity and discusses when another approach would be better | __ / 4 |
| Code quality | 10 | Code is difficult to follow or mixes responsibilities | Uses clear names, small units, and language-appropriate structure | __ / 4 |
| Testing and debugging | 15 | Runs only the sample or changes code without a diagnosis | Builds normal, boundary, and failure tests; debugs from evidence | __ / 4 |
| Communication and adaptability | 10 | Goes silent or resists new constraints | Narrates decisions concisely and incorporates follow-ups productively | __ / 4 |
Coding total: sum((rating / 4) x weight) = ____ / 100
Also record critical gaps separately. Mark a gap when the final solution does not meet the core requirement, the candidate cannot explain the code, or no meaningful validation occurs. Do not let a high communication score erase a correctness failure. This is a practice safeguard, not a claim about a company's automatic cutoff.
System design mock interview scorecard
System design has no single correct diagram. The scorecard should reward a coherent decision process: scope the problem, attach numbers to scale, connect data and APIs to access patterns, and test the design against load and failure. Atlassian's published candidate guide similarly highlights problem solving, decision making, performance, reliability, and communication.
| System design criterion | Weight | Evidence for 0-1 | Evidence for 3-4 | Rating |
|---|---|---|---|---|
| Requirements and success metrics | 15 | Draws components before defining users, scope, or goals | Establishes functional needs, non-goals, SLOs, and constraints | __ / 4 |
| Capacity assumptions | 10 | Uses "large scale" without quantities or boundaries | Estimates QPS, data volume, bandwidth, growth, and peak conditions | __ / 4 |
| API and data model | 15 | Interfaces and access patterns remain vague | Connects APIs, keys, schema, and consistency to real operations | __ / 4 |
| High-level architecture | 20 | Produces disconnected boxes or an unexplained product list | Traces core flows through a coherent set of components | __ / 4 |
| Scalability and reliability | 20 | Ignores bottlenecks, overload, or failure | Finds limits, handles failure domains, and protects critical paths | __ / 4 |
| Deep dive and trade-offs | 10 | Defends choices by popularity or memorized rules | Compares alternatives and follows one risk to implementation detail | __ / 4 |
| Communication and adaptability | 10 | Loses structure or ignores interviewer changes | Signposts the discussion and revises the design under new constraints | __ / 4 |
System design total: sum((rating / 4) x weight) = ____ / 100
Critical gaps include missing core requirements, an architecture whose main flow cannot work, or no credible handling of the principal bottleneck or required failure. For senior-level practice, shallow product-name listing should also be flagged even when the diagram looks complete.
How to interpret the total
Use score bands to choose the next practice action, not to declare a hire result.
| Practice score | Interpretation | Next action |
|---|---|---|
| 85-100 | Strong execution on this prompt and setup | Repeat with a different prompt or harder follow-up |
| 70-84 | Solid foundation with one or two limiting dimensions | Drill the lowest criterion, then rerun a comparable mock |
| 55-69 | Partial performance with several unstable behaviors | Study one missing skill and use a shorter focused session |
| Below 55 | The framework or execution broke down | Rebuild the approach untimed before another full mock |
A critical gap overrides the comfort of the total. A coding session with incorrect core logic is not "ready" because communication lifted the score to 72. A system design that never addresses the required consistency or failure constraint needs another attempt even if the presentation was polished.
Capture evidence, not impressions
Write one observable note per criterion. Good evidence includes a timestamp, action, consequence, and next change:
| Time | Observable behavior | Criterion | Impact | Next attempt |
|---|---|---|---|---|
| 04:00 | Confirmed duplicates but not empty input | Problem framing | Missed one boundary | Use a three-case checklist before coding |
| 18:00 | Chose BFS and stated the visited-set invariant | Strategy | Prevented duplicate work | Keep this explanation concise |
| 31:00 | Test failed; traced state mutation before editing | Testing | Fixed root cause | Add the failing case before the fix |
Avoid notes such as "seemed smart," "not senior," or "good communicator." They do not tell you what to repeat or repair. GitLab's public scorecard guidance likewise recommends specific examples and assessment only for attributes that were actually covered.
Run a 60-minute mock without gaming the score
Use a repeatable sequence:
- Spend five minutes completing the session header and reading the prompt.
- Run 40-45 minutes under the chosen interview rules. The evaluator records evidence without coaching unless a planned follow-up is due.
- Spend five minutes on the candidate's self-assessment before revealing the evaluator's ratings.
- Score each row independently, compare evidence, and discuss differences of two or more points.
- Pick one lowest-leverage behavior to change and write the exact trigger for using it next time.
Do not immediately redo the same prompt from memory and treat the score increase as general improvement. Use a different problem with the same underlying skill, then return later for a retention check.
Calibrate self-scores and peer scores
Self-assessment is useful, but people vary in strictness. Calibrate with a peer or mentor every few sessions. Both reviewers should score independently before discussion; Greenhouse recommends this order for interviewer feedback because early group discussion can influence individual judgments.
When scores differ, compare evidence rather than averaging automatically. One reviewer may have scored the final code while another scored the process. Decide what the criterion is meant to capture, update its anchor if needed, and keep that definition stable for future mocks.
Common scorecard mistakes
- Changing weights after seeing a disappointing result.
- Giving every criterion a 3 without recording evidence.
- Scoring personality, accent, speed of speech, or similarity to the evaluator.
- Treating one total as comparable across different levels and formats.
- Letting a strong final answer hide heavy prompting or an unsafe process.
- Tracking totals while ignoring the same recurring critical gap.
- Practicing only familiar prompts until the score looks impressive.
The best scorecard is slightly uncomfortable: it makes missing evidence visible and produces one concrete change for the next round.
Frequently asked questions
What is a good mock interview score?
There is no universal passing number. For this practice rubric, 70 or higher suggests a workable session, while 85 or higher suggests strong execution on that prompt. Critical gaps still matter more than the total, and employer rubrics may use different dimensions, levels, and decision rules.
Should I score myself during the mock interview?
No. Run the session under realistic timing, then complete a self-score immediately afterward while the evidence is fresh. Scoring during the round changes your behavior and consumes working time. An evaluator can take notes during the session but should avoid coaching unless the mock explicitly includes follow-ups.
Can I use the same scorecard for intern and senior interviews?
Use the same dimensions for trend tracking, but change the behavioral anchors and prompt difficulty. A senior system design should show deeper ambiguity management, failure analysis, and evolution strategy. An intern coding mock may emphasize correctness, basic complexity, testing, and clear collaboration.
How often should I run a mock interview?
One or two full mocks per week is usually enough when paired with focused drills. The useful cadence is score, diagnose, practice the weakest behavior, and retest on a different prompt. Repeating full mocks without repairing the identified gap mostly rehearses the same mistake.
Should two evaluators average their scores?
Not immediately. Each evaluator should score independently and attach evidence first. Discuss large disagreements, clarify the criterion, and then record a calibrated result if useful. Blind averaging can hide that the reviewers assessed different moments or interpreted an anchor differently.
Final takeaway
A mock interview becomes valuable when it produces more than a feeling. Keep the prompt and conditions visible, score observable behavior against stable anchors, protect the total with critical-gap flags, and turn the lowest dimension into the next drill. After several comparable sessions, the trend and evidence notes matter more than any single number.
Sources and Further Reading
- U.S. Office of Personnel Management: Structured Interviews
- U.S. Office of Personnel Management: Developing a Customized Rating Scale
- Greenhouse: What Is an Interview Scorecard?
- CoderPad: Using Rubrics for Interviewer Notes
- Atlassian Fullstack Engineering Interview Guide
- GitLab: Conducting a GitLab Interview
*Research note: Sources were checked on August 28, 2026.