He solved every algorithm question perfectly. But I gave him a no-hire.

This isn't clickbait. This is a real interview I conducted last week—and it wasn't the first time something like this happened.

The "Perfect" Candidate

Let me tell you about his performance first.

Algorithm questions? Two medium, one hard—all AC'd. Time? He finished in 30 minutes of a 45-minute interview. Code style? Clean variable names, proper edge case handling, and he even proactively optimized the time complexity.

"This can be optimized to O(n) with a hash table," he said while typing, "but space complexity becomes O(n). If memory is a concern, two pointers would be better."

I thought: This kid is a lock.

Then I asked him a system design question.

But I Noticed Something Wrong

"Design a URL shortener," I said. "You can start by asking some clarifying questions."

He didn't ask any questions. He just started drawing the architecture diagram.

"I just want to confirm," I interrupted, "don't you want to know about the user scale?"

"No need," he said without looking up. "I know how to do this."

I frowned but didn't say anything. I kept watching his design.

His solution was correct—technically speaking. But throughout the entire session, he never asked a single question:

What's the daily active user count?
Do shortened URLs need to be permanent?
What are the latency requirements?
Do we need to support custom short URLs?

The answers to these questions would completely change his design. But he didn't care.

What made me even more uncomfortable was when I tried to give him some hints:

"Actually, in this scenario," I said, "users might—"

"I know," he cut me off. "I've seen this question before."

Then he continued with his solution.

At that moment, I decided: No hire.

What Interviewers Actually Care About

Let me be clear: Technical ability is just the threshold, not the deciding factor.

At big tech companies, anyone who passes resume screening has decent technical skills. Grind some LeetCode, memorize some system design patterns—most people can do that.

But work isn't about one person writing code alone.

You need to communicate requirements with product managers, discuss solutions with designers, accept feedback during code reviews, and collaborate with the team when projects are delayed.

Someone who doesn't communicate, doesn't listen, and only cares about showing off is a disaster for any team.

I'd rather hire someone with average technical skills who's willing to learn and good at communicating, than someone technically strong but arrogant. The former can be developed; the latter will drag down the entire team.

The Candidate I Did Hire

Let me contrast this with another candidate I hired last week.

Her algorithm performance was average—she passed the first one, had a small bug in the second, and only wrote out her approach for the third.

But during system design, she asked me a ton of questions:

"Is this service for internal use or external?"
"What's the expected QPS?"
"What are the availability requirements? 99.9% or 99.99%?"
"Is there a budget constraint?"

Every question made me think: She gets it. She understands that real-world system design isn't about memorizing templates—it's about making tradeoffs based on constraints.

When I said "Let's assume it's a startup with a limited budget," she immediately adjusted her approach:

"Then we probably don't need multiple data centers. Single-region with multiple AZs should be enough. For the database, we could start with a single MySQL instance plus a caching layer, then consider sharding when traffic grows."

She also said things like "I'm not sure if this is optimal—what do you think?"—words that "perfect" candidate would never say.

In the end, I gave her a hire. My colleague did too.

3 Tips for Candidates

Treat Interviews as Collaboration, Not Exams

Many people treat interviews like exams: question → answer → score. Wrong.

An interview simulates a work scenario. You get a requirement, discuss solutions with colleagues, weigh tradeoffs, and implement. The interviewer is your "colleague."

So:

Ask questions. If you don't understand, ask. If you're unsure, confirm. This shows communication skills, not "ignorance."
Explain your thinking. Don't just write code in silence. Talk through your approach so the interviewer knows what you're thinking.
Accept feedback. If the interviewer gives you a hint, seriously consider it. Don't rush to argue.

Technical Skills Are Just the Foundation—Attitude Is Everything

I've seen too many "technically strong but rejected" candidates. The reasons are usually similar:

Interrupting the interviewer
Answering before hearing the full question
Dismissing hints
Not testing code after finishing

These are attitude problems, not ability problems.

Conversely, I've seen many "technically average but hired" candidates. Their common traits:

Humble and eager to learn
Good at communicating
Don't panic when facing difficulties
Willing to admit mistakes

Technical skills can be learned; attitude is hard to change. That's why attitude matters more.

Prepare "Soft Skills" Just Like You Prepare for Algorithms

Many people grind hundreds of LeetCode problems but never practice how to communicate with interviewers.

My suggestions:

Do mock interviews with friends. Have them play the interviewer, intentionally giving you some interruptions or hints, and see how you respond.
Record your responses. Watch the playback to see if you're just talking to yourself, or if you're giving the interviewer a chance to speak.
Practice saying "I'm not sure." Many candidates are afraid to say this, thinking it makes them look weak. Actually, the opposite is true—being willing to admit uncertainty is a sign of confidence.

FAQ

Q: Does technical skill not matter? Can I pass with just a good attitude?

Of course not. Technical skills are the threshold; attitude is the deciding factor.

Simply put:

Weak technical skills + good attitude = might pass (depends on the role)
Strong technical skills + bad attitude = almost never passes
Strong technical skills + good attitude = definite pass

So prepare for both, but don't only prepare for technical aspects.

Q: Are interviewer hints traps? Should I accept them?

99% of the time, hints are genuinely meant to help you.

Interviewers aren't your enemies. Their goal is to find suitable candidates, not to trick you. If they give you a hint, it's usually because:

You're going off track and they want to bring you back
Time is running out and they want to help you speed up
They want to see if you can accept feedback

So, seriously consider every hint. Of course, if you have a different idea, you can say "I understand what you mean, but my current thinking is... what do you think?"—this is discussion, not rejection.

Q: What should I do if I get interrupted?

If the interviewer interrupts you, stop and listen to what they have to say. Then:

If they're right, acknowledge it and adjust
If you want to explain, say "I understand your point. Can I explain why I'm doing it this way..."

Don't:

Talk over them
Show impatience
Ignore their input and keep talking

Remember, an interview is collaboration, not a debate.

Closing Thoughts

What happened to that "perfect" candidate?

I don't know. Maybe he went to another company, maybe he's still grinding LeetCode.

But I hope he sees this article someday. Not because I'm "teaching him a lesson," but because I genuinely believe: He was so close to an offer—and it wasn't technical skills he was missing, it was mindset.

If he could learn to listen, to communicate, to treat interviews as collaboration rather than exams, he would definitely land his dream offer.

Practice Real Interview Scenarios

Reading articles can only take you so far. Real improvement comes from practice.

Interview AiBox provides AI-powered mock interviews—not just algorithm questions, but system design, behavioral interviews, and communication skills. The AI gives you feedback like a real interviewer, including your communication style, attitude, and those subtle details you might not notice.

Don't wait until a real interview to discover your weaknesses. Start practicing now.

Start Free Practice →

Interview AiBoxInterview AiBox — Interview Copilot