You're a technical expert but interviews feel so daunting. Especially for international companies where you need English. 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 this is all in your native tongue.
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). If you are being asked to do this in English and you are nervous that is normal. But the problem is if you can't do it, your 'communication skills aren't good enough' to get the job. You don't get through to the next round. Maybe you don't even want to apply. You are spending too much time thinking about how to say, 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 even in English. I have also interviewed in French to an offer and that was much, much harder to prepare so I understand. 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 that 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 answer STAR answers based on a couple of themes: what went well, what went badly but you learnt from etc. 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 have 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, perfect! 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 and honestly, 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 we 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."
Now, even in English, I have my answers well-rehearsed because I've worked with a coach who would spring questions on me. These are your stories so they should feel like a part of you. If speaking English doesn't fully feel like your natural personality it can create a barrier. The best thing to do is simply practice and record these answers. Listen back to them (which I know a lot of people hate) and look for where you are hesitating or using filler.
Don't worry about a perfect accent, or 100% accuracy to the script. Look for where the idea in the answer isn't coming naturally. Reciting a script from memory is not good communication, so make sure to just learn the ideas. 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'd find it useful to practice some of this with real feedback on your own CV stories, feel free to reach out.
Top comments (0)