Interview Notes Template
An interview notes template helps each interviewer record observed evidence and score a candidate on a shared scale, instead of writing scattered impressions and then debating them from memory in a hiring meeting. The template below includes a scorecard, competency-based questions and a filled-in example.
The biggest problem with interview notes is not that too little gets written down, it is that conclusions get written instead of evidence. The candidate communicates well is a conclusion. The candidate explained their previous system architecture to a non-specialist in three minutes is evidence. Only the second kind can be compared across interviewers.
This page covers the structure, how to score in a way that reduces bias, a filled-in example for a technical role, common mistakes, and a short FAQ.
A .docx file that opens in Word, Google Docs and LibreOffice.
When to use this template
Use it for structured interview loops where several interviewers assess one candidate and the results must combine into a single decision. It works best when every interviewer uses the same competency set and the same scale.
For a fifteen-minute phone screen, use a reduced version with basic details, two core competencies and an advance-or-stop conclusion. Filling in the full template for a screening call is unnecessary work.
This is not a performance review template for existing employees, and it does not replace your organisation's formal recruitment records. It is a tool for the interviewer.
Interview notes structure
The nine fields below keep observation separate from conclusion. That separation is the single most important thing about this template.
| Field | How to fill it in |
|---|---|
| Interview details | Candidate name, role, round number, date and interviewer. Record the round number because expectations at round one and round three differ substantially. |
| Format | In person, video call or phone. It matters when comparing, because assessing communication over the phone and in person are not directly comparable. |
| Competencies assessed | The agreed competency list for this role, usually three to five. Settle the list before meeting the first candidate rather than adjusting it midway through. |
| Questions asked | The questions you actually used. Needed to know whether candidates were asked equivalent things, which is the precondition for any meaningful comparison. |
| Observed evidence | What the candidate said and did, as close to verbatim as possible. This field needs the most writing. Avoid every evaluative adjective here. |
| Score per competency | Score against a four-level scale defined in advance. Every score must point back to a specific line in the evidence field, otherwise it is an impression rather than an assessment. |
| Notable strengths | One to three, each with supporting evidence. If you cannot cite evidence, what you are describing is most likely personal rapport rather than professional strength. |
| To probe in the next round | Open questions you lacked data to settle, with suggested questions for the next interviewer. This field makes rounds build on each other rather than repeat each other. |
| Recommendation | One of four: hire, lean hire, lean no, no. Write it after scoring each competency, not before. |
Filled-in example
Notes from a technical round for a software engineer role. The content is illustrative.
| Field | Example content |
|---|---|
| Details | Candidate N.T.M, Software Engineer, round 2 technical, 24 July 2026, interviewer: Nam |
| Format | Video call, 60 minutes |
| Competencies | System design, code quality, problem solving, technical communication |
| Questions asked | Describe a system you designed and why you chose that approach. Short URL shortener design exercise. A time you found your own bug after it reached production. |
| Evidence · System design | Asked about expected scale before drawing anything. Proposed starting simple and named three points that would break at ten times the traffic. Could not describe how to handle collisions in the code generator. |
| Evidence · Technical communication | Explained caching to a non-specialist interviewer in about three minutes using an everyday analogy. When pushed, acknowledged uncertainty directly rather than talking around it. |
| Scores | System design 3/4. Code quality 3/4. Problem solving 3/4. Technical communication 4/4. |
| Strengths | Explains technical concepts to non-specialists very clearly, seen in the caching explanation. Clarifies requirements before solving, seen in asking about scale before drawing. |
| To probe next round | Operational experience with live systems looks thin. Next round should ask about a real incident they handled, their specific role in it, and what changed afterwards. |
| Recommendation | Lean hire |
Record evidence, not conclusions
This is the most important rule and the most frequently broken one. Notes like smart, enthusiastic, a bit inexperienced give a third reader nothing to check. When two interviewers reach opposite conclusions, there is no way to locate the source of the difference.
The fix is to record what the candidate said and did, as close to verbatim as possible, and derive the assessment in a separate field. Then when interviewers disagree, they can compare evidence and usually discover they asked two very different questions.
A quick check: reread your notes and delete every adjective. If nothing remains, the notes had no content.
Define the scale before meeting the first candidate
A four-level scale works better than five because there is no middle to hide in. Interviewers are forced to lean one way, and that lean is precisely the information you are trying to collect.
The four levels should be defined by behaviour rather than adjectives. For system design: level 1 cannot produce a complete approach, level 2 produces one but does not see its weaknesses, level 3 produces one and names what breaks at scale, level 4 is level 3 plus proposing how to measure when the change becomes necessary.
Write those definitions down and circulate them to every interviewer before the first round. A scale with no shared definition is just a way of encoding gut feeling as a number, and the number creates a false sense of objectivity.
Score immediately, before talking to other interviewers
Notes and scores should be finished within thirty minutes of the interview and, more importantly, before hearing another interviewer's view. A single remark overheard in a corridor is enough to change how you remember the conversation.
This is not weak-mindedness, it is how memory works. Once you know someone else rated a candidate highly, you recall the positive details more sharply and the negative ones more faintly, entirely without intending to.
In the debrief, have the most junior interviewer speak first. If the most senior voice goes first, the rest of the meeting tends to be confirmation of that view.
Writing the probe-next-round field
This field is what turns an interview loop into a process that accumulates. Without it, every round starts from zero, the candidate gets asked the same question three times, and the genuine open questions never get explored.
Write it specifically enough that the next interviewer can use it directly. Instead of check operational experience further, write ask about a real incident they handled, their specific role in it, and what changed afterwards.
The field also helps when a candidate is rejected. Clear notes let you give a specific reason rather than a generic response, and they help you when the same candidate applies again a year later.
Five common interview note mistakes
Good communicator cannot be compared. Explained caching to a non-specialist in three minutes can be.
One remark heard before you score is enough to change how you remember the interview. Finish notes and scores within thirty minutes.
If candidates were not asked equivalent things, comparing them is meaningless no matter how tidy the scorecard looks.
A scale with no behavioural description per level is just gut feeling encoded as a number, and the number creates objectivity that is not there.
Notes about appearance, age, family situation or background are irrelevant to capability and can create legal exposure. Record only what relates to the role requirements.
FAQ
How many levels should the scale have?
Four works better than five because there is no middle to hide in, forcing interviewers to lean one way. More important than the number of levels is that each one is described by specific behaviour rather than an adjective.
When should notes be finished?
Within thirty minutes of the interview and before discussing it with other interviewers. Hearing another view before you score changes how you recall the conversation without your noticing.
Can interviews be recorded?
Ask the candidate explicitly before starting and accept a refusal. When permission is given, recording lets the interviewer focus on the conversation rather than questioning and typing at once, and it makes the evidence field much closer to verbatim.
How long should interview notes be kept?
According to your organisation's policy and the personal data rules that apply to you. As a principle, keep only what relates to the hiring decision, for as long as that purpose requires, with restricted access.
What if two interviewers reach opposite conclusions?
Compare the evidence rather than debating the conclusions. Very often the two asked different sets of questions and were effectively assessing different things. This is exactly why the evidence field must be kept separate from the scores.
Record the interview so you can focus on the candidate
Questioning and typing at the same time makes interviewers miss the very details they are supposed to assess. Meco records the interview and produces a transcript and summary, so you can fill the evidence field with near-verbatim wording rather than recollection.
Meco captures both in-person interviews in a room and phone calls. Remember to ask the candidate's permission before recording, and note that every set of minutes in Meco is private by default.
Try it free