Post-Interview Self-Assessment Guide: The Engineer's Rubric

You walk out of the Zoom room, close the laptop, and your brain immediately begins a messy loop. Did I handle that graph question well? Why did I say "obviously" three times? Should I have asked about constraints earlier? The first thirty minutes after an interview are the highest-signal moment of the entire hiring process for you as a candidate — and most engineers waste it on rumination instead of evaluation.

This guide gives you a rubric designed for the way engineers actually think. Six dimensions, a 1-5 scale, and an action item for every score you give yourself. The goal is not to flatten the experience into numbers. The goal is to turn a fuzzy memory into six small repeatable improvements before your next loop.

Table of Contents

• Why a Rubric Beats a Vibe
• When to Run the Assessment
• The Six Dimensions
• Dimension 1: Clarity
• Dimension 2: Correctness
• Dimension 3: Optimization Talk
• Dimension 4: Testing
• Dimension 5: Communication
• Dimension 6: Recovery
• The Scoring Template
• Action Items by Score
• The 48-Hour Follow-Through
• Common Assessment Failures
• FAQ
• Conclusion

Why a Rubric Beats a Vibe

After an interview, your memory is biased toward the loudest moment. A bug you caught at minute 40. A panicked silence at minute 25. The one hint you didn't need. A vibe-based review will over-weight that moment and under-weight everything else that actually determined the signal.

A rubric does three things a vibe cannot. First, it forces you to visit every dimension even when you'd rather not. Second, it produces comparable data across loops, so you can watch your testing score climb from a 2 to a 4 over a month. Third, it converts shame into specificity. "I bombed it" becomes "My recovery score was a 2 because I froze for ninety seconds instead of narrating what I didn't know."

Specificity is the only input that makes practice useful.

When to Run the Assessment

Run the assessment within 90 minutes of the interview ending. Sooner is better, but too soon and you'll still be adrenaline-tired. Too late and the tactile memory of the session decays — you'll remember what you felt but not what you said.

If the interview was virtual and the company allows self-recorded audio for your own notes, play it back once at 1.25x speed before you score yourself. If not, write a 90-second stream-of-consciousness dump of what happened in order, then score against the dump rather than against your vibe.

Pick a consistent place. A scratch file in a notes app, a spreadsheet with columns per dimension, or a simple markdown template. The format matters less than the consistency.

The Six Dimensions

The six dimensions below are the ones that correlate most strongly with interviewer feedback across hundreds of reported debriefs. They are not equal in weight — most loops weigh correctness and communication more heavily than optimization — but you should score all six regardless.

1. Clarity. Did you understand the problem before writing code?
2. Correctness. Did your solution handle the cases you claimed it handled?
3. Optimization Talk. Did you surface trade-offs without being asked?
4. Testing. Did you test, or did you hope?
5. Communication. Did the interviewer know what you were doing at all times?
6. Recovery. When something broke, how fast did you unstick?

Each is scored 1 to 5. A 3 is the baseline pass for a mid-level candidate. A 4 is the baseline pass for senior. A 5 is rare and should make you suspicious — most 5s are actually 4s with flattery.

Dimension 1: Clarity

Clarity is about the first five minutes. It covers whether you asked about input size, input shape, mutation constraints, output format, and the degenerate cases. Interviewers almost universally report that candidates who clarify early produce better solutions and feel senior, even when the final code is identical.

Score yourself honestly against the anchors below.

• 1 — Started coding immediately. Never asked a clarifying question.
• 2 — Asked one vague question ("Any edge cases I should worry about?").
• 3 — Asked about input size and one edge case. Missed output format or mutation.
• 4 — Asked targeted questions covering size, shape, mutation, and at least two edge cases. Confirmed understanding with an example before coding.
• 5 — Did all of the above and restated the problem in your own words, including the interviewer's implicit assumptions.

Action items by score are in the section below.

Dimension 2: Correctness

Correctness is not "did you pass all test cases the interviewer ran." It is "did your solution do what you claimed it did, for the inputs you claimed to support." An interviewer who runs your code on a case you never discussed and sees it fail will score you generously on correctness if you noted the limitation aloud. Silent incorrectness is the expensive kind.

• 1 — Final code had a logic bug you did not catch.
• 2 — Final code passed the main case but you missed an obvious edge.
• 3 — Passed the main case and most edges. Missed one edge you should have caught.
• 4 — Passed all cases you claimed to support. Explicitly noted any cases you were not handling.
• 5 — Passed all cases including edge cases you proactively enumerated. Sanity-checked with a non-trivial example before declaring done.

A common trap: scoring yourself a 4 because "the interviewer said it worked." The interviewer's job is not to score correctness for you. Replay your own code against an input you did not discuss during the interview. That is your correctness score.

Dimension 3: Optimization Talk

Optimization talk is the meta-conversation around your solution's time and space complexity. It covers whether you stated the complexity of your first approach, proposed a better approach with specifics, discussed trade-offs, and were honest about what you couldn't improve.

• 1 — Never mentioned complexity. Interviewer had to ask.
• 2 — Mentioned big-O when asked but got it wrong.
• 3 — Correctly stated complexity of your solution but did not propose alternatives.
• 4 — Stated complexity, proposed at least one alternative, and explained why you chose your approach.
• 5 — Discussed multiple approaches with concrete trade-offs (space vs time, read vs write, preprocessing cost), and referenced the constraints from Dimension 1 to justify your pick.

A 5 here is genuinely rare. Most senior engineers land at a 4.

Dimension 4: Testing

Testing is the dimension that separates adequate candidates from strong ones more reliably than any other. Writing working code quickly is table stakes. Writing code and then immediately walking it through three inputs with the interviewer watching is what senior looks like.

• 1 — Did not test. Ran the code once and declared it done.
• 2 — Ran on the example input only. Did not walk through the code.
• 3 — Ran on the example and one edge case. Walked through the happy path.
• 4 — Ran on multiple cases including empty, single-element, and duplicate cases. Walked through both happy path and at least one edge.
• 5 — Wrote test cases before calling the function. Walked through the code narrating state at each step. Caught and fixed at least one issue during testing.

Note the language: "walked through the code" means reading your own code aloud while tracing variable state. It is the single highest-signal activity a candidate can do in the last ten minutes.

Dimension 5: Communication

Communication covers whether the interviewer ever had to ask "what are you doing right now?" If yes, you scored a 2 or below. Senior engineers narrate by default — not constantly, but at every decision point.

• 1 — Long silences. Interviewer asked multiple times what you were thinking.
• 2 — Some narration but lots of silent coding. Interviewer asked once.
• 3 — Narrated your approach but went silent during implementation.
• 4 — Narrated approach, implementation decisions, and any changes mid-code.
• 5 — Narrated constantly without being performative. Paused appropriately for the interviewer to react. Asked confirming questions at decision points.

Communication is the dimension most candidates overestimate. Record yourself in a mock interview once — you will be shocked by how much you are not saying.

Dimension 6: Recovery

Recovery measures what you did when something went wrong. Every real interview has a broken moment: a confusion, a wrong answer, a bug you didn't see, a hint from the interviewer you didn't expect. Your recovery score is more correlated with offer outcomes than any other dimension except correctness.

• 1 — Froze. Went silent for more than 30 seconds. Had to be rescued.
• 2 — Attempted to continue but the error compounded. Interviewer had to intervene.
• 3 — Recognized the issue within a minute and backed up.
• 4 — Recognized the issue quickly, narrated what you were changing and why, recovered without a hint.
• 5 — Recognized the issue, stated what you thought was wrong, asked a clarifying question if needed, and recovered with a cleaner approach than the original.

A 5 on recovery often comes from moments that looked like disasters mid-interview. Do not underscore yourself because you felt embarrassed.

The Scoring Template

Copy the template below into your notes app and run it after every interview. Seven minutes, maximum.

Company:
Role / Level:
Round:
Interviewer Style: (collaborative / hands-off / adversarial)
 
Clarity:          [ 1  2  3  4  5 ]   One-line evidence:
Correctness:      [ 1  2  3  4  5 ]   One-line evidence:
Optimization:     [ 1  2  3  4  5 ]   One-line evidence:
Testing:          [ 1  2  3  4  5 ]   One-line evidence:
Communication:    [ 1  2  3  4  5 ]   One-line evidence:
Recovery:         [ 1  2  3  4  5 ]   One-line evidence:
 
Weakest dimension:
Strongest dimension:
Surprise moment:
One thing to practice before next loop:

The one-line evidence field is non-negotiable. If you cannot write a sentence of evidence, you have not scored yourself — you have guessed.

Action Items by Score

Below is a mapping from score to next-session practice. Each item is scoped to a single week of focused work.

For Clarity scores of 1 or 2, run three practice problems where you are not allowed to write any code until you have asked four clarifying questions. For scores of 3, add the habit of restating the problem back to the interviewer in one sentence.

For Correctness scores of 1 or 2, take your last three interview problems and run them against five adversarial inputs each. For scores of 3, introduce a checklist of standard edge cases you walk through silently before declaring done: empty, single, duplicates, max size, overflow.

For Optimization scores of 1 or 2, practice the complexity drill: for the next ten problems you solve, state time and space complexity aloud before writing code. For scores of 3, pick three problems and write two solutions to each, then compare trade-offs in writing.

For Testing scores of 1 or 2, adopt the rule that no solution is complete until you have traced it through two inputs aloud. For scores of 3, introduce a pre-commit habit: you cannot declare done until you have written three test inputs in comments.

For Communication scores of 1 or 2, record yourself in a mock interview and listen back at 1.5x. Count the silent seconds. For scores of 3, practice the "narrate at decision points" drill: pause, state what you are about to do, then do it.

For Recovery scores of 1 or 2, seek out mock interviews with adversarial interviewers who deliberately throw you off. For scores of 3, practice the "pause and name" technique: when you are confused, say aloud "I'm not sure about X — let me think for thirty seconds."

The 48-Hour Follow-Through

The scoring exercise is worthless unless you convert it into a small practice session within 48 hours. The half-life of interview memory is about three days — after that, you cannot reconstruct what happened with enough fidelity to learn from it.

Block 30 minutes the day after the interview. Pick your lowest-scoring dimension. Do one exercise from the action items above. Write two sentences on what you noticed. Store the note somewhere searchable.

Do not wait for the next interview to be scheduled. Do not wait to "see if you got the offer." The learning is independent of the outcome.

Common Assessment Failures

Certain failure modes show up in almost every engineer's first few self-assessments. Watch for them.

The first is collapsing all six dimensions into a single vibe score. You feel good, everything is a 4. You feel bad, everything is a 2. The whole point of the rubric is to separate signal. If your six scores are all within one point of each other, you are not scoring — you are feeling.

The second is scoring yourself against the offer outcome. You got the offer, so you were a 5 everywhere. You did not, so you were a 2. The outcome is not the signal. Strong candidates get rejected for headcount reasons. Weak candidates get offers at companies with high false-positive rates. Score the performance, not the result.

The third is scoring too generously on Recovery because you feel embarrassed about the moment. Be especially skeptical of recovery self-scores above 3 — most candidates rate a panicked 45-second silence as a "4, I handled it."

The fourth is never returning to the notes. A year of post-interview rubrics is a goldmine of self-knowledge. If you never read them, you are journaling, not improving.

FAQ

How long should the assessment take? Five to ten minutes. If you are spending more than 15, you are either over-processing or avoiding a different task. Keep it short and repeatable.

What if I cannot remember the interview clearly enough to score? Score what you can and leave the rest blank. Next time, do the 90-second stream-of-consciousness dump immediately after the interview. The problem is not memory — it is capture timing.

Should I share the assessment with a mock interview partner? Yes, after you have done it yourself first. Their scores on the same dimensions are among the highest-signal external feedback you can get. Disagreement is especially useful.

What if my scores are always in the 3-4 range? That means either (a) you are genuinely in that band, which is an honest place to be, or (b) your rubric is miscalibrated. Look at your lowest-scoring interview and ask whether a 1 or 2 was ever warranted. If not, you may be anchoring on the middle.

Does this work for system design interviews? The dimensions still apply, but the anchors shift. Clarity becomes requirements gathering. Testing becomes capacity estimation. Optimization Talk becomes trade-off discussion. Build a separate anchor card for system design interviews and keep them in parallel.

How often do scores actually change with practice? Communication and Testing move fastest — typically within two to four weeks of deliberate work. Clarity and Recovery take longer because they require confidence under pressure. Correctness and Optimization track your overall technical depth and move on the timescale of months.

Is it worth assessing recruiter screens and behavioral rounds? Yes, with adapted dimensions. For recruiter screens, replace Testing with Story Structure. For behavioral rounds, replace Optimization with Specificity.

What if the interviewer was bad — do I still score myself? Yes. Your job is to control your performance, not the interviewer's. If the interviewer was hostile or poorly prepared, make a separate note, but score your own dimensions honestly.

Conclusion

The post-interview window is where most of the compounding happens in an engineering interview practice. Not the prep before, not the interview itself — the 90 minutes after, when a rubric can turn fuzzy memory into a specific action item you can actually work on.

Six dimensions. A 1-5 scale. One sentence of evidence each. Thirty minutes of follow-through within 48 hours. Repeat for every loop.

If you do this consistently for three months, you will either discover a clear pattern of weakness to fix, a clear pattern of strength to lean on, or both. What you will not discover is that you are exactly where you thought you were. Self-assessment is cheap. Honest self-assessment is rare. The rubric exists to make the second one a habit.