Is Communication Not Technical Skill Stopping You From Interviewing?

YOU'RE a technical expert but interviews feel so daunting.

The last time you applied you drilled leetcode, prepared to talk about a side-project, gathered lots of stories about great things you did at your current job.

You know your stack. But putting that across under pressure is a different problem entirely.

Interviewers are probably using this dreaded phrase, "talk through your thinking."

In a high stress situation like live-coding, talking about what you are doing is pretty difficult. At least, I find it to be.

You are spending too much time thinking about how to say it, not what to say. And that is stopping you from showing your technical value.

It's unfair, like a lot of things in interviews. But employers can be picky.

Personally I prepare and rehearse interview answers. I have also interviewed in a second language to an offer and that was much harder to prepare, so I understand the pressure.

One of the problems is that, while there are themes of what we are normally asked, it's not possible to know exactly what the question will be.

This gap means there is always something we don't know, which can create anxiety. But the trick is to be able to move the interview question to our story.

The easiest thing to do is to prepare a few flexible answers. Those that can cover STAR answers based on a couple of themes: what went well, what went badly but you learnt from, and so on.

The best way to prep this is to simply look at your CV, and create a story from each point you make about what you achieved at the job. It's also worth looking at the job description and seeing how your experience connects with it.

If you have that skill, great. You can use the language in the description and connect it to your story. If there is a gap, prepare a bridging phrase. Something that says "while I don't X, I do Y."

(If you aren't familiar with STAR, the below example shows how it works. It's about outlining a situation, task, action, and result. An LLM is a great starting point for writing them.)

Let's look at an example:

In the job description: "Experience mentoring juniors as direct reports" for a senior role. But maybe this is your first senior role.

This kind of requirement is usually a nice to have rather than a deal-breaker.

If you don't have this, how can you prepare a great answer?

Think about what you do have. You're very active in code reviews, for example. Perhaps you would write something like this:

• Situation: During a routine code review, I noticed a junior developer had written a database query inside a loop, something that would work fine in testing but would cause serious performance problems in production at scale.
• Task: I needed to flag the issue in a way that was clear and educational, not just a rejection of their work.
• Action: Instead of simply commenting "this will cause an N+1 problem," I left a comment explaining what would happen at scale, linked a short article on the N+1 problem, and suggested we pair for 20 minutes to look at it together. In that session I walked through how to move the query outside the loop and why the database cares about that.
• Result: They fixed it confidently and independently caught a similar issue themselves two weeks later.

Now this is something you can use with a bridging phrase:

• "While I don't have any formal reports at my current role, I am an active participant in code review."
• "I haven't held a senior title yet, but mentoring has been a natural part of how I work with the team."
• "Formal line management hasn't been part of my role, but I've taken ownership of bringing junior developers up to speed on our codebase."
• "I don't have direct reports, but I'm often the person juniors come to before they open a PR or ask a question in standup."

This means you can give a proper answer like this:

"While I don't have formal direct reports yet, mentoring has been a natural part of how I work. Once I was reviewing a PR from a junior on the team and spotted a database query inside a loop. It would have passed testing fine but would have been a real problem in production.

I didn't want to just reject the PR so I left a detailed comment explaining what would happen at scale, linked some reading on it, and suggested we pair for twenty minutes. We walked through the fix together and I explained the reasoning behind it rather than just showing them what to change.

Two weeks later they caught a similar issue themselves in someone else's review. That's the outcome I care about, not just fixing the problem but making sure they understand it."

Your answers should feel like a part of you. Reciting a script from memory is not good communication. Learn the ideas, not the words. Being comfortable with the idea is what creates confidence.

The goal is to speak confidently about what you did, without getting stuck on how to say it.

Even a couple of good, practised interview stories can make a big difference. And if you're smart about what you pick, you can almost always use the same ones.

If you are interested in a more structured approach to feeling confident in software interviews, I offer a review to see if you're ready to interview and secure a role.

We will talk about any difficulties, practice some real answers based on your CV, and create a plan to get you to your dream job.

I've helped dozens of professionals improve their interview skills across the tech industry, and I've also been in awful technical interviews myself so I understand the pain.

If that sounds useful, book here or have a 20 min chat if you're not sure what's right.

Let's Talk