A Quick Tip for Anyone Going Into a Technical Interview

I’ve written before on this blog about doing technical interviews for Lemon.io — a community of developers that works kind of like a middleman, matching devs with projects. I think I have at least one article here about the interview side of things already, but after some recent experiences I figured I’d start dropping the occasional tip whenever something worth sharing comes up.

Here’s today’s tip, and it’s for anyone who’s going to be interviewed for a technical role at some point.

I recently interviewed a developer who’s actually been in the industry longer than I have — more years of experience, by the numbers at least. And throughout the interview, he kept trying, in one way or another, to show me he had more experience than me.

The clearest example: whenever I started asking a question, he’d cut me off before I even finished it.

“Stop, stop — can I interrupt? I know where you’re going with this, and the answer is X.”

Except “X” was usually one word. Two, tops. He’d answer before I’d even finished asking, and what he actually gave me was a buzzword, not an answer.

Sure, that can make it look like you already understand where the question is going. But first of all, it’s just annoying to cut someone off before they finish a sentence. Second, and more importantly: if I ask you about something, I don’t want to hear a single term and have you assume I’ll fill in the blanks myself. I want to see that you can actually explain it.

If I ask you how you’d solve an N+1 problem, I don’t want you to just say “eager loading” and stop there, expecting me to nod and assume you know what it means. I want you to walk me through it — what actually happens, how you’d fix it, what the steps look like.

Honestly, this particular case didn’t really affect me. But it easily could have gone differently — what if the person interviewing you has been in the industry for less time than you have? That doesn’t make you superior, and it doesn’t mean you need to talk down to the person interviewing you.

You might run into someone who takes it personally, who walks away thinking “this guy’s a show-off who just wants to prove what he knows,” and decides not to move you forward. In this case, that’s not what happened. I think he probably moved forward, assuming the team followed my feedback — I included both his strengths and the areas where I thought he could improve, because there’s always something to improve with every candidate.

But here’s the actual point: you can easily come across to someone as a show-off who just wants to prove what he knows, someone who fires off terms without explaining anything, without giving any real detail. And that can genuinely hurt your chances in an interview.

We should remember that in an interview, you’ve got two people talking as equals. Nobody should walk in assuming they’re above the other person, and there shouldn’t be any prejudice going either way. You’re just talking developer to developer — because even when I’m the one asking the questions, I’m still a developer too.

I want to see what you actually know, without the flex. Or honestly — if you’re going to show off, at least back it up and explain in detail. Don’t just skim the surface with quick answers meant to look impressive, and then never actually go deeper.

Maybe this tip helps somebody out there, especially if you’ve been in the industry for a while and you’ve got an interview coming up. I’ll be back with more posts on this topic — there’s a lot to say, including about using AI in interviews, which I’ll get into another time.

Thanks for reading. If you’ve got thoughts on any of this, I’ll be in the comments.