13 January 20267 min read
Language comes up in every conversation about hiring across borders and is almost always discussed badly. It gets reduced to a level on a certificate or, worse, to a feeling about someone's accent formed in the first thirty seconds of a call. Both are poor proxies for the thing that actually determines whether a remote engagement works.
Worth separating out what you need, because it is narrower and more testable than general fluency.
What you actually need
- That they understand what was asked, including the part that was implied rather than said
- That they can write clearly in short form: a ticket, a pull request description, a status update, a message that arrives while you are asleep
- That they can say 'I do not understand' and 'I disagree' without it costing them anything
- That they can hold their own in a fast group call with people talking over each other, or know to follow up in writing afterwards
Notice that three of those four are not about vocabulary at all. They are about confidence and habit, which is why a strong test-score candidate can still be a communication problem and a hesitant speaker can be excellent.
Accent is not comprehension
An accent tells you where someone learned English. It tells you nothing about their reading comprehension, their writing, or their ability to explain a technical trade-off. Screening on it is a straightforward way to reject strong candidates in favour of confident ones, which is the same failure that afflicts non-technical interviewers generally.
There is a legitimate version of the concern, and it is worth stating precisely: if your team genuinely cannot follow someone on a call, that is a problem, and it is a problem whether the accent is Lebanese, Glaswegian or Bavarian. Test it directly by having a real conversation rather than inferring it from the first impression. Most of the time the difficulty disappears after two weeks of exposure, which is not something a thirty-second judgement can predict.
Written English usually matters more
In distributed work most communication is written and asynchronous, and written English is both more consequential and easier to assess. A person who writes a clear pull request description and a legible summary of what they did today can be fully effective even if calls take them more effort.
The reverse is a common and expensive mistake: hiring the person who is delightful on video and discovering their written updates are unusable, which means someone on your side has to translate them into something the rest of the team can act on.
Three tests that tell you something
The first is asynchronous and written. Send one real question by message, ideally slightly ambiguous, and read the reply. Did they answer the question, ask about the ambiguity, or answer a different and easier question? Length is irrelevant; a two-line answer that resolves the ambiguity is the best outcome.
The second is disagreement under mild pressure. In the call, state something about your product or approach that is a bit wrong and see whether they contradict you. Anyone can be pleasant; the ability to say 'I think that will not work, because' in a second language to a prospective client is the thing you are actually buying.
The third is explaining something unfamiliar. Ask them to explain a concept from their work that you do not know. It requires improvised, structured language rather than rehearsed interview vocabulary, and it is the closest simulation of what they will do on your calls every week.
Domain vocabulary versus general fluency
Engineers, marketers and support agents working in international teams often have excellent technical vocabulary and thinner conversational range. That is the right way round for the job and a poor showing on small talk should not be read as a language deficit.
Where the ranking flips is customer-facing work. A support agent handling frustrated customers in writing needs register control: the ability to sound calm, warm and firm in the same message. That is a genuinely higher bar than technical fluency and should be tested with real ticket text rather than an interview.
Lebanon specifically
It is a practical point rather than a sales one: education in Lebanon is commonly multilingual, with Arabic alongside French or English through school and university, and a great deal of professional and technical work happens in English or French. In hiring terms this mostly means the language conversation is a shorter one than it is in some markets, and that a French-speaking team in Paris or Brussels has a wider network than an English-only brief would suggest.
It does not mean the assessment can be skipped. Run the three tests anyway. What it means is that you should expect to spend the time on the job fit rather than on the language.
When language really is the problem
Sometimes it is, and the honest move is to say so plainly rather than dressing it as a culture-fit rejection. Be specific about the failure: was it comprehension of written requirements, or fluency in live discussion? The first is close to disqualifying for most roles. The second is often survivable by changing how you work, moving decisions into writing and using calls for alignment rather than detail.
That change is worth considering regardless. Teams that write things down are more robust to time zones, to holidays, to people leaving, and to a candidate who is thoughtful but quiet on a video call. Improving the writing habit is usually a better investment than raising the language bar.