Interview feedback examples: hire, no-hire and mixed, each tied to what was heard

Useful interview feedback names what the candidate did, under the question it was heard on, and what that says about one skill. Below are nine write-ups from a coding, a system design and a behavioral round: a hire, a no-hire and a mixed one for each, every one tied to the signals the interviewer marked.

Updated . Written by Hirezen. The candidates are invented; every signal is quoted from a published interview plan, and every recommendation is one of the four the app offers.

Two colleagues in a small meeting room comparing handwritten notes after an interview
Image generated with AI.

On this page

  1. 1. Vague feedback, rewritten as evidence
  2. 2. What useful interview feedback holds
  3. 3. Coding round feedback examples
  4. 4. System design round feedback examples
  5. 5. Behavioral interview feedback examples
  6. 6. Why interview feedback arrives late, and what gets it in the same day
  7. 7. Feedback for the candidate is a different job
  8. 8. Questions

Vague feedback, rewritten as evidence

The feedback that stalls a debrief is an opinion with nothing under it: “not strategic”, “strong communicator”, “not sure”. Each line below is one of those, rewritten from the write-ups further down as something the candidate did, at a moment the interviewer can name. The rewrite is what lets someone else agree or disagree.

Instead ofWrite what happened
“Not strategic enough”Had a full diagram by 14:00 without asking what a wrong cached answer costs.
“Strong communicator”Gave the customer, the problem in hours a week, what shipped and their own part in under two minutes.
“Seemed junior”Retried the identical request three times at temperature 0 and expected a different answer.
“Good team player”Named the two data engineers on the engagement and what each of them owned.
“Smart, but something was off”Asked what a wrong answer costs at 03:05, then proposed caching everything with no expiry.
“Not sure about them”Would settle it: what the customer sees when the call fails. Question 3 was not reached.

What useful interview feedback holds

Useful feedback is written for the people who decide, not for the candidate. It ties what was heard to the question that drew it out, reads one skill at a time, gives a moment rather than an adjective, and ends on a side, with the question that would settle any doubt written down for the next interviewer.

Under the question
Each observation sits under the question that drew it out, so a reader can tell what was asked before judging what was said. “Struggled with design” means nothing until it says which prompt.
One skill at a time
The feedback says which skill each observation is about. A strong answer on one skill does not lift another, and a round that reads two is two reads, not one impression.
A moment, not an adjective
What the candidate said or did, and when: “asked what a wrong cached answer costs before drawing anything, at minute two”. An adjective is a conclusion the reader cannot check.
A side, and what would settle it
A recommendation of Strong No, No, Yes or Strong Yes, with no middle. A doubt becomes a question the next round can ask, written down, rather than a vote for “unsure”.

Coding round feedback examples

A 60-minute coding round for an AI engineer: a function that calls a model works on the happy path, and the candidate makes it safe to put in front of a customer. The three write-ups read the round’s first question, on what the code does when the model’s output is wrong, against five of its signals.

The opening question

“The function works against the happy path. Make it safe to put in front of a customer. Start wherever you think the biggest hole is, and tell me why that one.”

Priya Raman

Hire

Strong YesI would argue for them in the debrief

Readings

  • Validates the model's output against a schema at the boundary rather than trusting its shape

    Yesmarked at 04:10

  • Treats a parse failure as an expected outcome with a policy, not as an exception to log

    Last good summary, then the review queue

    Yesmarked at 06:30

  • Notices the schema-valid refusal — every field present, the content an apology — and says schema validation cannot catch it

    Yesmarked at 19:40

  • Does not retry with a byte-identical prompt at temperature 0 and expect a different result

    Yes

  • If it re-asks, appends what was wrong to the next attempt, and bounds the number of attempts

    No cap and no hint until asked

    Nomarked at 31:05

Written feedback

Started at the parse, not the prompt. Put a schema check on the model’s output at minute four and gave a failed parse a policy: serve the last good summary, then send the ticket to the review queue, rather than log it and return null. At 19:40, shown the sample that passes the schema and apologizes, said the schema cannot catch it and added a cheap check on the summary itself before any second call. Did not retry the same prompt at temperature 0. The gap: re-asked with no cap and without telling the model what was wrong, until asked; fixed in one line once asked.

Would settle it

Whether a bounded re-ask comes unprompted. Ask about retries in the untrusted-input round.

Elena Fischer

No hire

NoBelow the bar for this round

Readings

  • Validates the model's output against a schema at the boundary rather than trusting its shape

    Nomarked at 08:20

  • Treats a parse failure as an expected outcome with a policy, not as an exception to log

    Logged it and returned null

    No

  • Notices the schema-valid refusal — every field present, the content an apology — and says schema validation cannot catch it

    Called the apology valid output

    Nomarked at 23:10

  • Does not retry with a byte-identical prompt at temperature 0 and expect a different result

    Three identical retries

    No

  • If it re-asks, appends what was wrong to the next attempt, and bounds the number of attempts

    Not sure

Written feedback

Wrapped the call in a try/except, logged the error and returned null, so every caller would have to know about the failure. When the response wrapped in a code fence broke the parse, added a pattern for one fence style and moved on. Shown the schema-valid apology at 23:10, called it valid output. Retried the identical request three times at temperature 0 and expected a different answer. The code itself was quick and readable; the gap is treating model output as trusted input, which is what this round is for.

Tomás Herrera

Mixed

YesMeets the bar; I would work with them

Readings

  • Validates the model's output against a schema at the boundary rather than trusting its shape

    Yesmarked at 05:00

  • Treats a parse failure as an expected outcome with a policy, not as an exception to log

    Said “handle it”, no policy

    Not sure

  • Notices the schema-valid refusal — every field present, the content an apology — and says schema validation cannot catch it

    Yesmarked at 17:20

  • Does not retry with a byte-identical prompt at temperature 0 and expect a different result

    Yes

  • If it re-asks, appends what was wrong to the next attempt, and bounds the number of attempts

    Two attempts, validation error appended

    Yesmarked at 26:40

Written feedback

Strong on the model’s side: a schema check first, caught the polite refusal at 17:20 without a hint, and bounded the re-ask to two attempts with the validation error appended. Weaker on what the caller gets: said a failed parse would be “handled” and never said what the customer sees, so the failure path still returns nothing defined. Leaning Yes because the hard part, treating model output as untrusted, came unprompted.

Would settle it

What the customer sees when the call fails. Question 3 was not reached; ask it in the next round.

Start free with this planRead the full round plan The AI Engineer, LLM features loop

System design round feedback examples

A 60-minute system design round for an AI engineer: users ask one question a hundred ways, and the candidate designs a cache for the answers. The three write-ups read the opening question, which is where the round is won, against five of its signals: whether the design starts from what a wrong answer costs.

A candidate drawing boxes and arrows on a whiteboard while an interviewer takes notes at a table
Image generated with AI.

The opening question

“Our users ask the same question a hundred different ways, and we pay for every one of them. Design me a cache.”

Daniel Okafor

Hire

YesMeets the bar; I would work with them

Readings

  • Asks what a wrong cached answer costs before proposing any mechanism

    Yesmarked at 02:15

  • Asks whether answers are specific to the asking account, and gives an example of one that would be

    Remaining quota as the example

    Yesmarked at 05:40

  • Asks how stale an answer may be, and ties it to something that actually changes — pricing, a release, a policy

    Yes

  • Names latency and cost as separate goals and asks which one is being bought

    Not sure

  • Proposes a first cut that is narrower than the whole feature — one topic, one surface, read-only questions

    Yesmarked at 09:30

Written feedback

Asked what a wrong cached answer costs at 02:15, before drawing anything, and used the answer for the rest of the section. Gave a remaining-quota question as an answer that must never be shared across accounts. Tied staleness to the pricing page changing, not to a fixed expiry. Proposed starting with read-only how-to questions on one surface. Treated latency and cost as one goal and never said which the cache was for.

Would settle it

Latency or cost, if only one could be bought. One question early in the next design round.

Sofia Marquez

No hire

NoBelow the bar for this round

Readings

  • Asks what a wrong cached answer costs before proposing any mechanism

    Full diagram, cost never raised

    Nomarked at 14:00

  • Asks whether answers are specific to the asking account, and gives an example of one that would be

    No

  • Asks how stale an answer may be, and ties it to something that actually changes — pricing, a release, a policy

    “A day” with no reason

    Not sure

  • Names latency and cost as separate goals and asks which one is being bought

    No

  • Proposes a first cut that is narrower than the whole feature — one topic, one surface, read-only questions

    Everything, from day one

    No

Written feedback

Opened with an embedding store and a similarity threshold, and had a full diagram by 14:00 without asking what a wrong cached answer costs. Never raised answers that differ by account, so the design would serve one customer’s quota to another. Set a one-day expiry without saying what changes daily, and proposed caching every question from day one. The diagram was clean and well explained; the gap is that the design started from the mechanism, not the risk.

Hannah Weiss

Mixed

NoBelow the bar for this round

Readings

  • Asks what a wrong cached answer costs before proposing any mechanism

    Yesmarked at 03:05

  • Asks whether answers are specific to the asking account, and gives an example of one that would be

    Yesmarked at 06:10

  • Asks how stale an answer may be, and ties it to something that actually changes — pricing, a release, a policy

    “Answers don’t go stale”

    No

  • Names latency and cost as separate goals and asks which one is being bought

    Not sure

  • Proposes a first cut that is narrower than the whole feature — one topic, one surface, read-only questions

    Nomarked at 12:30

Written feedback

Asked the right first question, what a wrong answer costs, at 03:05, and flagged account-specific answers unprompted. Then used neither: at 12:30 proposed caching the whole assistant on day one with no expiry, saying answers do not go stale. Two strong instincts that did not reach the design. Leaning No because the design would ship the risk the candidate had just named.

Would settle it

Given the cost already named, would the first cut narrow? Worth one question in the next design round.

Start free with this planRead the full round plan The AI Engineer, LLM features loop

Behavioral interview feedback examples

A 60-minute behavioral round for a forward deployed engineer: one past customer engagement, told end to end. The three write-ups read the opening question, the two-minute version, against five of its signals: whether the story arrives in the customer’s terms, with the candidate’s own part separate from the team’s.

An interviewer writing a note while a candidate explains something across a small table
Image generated with AI.

The opening question

“Give me the two-minute version first: who the customer was, what problem they had in their terms, what you shipped and when, and what your part was.”

Ravi Menon

Hire

Strong YesI would argue for them in the debrief

Readings

  • Covers customer, problem, what shipped, when and their own part, inside about two minutes

    Yesmarked at 01:55

  • States the customer's problem in the customer's units - money, hours, risk, a date - rather than as a technology

    40 hours a week of manual review

    Yes

  • Names their own part precisely, including who else worked on it and what those people did

    Yes

  • Describes what shipped as something that ran, not as a recommendation, a prototype or a document

    Yes

  • Names the outcome the customer judged it on, even if it was missed

    Missed the 30-day target by a week

    Yesmarked at 01:40

Written feedback

Gave the whole engagement in under two minutes: an insurer, 40 hours a week of manual claims review, a triage service running in production after nine weeks, and their own part, the extraction and the rollout, with the two data engineers who owned the pipeline named. Said without being asked that the customer judged it on a 30-day target, and that it was missed by a week.

Lena Novak

No hire

NoBelow the bar for this round

Readings

  • Covers customer, problem, what shipped, when and their own part, inside about two minutes

    Still on the architecture

    Nomarked at 06:30

  • States the customer's problem in the customer's units - money, hours, risk, a date - rather than as a technology

    “They needed RAG”

    No

  • Names their own part precisely, including who else worked on it and what those people did

    “We” throughout

    Not sure

  • Describes what shipped as something that ran, not as a recommendation, a prototype or a document

    No

  • Names the outcome the customer judged it on, even if it was missed

    No

Written feedback

Opened with the architecture and was still on it at 06:30. The customer’s problem came as a technology, “they needed RAG”, never as hours, money or a date. Said “we” throughout, so their own part could not be told apart from the team’s. What shipped was a proof of concept handed to the customer’s IT team, and no outcome the customer measured was named.

Would settle it

Which part was theirs alone. Ask once, directly, in the next round that reads Ownership.

Chris Duarte

Mixed

YesMeets the bar; I would work with them

Readings

  • Covers customer, problem, what shipped, when and their own part, inside about two minutes

    About four minutes, one prompt

    Not sure

  • States the customer's problem in the customer's units - money, hours, risk, a date - rather than as a technology

    A filing deadline

    Yes

  • Names their own part precisely, including who else worked on it and what those people did

    Yesmarked at 03:20

  • Describes what shipped as something that ran, not as a recommendation, a prototype or a document

    Yes

  • Names the outcome the customer judged it on, even if it was missed

    “It went well”

    Not sure

Written feedback

Took about four minutes and one prompt to reach their own part, but everything was there once it came: a filing deadline the customer could not move, a reconciliation job running nightly in production, and a precise split of who built what. Could not say what the customer measured it against beyond “it went well”. Leaning Yes: the engagement was real and theirs; the outcome is the open question.

Would settle it

What number the customer judged it on. Question 4 was not reached; ask it in the next round.

Start free with this planRead the full round plan The Forward Deployed Engineer, AI deployments loop

Why interview feedback arrives late, and what gets it in the same day

Feedback is late because it is written from memory, after the interview, about everything at once. It arrives the same day when most of it is written during the interview, against a plan that names what to listen for, about two skills, and when someone who leads the hire can see whose write-up is missing.

Marked as it is heard
In Hirezen the interviewer marks each signal Yes, Not sure or No during the interview and types short notes under the question. The evidence exists before the call ends.
Two skills a round
In Hirezen an interview checks two skills at most. Feedback about two things is written in minutes; feedback about everything is put off.
A draft to edit, not a blank page
AI drafts the written feedback from the marks and notes, never from the recommendation, which it is not shown. The interviewer edits it or writes their own.
The gap is visible
The debrief shows how long after the interview each write-up was filed, and whoever leads the hire can remind the interviewer whose write-up is missing.

Feedback for the candidate is a different job

Everything above is written for the people who decide. Feedback given to a candidate after an interview is a different job: shorter, about the skills rather than the other candidates, and checked against what your company may say. Hirezen does not send it. The write-ups here are a better starting point than memory.

Questions

What should interview feedback include?
For the hiring team: what the candidate did, under the question that drew it out; which skill each observation is about; a moment rather than an adjective; a recommendation of Strong No, No, Yes or Strong Yes; and, where something stayed unclear, the question the next round could ask to settle it. Leave out guesses about personality and anything the candidate did not say or do.
How do you write interview feedback for a candidate you would not hire?
The same way as for a hire: what was heard, under the question it was heard on. Say what the round was for and where the answers fell short of it, with the moment, and name what was good too, so the reader can tell a gap in the round’s core from a gap at its edges. Pick No or Strong No by whether the gap is in what the round exists to read.
What is a good example of interview feedback?
“Asked what a wrong cached answer costs at 02:15, before drawing anything, and used the answer for the rest of the section. Treated latency and cost as one goal.” It names the question, the moment, the skill and a gap, and anyone on the panel can agree or disagree with it. “Strong systems thinker” cannot be checked by anyone who was not in the room.
What if I cannot decide between yes and no?
Pick the side you lean to and write down what would settle it. Hirezen’s recommendation has four points and no middle, so a doubt becomes a question for the next interviewer rather than an “unsure” that the debrief has to work around. A mixed write-up is normal; a mixed recommendation leaves the decision to whoever reads it least closely.
How long should interview feedback be?
Long enough to hold the moments the recommendation rests on, which is usually four to six sentences for one round, plus the marks under each question. Length is not the problem with most feedback; the problem is feedback that states a conclusion with nothing under it, or that arrives two days later from memory.
Should interview feedback be shared with the candidate?
The write-ups on this page are written for the hiring team, and they say things a candidate should not read in that form: other rounds, other people’s marks, a lean. Feedback to a candidate is a separate, shorter message about the skills the role needs, checked against your company’s policy. Hirezen does not send feedback to candidates.

What a write-up holds, how the debrief reads every write-up side by side and what the decision records are on the after-the-interview page; what Yes, Not sure and No sound like for six skills is on the interview rubric; what a plan holds before the interview is on how plans are structured.

Write feedback like this the same day

Run any round in the library, mark each signal as you hear it, and AI drafts the written feedback from your marks and notes for you to edit. No bot joins the call and nothing is recorded.

Start freeBrowse interview plans After the interview