Quick Answer
The 10 English mistakes that most often cost non-native speakers a job offer are: over-hedging answers, using present tense for past achievements, vague impact language, missing the STAR structure in behavioural answers, over-explaining context, under-claiming ownership, filler phrases that signal uncertainty, literal translation of idioms, answering a different question than the one asked, and ending answers without a clear conclusion. Each one is fixable with a specific language adjustment — not a fluency overhaul.
What interviewers are actually scoring (the hidden rubric)
The distinction most articles skip: interviewers are not grading your English. They are using your English as a proxy for something else — clarity of thought, ownership of your work, and confidence in your own judgement. A grammatical mistake rarely kills an offer. A pattern of language that makes you sound uncertain, vague, or junior almost always does.
This matters because the fixes are different. If the problem were grammar, you would need more study. Because the problem is signal, you need to change specific habits — most of which take a day to learn and a week to automate. The 10 mistakes below are ranked by how often they appear and how badly they damage the signal, not by how 'wrong' they are linguistically.
| What the interviewer hears | What they actually conclude | The real problem |
|---|---|---|
| Hedged, qualified answers | Candidate lacks conviction or depth | Over-hedging (Mistake 1) |
| 'We built...' 'We decided...' | Can't tell what this person actually did | We vs I (Mistake 6) |
| 'It was improved by some amount' | No real ownership of outcomes | Vague impact (Mistake 3) |
| Long story, no clear point | Rambling — would struggle to communicate with stakeholders | Missing structure (Mistake 4) |
| Answer trails off mid-thought | Unsure of their own conclusion | No conclusion (Mistake 10) |
| Filler before every answer | Nervous, unprepared, or stalling | Filler phrases (Mistake 7) |
None of these conclusions are about language ability. They are about perceived seniority, ownership, and confidence.
Before you read the mistakes, bookmark Mockly's guide to the STAR interview framework — it underpins four of the ten fixes below, and having it open while you practise will speed up the work.
Mistake 1: Over-hedging every claim
Insight
Over-hedging means softening every statement with 'maybe', 'I think', 'kind of', or 'possibly' — even when you are certain. To a native-English interviewer, this pattern reads as self-doubt, not politeness.
In many languages and cultures, hedging is a sign of intellectual humility. In a US or UK interview, constant hedging is interpreted as uncertainty about your own work. The interviewer's internal reaction is: 'Does this person actually know what they did, or are they guessing?' That reaction is unfair — but it is real.
| Over-hedged (what you say) | Direct (what to say instead) |
|---|---|
| I think I was kind of responsible for the backend. | I owned the backend — the API layer and the data pipeline. |
| Maybe we improved latency by around 30% or so. | We reduced latency by 32%. |
| I guess my approach was to refactor the service. | I refactored the service to separate concerns and make it testable. |
| It was possibly one of the bigger projects I've worked on. | It was the largest migration I've led — twelve services, six months. |
Reserve hedging for genuine uncertainty: 'I'm not certain of the exact figure, but it was in the range of 30%.' That is honest. Hedging things you know is a habit, not honesty.
Interview tip
Self-check: record a 2-minute answer to 'Tell me about a project you're proud of.' Count how many times you say 'I think', 'maybe', 'kind of', 'sort of', or 'I guess.' More than two in two minutes is a pattern to fix.
Mistake 2: Using present tense for past achievements
Insight
Describing past work in the present tense ('I build the system', 'we deploy every week') makes it sound like you are describing a general process, not a specific achievement — which is exactly what interviewers are asking for.
This is one of the most common interference patterns for speakers of languages where verb tense is less rigid or where the present is used for habitual past actions. The problem is not grammar — interviewers understand you. The problem is that present tense sounds like you are describing a job description rather than a concrete accomplishment. Behavioural and situational questions specifically want the past: a real event, a specific decision, a measurable result.
| Present tense (sounds like a process) | Past tense (sounds like an achievement) |
|---|---|
| I build a microservices architecture for the payments team. | I built a microservices architecture for the payments team — that was in 2022 at my previous company. |
| We deploy to production three times a week. | At that company, we were deploying to production three times a week — I introduced the CI pipeline that made that possible. |
| I work with cross-functional teams to align on requirements. | In that role, I worked directly with product and design to define the API contract before any code was written. |
Use simple past (built, led, reduced, introduced) for completed work. Use present perfect (I have built, I have led) to connect past experience to now. Use present simple only for your current role's ongoing responsibilities.
Interview tip
The guide to verb tenses for your career timeline maps exactly which tense to use for which part of your story — past role, current role, and future ambition — and is worth reading before your next mock answer.
Mistake 3: Vague impact language
Insight
Saying your work 'improved performance', 'helped the team', or 'made things faster' tells an interviewer nothing they can evaluate. Vague impact language is one of the clearest signals that a candidate is describing a task, not an achievement.
This is not a language problem — it is a framing problem that shows up more often in non-native speakers because the instinct is to understate. In US and UK tech interviews, quantifying impact is not boasting; it is the expected format. Interviewers at mid-to-senior level are specifically listening for numbers, because numbers are what distinguishes 'I touched this system' from 'I improved this system.'
| Vague | Specific |
|---|---|
| It improved performance significantly. | It reduced p99 latency from 800ms to 120ms. |
| We saved a lot of time in the deployment process. | We cut deployment time from 45 minutes to 8 minutes — that freed up roughly two hours per engineer per week. |
| The refactor helped the team move faster. | After the refactor, we went from one release per sprint to three. That was the direct result of removing the shared mutable state. |
| I contributed to a high-impact project. | I was the sole backend engineer on a feature that processed $2M in transactions in its first month. |
If you genuinely do not have a number, use a relative comparison: 'roughly half the previous time', 'the largest dataset the team had processed', 'the first time this had been done without a maintenance window.'
Watch Out
Do not invent numbers. If you are unsure of the exact figure, say so: 'I don't have the exact number in front of me, but it was in the range of 30–40% reduction.' Approximate honesty is far better than false precision — and interviewers can tell the difference.
Mistake 4: Missing structure in behavioural answers
Insight
An unstructured behavioural answer — one that jumps between context, action, and result without a clear sequence — forces the interviewer to do the work of extracting your point. Most do not bother; they move on with a low score.
Behavioural questions ('Tell me about a time you disagreed with a colleague', 'Describe a situation where you had to deliver under pressure') are the hardest part of an interview for many non-native speakers — not because the experiences are missing, but because the expected format is invisible. US and UK interviewers are trained to listen for a specific shape: Situation → Task → Action → Result. When that shape is absent, the answer feels incomplete even if the content is excellent.
The STAR shape in practice — 'Tell me about a time you had to push back on a product decision'
- SITUATION (5–10 seconds): 'This was at my previous company, about a year into my role as senior engineer. The product team wanted to ship a feature that required a schema change on a table with 50 million rows.'
- TASK (5 seconds): 'My job was to flag the risk and propose an alternative before we committed to the sprint.'
- ACTION (20–30 seconds): 'I ran a quick proof-of-concept showing the migration would lock the table for roughly 40 minutes in production. I then proposed a shadow-table approach — we'd write to both tables for two weeks and cut over without any downtime. I put together a one-page doc and walked the PM through it in a 15-minute call.'
- RESULT (10 seconds): 'They accepted the approach. We shipped on time, zero downtime, and the PM later told me it changed how they thought about involving engineering earlier in planning.'
Interview tip
The most common structural error is spending 80% of the answer on Situation and Task, then rushing through Action and Result. Interviewers score Action and Result — that is where your seniority shows. Aim for: 15% Situation, 5% Task, 60% Action, 20% Result.
Mistake 5: Over-explaining context before getting to the point
Insight
Starting every answer with two minutes of background — the company, the team structure, the technology stack, the business model — before reaching the actual point is one of the most reliable ways to lose an interviewer's attention.
This habit often comes from a genuine desire to be precise and to give the interviewer enough information to understand the answer. The effect is the opposite: interviewers in US and UK tech interviews are accustomed to answers that lead with the conclusion. When the conclusion is buried at the end of a long setup, they lose track of it — or they conclude the candidate cannot prioritise information.
Over-contextualised (common pattern)
'So, the company I worked at was a fintech startup, about 80 people, we were using a microservices architecture with Kubernetes on GCP, and the team was about six engineers split across two squads, and we had a product manager who was quite new, and the context was that we were trying to launch in a new market, and there were some regulatory requirements that we hadn't fully mapped out yet, and so the situation was...'
Lead with the point (what to do instead)
'At my previous company, I flagged a compliance gap three weeks before a market launch — and it nearly got the launch pulled. Here is what happened: [then the context, briefly].' The interviewer now knows where the story is going. They are listening for how you handled it, not waiting to find out if there is a story at all.
Interview tip
One sentence of context is almost always enough. 'This was at a 200-person fintech, about two years ago' gives the interviewer everything they need to calibrate the scale of your work. After that, get to the action.
Mistake 6: Saying 'we' when the interviewer needs 'I'
Insight
Using 'we' for everything — including decisions and actions you personally took — makes it impossible for the interviewer to assess your individual contribution, which is the only thing they are actually evaluating.
This is a cultural and linguistic habit, not a character flaw. In many engineering cultures, and in many languages, 'we' is the default for team work — it signals collaboration and avoids appearing arrogant. In a US or UK interview, the interviewer needs to know what YOU did. They understand you worked in a team. They are asking about your role within it. Saying 'we' throughout leaves them with nothing to score.
| 'We' (unscoreable) | 'I' (what the interviewer needs) |
|---|---|
| We decided to migrate to a new database. | I recommended the migration and owned the technical design. My team executed the individual service changes. |
| We reduced the incident rate by 60%. | I introduced the on-call runbooks and the post-mortem process that drove the 60% reduction in incidents. |
| We built the feature in two sprints. | I designed the data model and led the backend work. My colleague handled the frontend integration. |
| We had a difficult conversation with the client. | I led that conversation — I was the technical point of contact, and I made the call to recommend a scope change. |
Acknowledge the team, then claim your part. 'My team built X, and my specific contribution was Y' is both accurate and scoreable.
Key takeaway
Using 'I' is not arrogance in this context. It is the answer to the question that was asked. An interviewer who cannot identify your individual contribution cannot advocate for you in the debrief.
Mistake 7: Filler phrases that signal uncertainty
Insight
Filler phrases like 'that's a great question', 'how can I say this', 'let me think for a moment about how to explain this', and 'it's a bit complicated' are heard by interviewers as stalling — and they lower the perceived seniority of the speaker.
Some of these phrases come from genuine politeness conventions. 'That's a great question' is common in some cultures as a way to acknowledge the speaker. In a US or UK interview, it sounds like flattery or like you are buying time. 'It's a bit complicated' is particularly damaging — it signals that you are not sure you can explain it clearly, which is a core senior-engineer skill.
| Filler phrase | What the interviewer hears | What to do instead |
|---|---|---|
| That's a great question. | Stalling, or flattery. | Say nothing. Pause for one second. Then answer. |
| How can I say this... | They don't know how to explain it. | Pause, then start with the conclusion: 'The short version is...' |
| It's a bit complicated. | They may not be able to explain it simply. | Start explaining. If it's complex, structure it: 'There are two parts to this.' |
| Let me think about how to explain this. | Unprepared. | A silent pause of 2–3 seconds is fine and reads as thoughtful, not unprepared. |
| I'm not sure if this is what you're asking, but... | Anxious. Unsure of the question. | If you are unsure, ask: 'Are you asking about the architecture decision or the team process?' Then answer. |
A silent pause is always better than a verbal filler. Native speakers pause too — the difference is that fillers draw attention to the pause, while silence just looks like thinking.
Mistake 8: Literal translation idioms
Insight
Translating an idiom or expression word-for-word from your first language produces phrases that are grammatically close to English but semantically wrong — and they pull the interviewer's attention away from your content.
This is not about accent or pronunciation — it is about phrases that mean something different in English than their literal words suggest. The interviewer usually understands what you meant. The problem is the half-second of confusion it creates, and the cumulative effect of several such moments in one interview. Common examples vary by first language, but the patterns are consistent: expressing time, expressing effort, describing relationships between things.
Common literal-translation patterns and their natural English equivalents
- 'I have 5 years' → 'I have 5 years of experience in...' (the noun is required in English)
- 'We made a meeting' → 'We held a meeting' / 'We had a meeting'
- 'I did a mistake' → 'I made a mistake'
- 'It was very much work' → 'It was a lot of work' / 'It was a heavy workload'
- 'I am working since 3 years' → 'I have been working here for 3 years' (present perfect continuous)
- 'We discussed about the architecture' → 'We discussed the architecture' (no 'about' after 'discuss')
- 'I explained him the problem' → 'I explained the problem to him'
- 'The system is working good' → 'The system is working well' (adverb, not adjective)
Interview tip
The fix is not to memorise every idiom — it is to record yourself answering a practice question and listen back for phrases that sound unusual to you. If something sounds slightly off even to you, it will sound off to the interviewer. Replace it with the simplest, most direct English phrasing you know.