How to Evaluate English Proficiency in IT Candidates: Practical Tests Foreign Employers Actually Use in 2026

A head of engineering at a UK fintech hired a senior backend engineer from Eastern Europe last spring. Written English: excellent. Clean Slack messages, well-structured PRs, articulate cover letter. Three weeks into the role, the engineer was visibly struggling on standups and silent in design discussions. He could write English. He couldn’t speak it under cognitive load. The team had screened the wrong skill.

We see this often enough that it deserves a proper guide.

This post is the English-screening playbook we’d want every foreign hiring manager to read before evaluating Belarusian or broader CIS candidates. It covers the four English skills that actually matter in IT roles, why CEFR labels alone are not enough, the practical screening techniques foreign companies use, role-specific scenarios that surface real proficiency, and the common screening mistakes that produce mis-hires. If you’re still comparing Belarus to other Eastern European markets, our 2026 comparison of Belarus, Poland, Ukraine, and Romania covers the broader market picture.

The four English skills that matter for IT roles

English proficiency isn’t a single skill. It’s four skills that diverge meaningfully in the Belarusian candidate pool — and most screening processes test one or two and assume the rest.

Reading. Documentation, PRs, technical specs, internal wikis. Almost universally strong in Belarusian IT candidates. Years of consuming English-language technical content has built this layer thoroughly. Worth a baseline question, but rarely the gap.

Writing. Slack, PRs, design docs, email. Generally strong, with variation in idiomatic naturalness. The candidate who writes clear technical English at C1 level may still default to a slightly stilted register in casual Slack. Usually a manageable gap.

Listening. Standups, design discussions, customer calls, on-call rotations. Variable across candidates. Depends heavily on prior exposure to English-speaking colleagues. A candidate from an EPAM client-services background usually has stronger listening than a candidate from a Russian-language product company. Worth testing specifically.

Speaking. Standups, presenting work, articulating design trade-offs, pushing back on decisions in real time. The weakest skill on average and the one most under-tested. Many candidates who write fluent English struggle with spontaneous spoken articulation under cognitive load.

Why this matters: a senior engineer who can read and write English fluently but freezes when asked to articulate a technical trade-off out loud will struggle in any modern remote engineering culture. The screening that catches “can write English” but not “can think out loud in English under cognitive load” produces exactly that hire.

Why CEFR alone is not enough

CEFR (the European framework of A1–C2 levels published by the Council of Europe) is useful as a baseline filter, but it has three specific limits for IT hiring.

Self-reported. Most CVs show CEFR levels the candidate assigned themselves. There’s no central authority verifying them. Generous self-assessment is common; modest self-assessment exists but is rarer.

Doesn’t measure technical English. A B2 reader of literary English may struggle with API documentation. A C1 in academic English may still fumble with informal Slack register. The CEFR framework was built for general language proficiency, not for the specific demands of working in tech in English.

Fails to discern performance under load. Many applicants fare well on formal language exams when given a single assignment to complete, but many falter during a 90-minute design debate where they must also comprehend intricate technical information. The gap between “can perform a language task” and “can think out loud in English while reasoning about distributed systems” is real and usually invisible on paper.

CEFR is still worth asking about as a starting filter. Pair it with real-world test signals.

Six practical English assessment techniques foreign employers actually use

This is where most of the value of the post lives. Six techniques, with what each one surfaces and what it doesn’t.

The first 30 seconds of small talk. Surfaces conversational ease and how the candidate handles unscripted English. “How was your week?” “Where are you joining from?” Strong indication of the spoken baseline, but not technical. Keep an eye out for overly prepared responses and how quickly the candidate responds to your follow-ups.

The “explain your last project” exercise. Three to five minutes. Tests technical communication, vocabulary range, and ability to structure a longer answer. The candidate who recites a memorized blurb without engagement signals one thing; the one who naturally adjusts as you interject signals another. The interjections matter — ask a clarifying question at minute two and observe what happens to the rest of the answer.

Follow-up questions that require unpacking. “Why did you make that trade-off?” “What would you do differently?” “What was the hardest part?” Tests ability to think out loud in English rather than deliver prepared answers. The strongest signal is whether they can articulate uncertainty in English — saying “I’m not sure, but I’d think about it this way” is a high-skill move.

The interrupting-on-purpose probe. Once during the interview, gently interrupt mid-answer with a clarifying question. Strong candidates restart their thread smoothly and integrate the new input. Weak speakers lose composure or revert to overly cautious shorter sentences. This is one of the cleanest tests of real working English, and almost no one runs it.

The “in your own words” reformulation. Ask the candidate to summarize back what you just said about the role or the company. Surfaces listening comprehension at depth, not just surface acknowledgment. “Yes, I understand” tells you nothing; “So if I’m understanding right, the main thing is X and Y, and you’re particularly looking for someone who can Z” tells you everything.

The written sample done live, not pre-prepared. Ask for a short structured response in Slack or email format during or right after the interview, written on the spot. Pre-prepared writing samples tell you nothing about composition speed or live idiomatic comfort. Five minutes of live writing surfaces more than any submitted writing sample.

A brief note on third-party tests. EF SET is free and reasonably calibrated. Cambridge Linguaskill is commercial but well-respected. Both can be useful as add-ons. Most foreign tech companies don’t run them — the six techniques above cost zero and surface more useful signal in 30 minutes than most formal tests do in two hours.

Role-specific scenarios that surface real proficiency

Different IT roles need different English skills under different loads. The screening should mirror the actual job.

Frontend or Backend Engineer (general). The “explain your last project” exercise plus a design-discussion follow-up. Test whether they can articulate a trade-off they actually made. A 30-minute conversation that covers a real project plus a design probe surfaces enough signal for most roles below senior level.

Senior or Staff Engineer. Add a 10-minute system design discussion. The English-screening and the system-design-screening become the same test — and that’s the right outcome. A senior who passes design alone but stalls on the English layer is a real hiring risk for any cross-time-zone team. Watch for whether they can articulate trade-offs as they design, not just describe a finished architecture.

DevOps or SRE. Test articulating an incident scenario. “Walk me through a recent on-call incident, including what you didn’t know at the time.” Tests vocabulary range (security, performance, networking terms), time-pressure communication, and — critically for incident response — ability to be clear about uncertainty without losing composure.

Data Engineer or Data Scientist. Test explaining a model decision or a data pipeline trade-off. Often the weakest English layer in this segment because daily work has less customer-facing communication than in software engineering. A data scientist who can write a clear analysis in English but can’t talk through model selection in real time is common.

Product Manager or Tech Lead. Test storytelling. “Tell me about a project where you had to align engineering and product.” Behavioral and English-fluency become the same evaluation. This is the role where English speaking matters most because the job is largely about translating between groups.

Customer-facing roles (Solutions Engineer, Support Engineer, Sales Engineer). The highest English bar. Add a five-minute role-play. “I’m a frustrated customer; my integration broke at 2 am.” Surfaces real-time English under stress better than any other test. Most candidates who pass technical interviews comfortably struggle here, and that’s the point.

The pattern: pick the scenario that mirrors what the actual job will demand, not a generic English test.

The “B2” trap: how to read CEFR labels in practice

What “B2” actually means in IT hiring practice, broken down:

Self-reported B2 often means “I can read documentation and write Slack messages, but I have not done a 90-minute technical interview in English.” Common on CVs. Treat as a starting filter, not a screening conclusion.

Tested B2 (from a real assessment) means roughly: can hold a conversation on familiar topics, makes occasional errors, may struggle with complex abstract discussion. Better signal than self-reported, but still incomplete for IT hiring.

Working B2 in IT is what you actually need to measure. Can the candidate participate in a design discussion, push back on a decision in real time, summarize an incident under stress, and write a clear PR description? That’s a different skill set than what CEFR measures formally.

What you actually need for most remote IT roles: working B2+ (closer to C1) speaking, B2 listening minimum, any reasonable level of reading and writing.

The gap to watch: B2 on paper, B1 in practice when stressed. The screening techniques above catch this; CEFR alone does not.

The Council of Europe CEFR guide is the definitive reference for what each level formally means. The EF English Proficiency Index publishes annual country-level data on average English skill — useful background for setting expectations, less useful for individual hiring decisions.

Common screening mistakes and how to fix them

Five mistakes hiring managers make repeatedly.

1. Conducting the interview half in Russian out of politeness. Eliminates the test. If the role requires working English, the entire interview should be in English. Switching back to Russian to “make the candidate comfortable” is well-meant and counterproductive — it gives you no signal on the skill you’re hiring for.
2. Asking “what’s your English level?” as a screening question. Self-reported and near-useless. Ask about real situations instead: “When was the last time you presented your work in English?” “How often do you write in English at your current job?” “Tell me about a meeting in English that was hard for you and why.”
3. Over-weighting accent. A heavy accent with clear communication is usually fine. A light accent with poor comprehension is the actual risk. Focus on whether you can understand the candidate and whether they understand you, not on accent neutrality.
4. Confusing politeness with proficiency. A candidate who answers every question with “yes, of course” and “I understand completely” is not necessarily understanding. The “in your own words” reformulation technique catches this.
5. Trusting written samples that may have been AI-polished. Slack messages, PRs, and email samples submitted in advance can be polished after the fact. The live writing sample mentioned above is the way around this.

A practical implication: if you’re hiring through a recruiting partner, ask them how they screen English specifically. Vague answers (“they have good English”) signal a partner who isn’t actually testing it. Our IT recruitment service runs an explicit English-screening step calibrated to the seniority and role you’re hiring for.

The 2026 AI complication

A specific 2026 consideration worth being explicit about: candidates increasingly use AI translation or polish tools during remote interviews. The patterns are detectable but worth understanding.

A candidate who pauses unnaturally before each answer, whose answer quality is wildly inconsistent across questions, or whose written submissions are markedly more polished than spoken answers may be using LLM assistance. The pause pattern is the strongest signal — silent for 5–8 seconds, then a polished answer, then conversational reverts to natural pace.

This isn’t necessarily disqualifying. Depends on the role and what you’re testing. For a role where the engineer will work primarily with AI tooling and rarely speak in real time, an English speaker who uses translation tools may still be a strong hire. For a role that requires live English under pressure (incident response, customer-facing work, design discussions), it’s a signal worth weighting heavily.

The cleanest fix: the live writing sample done with a shared screen. If you can see the candidate type, you can see whether the writing is theirs. Combined with the conversational techniques above, this gives you a complete picture in 30 minutes.

FAQ

What CEFR level does our IT role actually need?

For most remote engineering roles: working B2+ speaking (closer to C1 in practice), B2 listening minimum, B2 reading and writing. For customer-facing roles (Solutions Engineer, Support Engineer, Sales Engineer): C1 across all four skills. For roles with heavy async written communication and limited live English (some data engineering, some research roles): B2 across the board is enough. Calibrate to what the role actually requires, not to a generic standard.

How long should the English-screening portion of the interview be?

It shouldn’t be a separate portion. Embed it in the technical and behavioral interviews. A 60-minute conversation that includes the “explain your last project” exercise, follow-up questions, and an interrupted exchange surfaces enough signal. Adding a dedicated “language test” round signals to candidates that you’re treating them differently and often produces stilted performance.

Should we test written English separately?

Yes, but briefly. A 5-minute live writing sample done during or right after the interview is enough. Don’t ask for pre-submitted writing samples — they tell you nothing about composition speed or unprepared idiomatic comfort, and they may be AI-polished.

Is a strong accent a problem for remote roles?

Usually not, as long as comprehension is clear. Remote teams work across many accents already — leading async-first companies like GitLab have built explicit communication frameworks that work across language backgrounds. What matters is whether the candidate can be understood and can understand colleagues clearly under typical work conditions, including video calls with imperfect audio. Focus on comprehension, not on accent neutrality.

How do we test English without making the interview feel like a language exam?

Embed the tests in the technical and behavioral conversations. The “explain your last project” exercise is a behavioral question that doubles as a speaking test. The system design discussion at senior level is a technical test that doubles as a real-time English test. The candidate experience stays normal; you get cleaner signal.

What’s the difference between conversational and technical English proficiency?

A meaningful gap. Many IT candidates can hold conversational English but struggle with technical English under complex cognitive load — and vice versa, a smaller group can discuss technical content well but freezes in informal small talk. For most IT roles, technical-under-load is the more important skill. For customer-facing roles, both matter. Test both, briefly.

Should we require a third-party test like Linguaskill or EF SET?

Optional. They’re useful as supporting evidence but not as the screening conclusion. EF SET is free and reasonably calibrated. Linguaskill is paid and more thorough. If you require one, do it as a pre-interview filter for high-volume roles, not as the screening test itself.

How do we handle candidates who clearly use AI translation during the interview?

Depends on the role. For roles requiring live English (incident response, customer-facing, design discussions, real-time collaboration), AI-assisted answers are a hard signal that working English isn’t at the required level. For roles where the engineer can plan and compose responses asynchronously, AI assistance is less of a concern. The five-minute live writing sample with a shared screen is the cleanest test.

Want a 30-minute walkthrough?

If you’d like a 30-minute walkthrough of the English-screening playbook we use on inbound candidates — including the role-specific scenarios calibrated to your stack, the seniority level you’re hiring for, and the patterns we look for in interviews — get in touch. We’ll come back within 24 hours.

For broader context on what hiring through Belarus looks like operationally, our pages on EOR, offshore development centers, and Hi-Tech Park residency cover the structures most foreign employers use.