I’ve been on both sides of the interview table. I’ve been the nervous candidate who went home and replayed every answer in their head for three days. And I’ve been the interviewer trying to fill out a scorecard while making small talk about weekend plans.
Being on the other side changed how I think about interviews completely. Because what interviewers are evaluating is NOT what most candidates think.
It’s Not About the Right Answer
I know, I know. You’ve heard this before. But I mean it in a very specific way.
When I give a coding problem and someone gets the optimal solution in 15 minutes — that’s fine. Good, even. But it tells me almost nothing about how they’d be as a colleague.
When someone struggles, thinks out loud, asks good questions, considers tradeoffs, and arrives at a working-but-not-perfect solution while explaining their reasoning? That tells me EVERYTHING.
The solution is just the artifact. The process is the interview.
The Four Things That Actually Matter
Every company structures their scorecards differently, but after talking to dozens of interviewers across different companies, these four things come up everywhere:
1. How You Think Through Problems
I want to see how your brain works. When I give you a problem you haven’t seen before, do you:
- Ask questions to clarify the constraints?
- Break it into smaller pieces?
- Consider multiple approaches before committing?
- Recognize when you’re going down a wrong path?
A candidate who says “Let me think about this… my first instinct is brute force, which would be O(n²). But if I sort first, I could probably do this in O(n log n). Let me think about whether there’s a linear approach…” — that person just showed me more than someone who silently writes the optimal solution.
2. How You Communicate
This one surprises people. Communication is a massive part of every technical role, but candidates treat interviews like an exam — head down, mouth shut, write the answer.
What I’m looking for:
- Can you explain your thinking clearly?
- Do you adjust your explanation when I look confused?
- Can you describe technical concepts without unnecessary jargon?
- Do you listen to hints when I drop them?
That last one is important. When an interviewer says “What if the input were sorted?” — that’s not idle curiosity. That’s a hint. Candidates who pick up on hints and run with them score way higher than candidates who bulldoze past them.
3. How You Handle Being Stuck
Everyone gets stuck. The question is what you do next.
Red flags: Going silent for two minutes. Guessing randomly. Getting visibly frustrated. Saying “I don’t know” and stopping.
Green flags: Thinking out loud about what’s blocking you. Going back to what you do know. Asking “Can I talk through my reasoning?” Trying a simpler version of the problem first.
I’ve given “hire” scores to candidates who didn’t finish the problem because how they handled being stuck showed me exactly the kind of engineer they are — the kind who works through hard things methodically instead of panicking.
4. Whether I’d Want to Work With You
This sounds vague, but it’s real. After an hour-long interview, I have to answer: “Would I want this person on my team?”
That doesn’t mean you need to be charming or funny. It means:
- Are you pleasant to talk to?
- Do you listen, or just wait for your turn to speak?
- Are you honest about what you don’t know?
- Do you give credit to your team when telling stories?
- Would pairing with you on a hard problem be enjoyable or painful?
I’ve passed on technically strong candidates because they were condescending, dismissive of questions, or clearly BS-ing about their experience. And I’ve championed candidates who had gaps in their knowledge but were genuinely curious, collaborative, and self-aware.
Things Interviewers Don’t Care About (As Much As You Think)
Your Exact Tech Stack
“But the job posting says React and I only know Vue.”
If you’re a strong engineer who knows Vue, you’ll learn React. Every interviewer knows this. Framework knowledge is the easiest thing to acquire. Fundamentals, problem-solving ability, and communication skills are not.
Obviously, if the job requires 5 years of Kubernetes experience and you’ve never used containers, that’s different. But for most skill mismatches, you’re filtering yourself out before they would.
Perfect Syntax
In a whiteboard or coding interview, nobody cares if you forget whether it’s array.length or array.size(). We care about the algorithm, the structure, the approach. If you write pseudocode and explain it well, that’s often better than syntactically perfect code with no explanation.
Your Pedigree
I’ve interviewed people from top CS programs who couldn’t think through basic problems. And I’ve interviewed self-taught developers who blew me away. Where you learned doesn’t determine what you know.
Your resume gets you the interview. Your performance in the interview gets you the job. They’re separate phases.
Nervousness
We can tell you’re nervous. It’s fine. We’re not scoring you on confidence. If you stammer, pause, or need to restart an answer — that’s normal. Just keep going.
In fact, I trust nervous candidates MORE than overly polished ones. Nerves mean you care. A rehearsed, smooth performance sometimes means you’re telling me what I want to hear instead of what’s actually true.
How to Use This Knowledge
Knowing what interviewers look for changes how you prepare.
Stop: Memorizing solutions to 500 LeetCode problems. Start: Practicing explaining your approach out loud while solving problems.
Stop: Trying to be perfect. Start: Practicing recovery — intentionally getting stuck and talking through it.
Stop: Hiding what you don’t know. Start: Being honest and curious. “I haven’t worked with that technology, but here’s how I’d approach learning it” is a great answer.
Stop: Treating the interview as a performance. Start: Treating it as a conversation between two people trying to figure out if working together makes sense.
The Uncomfortable Truth
Here’s something I wish someone had told me earlier: sometimes you do everything right and still don’t get the job.
Maybe they had an internal candidate. Maybe the role changed. Maybe the interviewer was having a terrible day. Maybe there were three great candidates and they could only hire one.
Rejection after a good interview doesn’t mean you failed. It means the specific stars didn’t align. Keep going.
Related: Now that you know what interviewers look for, learn how to structure your answers with the STAR method and handle the dreaded “Tell me about yourself” opener.