It was one of my last interviews of the day.
The candidate had a strong resume. They'd worked at a well-known company, explained their previous projects clearly, and came across as confident.
I explained the problem and asked, "Any questions before we begin?"
They smiled and said, "No, I think I got it."
Within seconds, they were typing.
For the next fifteen minutes, they barely spoke. No clarification. No discussion about the approach. No explanation of why they chose a particular data structure. Just code.
Eventually, they stopped.
"I think I misunderstood one of the requirements."
Unfortunately, they had.
The solution they had spent fifteen minutes building solved a different problem.
The rest of the interview became an attempt to recover.
After the interview ended, I wasn't thinking about the algorithm they chose.
I kept thinking about something much simpler.
A single question in the first two minutes could have saved the next fifteen.
That interview wasn't unusual.
I've seen similar situations more times than I can count.
Over the years, after conducting more than 100 engineering interviews, I've noticed that the candidates who receive offers aren't always the ones who write the smartest code.
They're usually the ones who avoid making simple mistakes.
Here are the patterns I keep seeing.
1. They don't rush to prove themselves
A lot of candidates think the interview starts when they begin writing code.
It doesn't.
It starts the moment the problem is introduced.
The best candidates don't treat clarifying questions as a sign of weakness. They ask about assumptions, constraints, edge cases, and expected inputs before discussing a solution.
Questions like:
- Can the input contain duplicates?
- How large can the input be?
- Are there any memory constraints?
- Should I optimize for readability or performance?
I've never thought less of a candidate because they asked good questions.
I've definitely seen interviews go badly because someone didn't.
2. They explain what they're thinking
One interview still stands out.
The candidate stayed completely silent for almost seven minutes.
They weren't typing.
They weren't asking questions.
They were simply staring at the screen.
As an interviewer, I had no idea what was happening.
Were they exploring multiple solutions?
Were they stuck?
Had they misunderstood the problem?
I couldn't tell.
A few interviews later, another candidate approached things very differently.
They kept saying things like,
"I'm considering a hash map because lookup time matters here."
Or,
"I have another idea, but I think it'll make the solution harder to explain."
Those small comments made a huge difference.
Interviewers can't see what's happening inside your head.
Help them understand your thinking.
3. They don't chase the perfect solution
I've seen candidates reject perfectly good approaches because they weren't optimal.
Twenty minutes later, they still hadn't written any code.
That almost never ends well.
The strongest candidates usually start with something correct.
Then they improve it.
That's how engineering works in the real world.
You build something that works.
Then you iterate.
4. They treat the interview like a discussion
The interviews I enjoy the most don't feel like interviews.
They feel like two engineers working through a problem together.
The candidate asks questions.
The interviewer asks questions.
Ideas are discussed.
Trade-offs are explored.
Sometimes a candidate will say,
"I considered another approach, but I don't think it's worth the additional complexity."
That tells me much more than another few lines of code ever will.
5. They think about edge cases without being reminded
One thing I always notice is who brings up edge cases first.
Some candidates only think about them after I ask.
Others naturally ask,
"What happens if the input is empty?"
"Can values repeat?"
"What if the input becomes very large?"
It isn't about checking every possible scenario.
It's about showing that this is how you naturally think.
That's a habit that carries over into production systems.
6. They understand what the interview is actually measuring
Many candidates think the interview is mostly about coding.
Especially for experienced engineers, that's only part of it.
I'm also paying attention to how they communicate.
How they make trade-offs.
How they respond when I challenge an assumption.
How they react when something doesn't go according to plan.
If I can picture someone debugging a production issue with the rest of the team at 2 AM, that's a very strong signal.
Good engineering is rarely about writing code in isolation.
7. They recover well
Nobody has a perfect interview.
I've interviewed brilliant engineers who made mistakes.
The difference wasn't the mistake itself.
It was how they responded.
Some candidates panic.
Some become defensive.
Some keep pushing an idea even after they know it isn't working.
The strongest candidates simply stop, acknowledge the issue, adjust their approach, and continue.
That's exactly what good engineers do every day.
Requirements change.
Designs evolve.
Systems fail.
Being able to recover is part of the job.
What surprised me the most
When I started interviewing, I assumed I'd remember the people who wrote brilliant code.
I don't.
I remember the candidate who asked thoughtful questions.
I remember the engineer who admitted they were stuck instead of pretending they had everything figured out.
I remember the person who changed direction after receiving feedback without letting their ego get in the way.
Those are the people I'd happily work with.
And more often than not, they're also the people who receive offers.
Final thoughts
If you're preparing for interviews, here's one suggestion.
Don't spend all your time solving more problems.
Spend some time practicing how you communicate your thinking.
Explain your decisions.
Talk about trade-offs.
Ask questions.
Interviewers aren't just evaluating whether your solution works.
They're trying to answer a much bigger question.
"Would I trust this person to solve difficult engineering problems with my team?"
In my experience, the answer to that question often starts becoming clear within the first fifteen minutes.
