My Take as an Interviewer

Over the past few years, I've had the opportunity to sit on both sides of the interview table.

At my previous company, I conducted technical interviews as an Individual Contributor. Today, as a Team Lead, my role is much more managerial. Somewhere along that journey, my perspective on interviews changed completely.

Ironically, becoming an interviewer taught me more about interviews than being interviewed ever did.

What I Thought Interviews Were

Like many engineers, I used to think interviews were about proving that you knew everything.

Every question felt like a test. Every mistake felt like it could cost me the job. If I couldn't answer something immediately, I assumed the interview was over.

Looking back, I realize how much pressure I was putting on myself.

Today, I see interviews very differently.

They're not about finding someone who has every answer. They're about understanding how someone approaches problems, communicates, and whether they'd be a good fit for the team.

Knowledge matters, of course. But knowledge alone rarely tells the whole story.

The Biggest Misconception

One thing I hear often is that interviewers expect candidates to know everything.

We don't.

In fact, one of the strongest answers a candidate can give is:

"I don't remember."

That answer is infinitely better than trying to invent an explanation.

Experienced interviewers naturally ask follow-up questions. If someone genuinely understands a topic, the conversation flows. If they're relying on buzzwords or trying to bluff their way through, it usually becomes obvious very quickly.

You don't lose credibility by admitting you don't know something.

You lose credibility by pretending that you do.

Not Every Mistake Matters

Another misconception I had as a candidate was that every mistake was catastrophic.

I don't believe that anymore.

Forgetting syntax? That's fine.

Not remembering some theoretical concept? Also fine.

We all use documentation. We all forget things. Software engineering isn't a memory competition.

What concerns me much more is when someone struggles with the fundamentals.

If you're interviewing for a JavaScript role and can't write a simple function or don't know how to dynamically access an object's property, that's different. Those aren't obscure details—they're part of the foundation.

The goal isn't perfection.

The goal is demonstrating that you have the fundamentals and can build on them.

Honesty Goes Further Than Confidence

If there's one piece of advice I'd give every candidate, it's simple:

Be honest.

I've seen candidates throw around buzzwords that don't really fit the conversation, hoping they'll sound experienced.

The problem isn't the buzzwords themselves.

The problem is that they rarely survive the next question.

Real experience is difficult to fake because it comes with context. You can explain why you made a decision, what went wrong, what trade-offs you considered, and what you learned afterwards.

That's much more convincing than dropping terms like "microservices", "Clean Architecture", or "SOLID" without being able to explain how you've actually applied them.

We Want You to Succeed

Something candidates often don't realize is that interviewers generally want them to do well.

I certainly do.

When someone is obviously nervous, I try to slow things down. I'll spend a few minutes chatting before jumping into technical questions or simply reduce the pace of the interview.

The goal isn't to make someone fail.

It's to understand who they really are.

A candidate who is overwhelmed by nerves isn't showing their best self, and that's not helpful for either side.

The Interview That Changed My Perspective

One interview has stayed with me.

We were hiring for a JavaScript position.

The candidate had almost no JavaScript experience.

Following the interview script would have meant ending the technical assessment almost immediately.

Instead, both interviewers agreed to do something different.

We told the candidate to use whichever programming language they were most comfortable with.

What happened next completely changed how I think about interviews.

The candidate demonstrated excellent problem-solving skills, a strong engineering mindset, and a structured way of thinking. The lack of JavaScript knowledge suddenly felt like a much smaller problem than we had initially assumed.

We hired them.

It turned out to be a great hiring decision.

That interview reminded me that technologies can be learned. Engineering mindset is much harder to teach.

Since then, I've become much more comfortable stepping outside the interview script when I believe it gives us a better understanding of the person sitting across the table.

Remember That You're Interviewing Too

One lesson I wish I'd understood earlier is that interviews aren't one-sided.

As a candidate, you're evaluating the company just as much as they're evaluating you.

Pay attention.

Do the interviewers interrupt each other?

Do they listen to your answers?

Do they seem respectful?

Do they appear to enjoy working together?

Technical questions matter.

The people you'll spend every day with matter even more.

A great salary can't compensate for joining the wrong team.

Final Thoughts

Interviews are imperfect.

A one-hour conversation can never fully measure someone's engineering ability or everything they've learned throughout their career.

But they can reveal something equally important: how someone thinks, how they communicate, how they approach problems, and what it might be like to work with them.

If I could give one piece of advice to my younger self before my first technical interview, it would be this:

Ask questions.

Be yourself.

Stick to what you're genuinely good at.

And remember that you're not just trying to get the job.

You're also deciding whether it's a team you want to be part of.

Becoming an interviewer changed far more about how I think about interviews than becoming a better engineer ever did. And I think that's because, from the other side of the table, you realize something simple:

The interview isn't about finding someone who knows everything.

It's about finding someone you'd enjoy building software with.