I've filled out hundreds of candidate evaluation forms. Here's the exact structure most companies use and what actually gets written in each section.
The Rating Scale
Most companies use some version of this:
STRONG NO HIRE → NO HIRE → LEAN NO HIRE → LEAN HIRE → HIRE → STRONG HIRE
Strong Hire happens maybe 10-15% of the time. It means the interviewer would be personally disappointed if you didn't get an offer.
The rest of the form determines which rating you get.
Section 1: Overall Impression
Written first. Carries the most weight. Never about technical knowledge.
Strong Hire version:
"Well-prepared, communicated clearly throughout, demonstrated
strong ownership of the problem. Asked clarifying questions
before diving in. Approached the solution methodically."
No Hire version:
"Jumped into coding immediately without discussing approach.
Required significant guidance to make progress. Struggled
to articulate reasoning when asked about decisions."
Notice: zero mentions of frameworks, APIs, or syntax.
Section 2: Technical Assessment
This is NOT about trivia. Nobody writes "didn't know the arguments to Array.prototype.reduce."
What actually gets noted:
POSITIVE:
"Immediately identified this as an async problem and discussed
race condition risks before writing any code."
"Used TypeScript generics confidently and explained type
constraints clearly."
NEGATIVE:
"Solution worked but used nested callbacks instead of
async/await. Unfamiliar with modern patterns."
"Wrote working code but did not consider edge cases
until prompted."
The evaluation is about level of thinking. Not facts you memorized.
Section 3: Problem Solving
This is usually the longest section. Interviewers write it like a story.
Hire story:
"Started by restating the problem. Discussed two approaches
with tradeoffs. Chose hash map for better time complexity.
Implemented cleanly. Found own bug during testing."
No Hire story:
"Started coding immediately. Hit a wall after 5 minutes.
Stared at screen silently. I offered a hint. Candidate
restarted but got confused about loop conditions.
Partial solution with significant help."
Here's the critical insight. I once wrote this about a candidate who didn't finish:
"Did not complete the solution within time limit, but
demonstrated excellent methodology. Broke the problem
into sub-problems, identified the key challenge, and
was making clear progress. Recommend proceed."
Same week, about a candidate who did finish:
"Produced correct code but could not explain how it
worked. Appeared to have memorized the pattern. When I
modified the problem slightly, candidate could not adapt.
Concerns about depth of understanding."
The first candidate got hired. The second didn't.
Section 4: Communication
Gets its own section because it matters that much.
POSITIVE:
"Thought out loud throughout. I always knew what they
were thinking and why."
NEGATIVE:
"Mostly silent during coding. When asked what they were
thinking, responses were vague."
ALSO NEGATIVE:
"Answers were extremely long and wandering. Simple
questions received five-minute responses."
Being too verbose is flagged just as often as being too quiet.
Section 5: Hints and Obstacles
Asking for a hint is NOT a negative. Your response to it is everything.
HIRE:
"I suggested considering a hash map. Candidate immediately
understood the implication and ran with it."
NO HIRE:
"I suggested the same approach three different ways
before the candidate understood what I was pointing toward."
Section 6: Questions You Asked
Yes, this gets documented.
POSITIVE:
"Asked about team's development process, current technical
challenges, and how success is measured."
NEGATIVE:
"Had no questions. When prompted, asked about vacation days."
The Decoder Ring
Phrases that mean rejection:
"Would benefit from more experience"
→ Not ready for this level
"Showed enthusiasm for the role" (without technical praise)
→ Nothing technical to highlight
"Creative but unconventional approach"
→ Wrong answer, said politely
"Strong cultural fit" (alone)
→ We liked them but no
Phrases that mean offer:
"I would want this person on my team"
→ Personal advocacy. Strongest signal.
"Approach was better than what I had in mind"
→ You impressed the interviewer. Rare.
"Identified an edge case I hadn't considered"
→ Hiring committee loves this.
What You Can Control
Think out loud. Silent coding gets documented negatively every single time. The interviewer cannot write about thinking they cannot see.
Ask clarifying questions first. Gets documented positively every single time. Zero exceptions in hundreds of evaluations I've read.
Discuss tradeoffs explicitly. Say: "I'm choosing a hash map for O(1) lookups. Could sort and binary search for less space, but time matters more here." This gives the interviewer material for a glowing evaluation.
Handle mistakes calmly. Say: "I have an off-by-one error. Let me trace through with a small example." Gets written as: "Identified and fixed own bug through systematic testing."
Prepare specific failure stories. Honest failure with lessons learned gets better notes than "I can't think of any mistakes." Every time.
Ask real questions at the end. About the work. The team. The challenges. Not about perks.
The evaluation form is not a mystery anymore.
Now you know exactly what's being written.
Make sure it says Strong Hire.
Full deep-dive with more evaluation examples and hiring committee insights: jsgurujobs.com
Top comments (0)