Recruiting Cloud Engineers in Belarus: Skills and Salary Bands for AWS, Azure, and GCP

Cloud hiring in Western Europe in 2026 is a seller’s market — short candidate pools, two-month notice periods, and salary bands that have outrun most international budgets. Belarus runs on different math. Senior AWS, Azure, and GCP engineers cost 50–70% less than in Berlin or London at comparable seniority. The talent pool is wider than its reputation suggests, and the engagement models have matured into something finance teams can actually sign off on.

This article provides answers to three questions: what abilities are expected at each seniority level, which cloud has the largest local pool, and what constitutes a competitive offer.

1. The numbers first

Since we know that’s what you’re looking for, we’ve placed the pay chart at the top. The gross monthly compensation in USD for direct or outstaffed engagements is shown here, cross-referenced with our 2026 placement statistics and wage surveys from dev.by. A service charge is added to these bands in EOR pricing.

​

​

Three things compress these ranges in real conversations. A professional-level certification pushes a candidate roughly 10–15% above the median for their band. Production Kubernetes experience adds another 15–20%, and cloud security depth — IAM design, threat modeling, real incident response — adds 10–20% on top. Engineers with all three negotiate from the top of the senior band, and they’re worth it. If you’d like a tailored band for your exact role, our team runs a free benchmark against live placements within 48 hours.

2. The three certifications that actually predict performance

Foundational certs are a vibe check.  Engineers with associate-level certifications have shipped something. The certifications that correspond to the seniority you would identify in an interview are those at the professional level. If you’re scanning resumes fast, you’re looking for one of three specific credentials.

AWS Solutions Architect Professional (SAP-C02)

The most common professional-level credential in the Belarusian market. Holders have typically owned multi-account AWS environments and made real cost-versus-resilience trade-offs in production. Cross-check against hands-on work — the cert without a project portfolio behind it is a yellow flag. The AWS Well-Architected Framework is a useful structure to organize the technical interview around, because most SAP-C02 holders will recognize the pillars and have opinions about them.

Azure Solutions Architect Expert (AZ-305)

Smaller pool, but the engineers who hold this credential tend to come from regulated industries — banking, healthcare, government — where Azure dominates. Strong overlap with hybrid cloud and identity work. Microsoft’s Azure architecture documentation maps closely to what these candidates will have shipped, and it’s a fair reference for designing the interview.

Google Professional Cloud Architect

The most concentrated technical depth in Belarus’s narrowest pool. For analytics-focused teams and ML-leaning platforms, GCP-certified engineers are frequently the best fit. A longer search—typically two more weeks—and a smaller shortlist are to be expected. Data platform positions are worth waiting for.

One warning is worth mentioning.  In this market, candidates who possess four credentials across all three clouds but are unable to identify a system they actually developed are engaging in a practice known as “cert-collecting.” A single cert paired with three production war stories is almost always the stronger hire.

3. Reading resumes in this market

Five patterns come up often enough that we filter for them during pre-screen. The clearest warning sign is a resume that’s heavy on certifications and thin on shipped work — four credentials, three companies, and no description of what the candidate actually built. That’s almost always a junior in disguise. Closely related is the engineer who lists Kubernetes as a skill but can’t tell you, without prompting, whether they ran EKS, GKE, AKS, or a self-managed cluster — and how many nodes were in production. Real operators know.

Early detection of two more structural clues is worthwhile. If Terraform or another infrastructure-as-code tool doesn’t appear anywhere on the resume past 2022, you’re probably looking at someone who deploys through the console, which means they haven’t worked at scale recently. And senior candidates who’ve never been paged have never run real production, regardless of title. Either dig harder into what their on-call rotation actually looked like, or adjust the seniority expectation downward. Salary expectations 30%+ above local market are the fifth pattern: usually it’s a sign the candidate is planning to relocate, which is fine if you’re hiring fully remote but worth knowing before the offer goes out.

On the positive side, the signals that predict strong hires are mostly stories, not credentials. An engineer who can guide you through every step of a production incident—detection, mitigation, postmortem, and fix—has held a senior position at a significant organization. A specific cost-saving project with a real number behind it (“reduced our AWS bill by 38% over six months by moving X to Y”) beats any cert. Multi-cloud exposure, even if shallow, signals adaptability and durability. Active participation in the local community — meetup talks, contributions to CNCF projects, a maintained GitHub — points to continuous learning. And the seniors who admit uncertainty in an interview are the seniors who admit it in a production incident, which is exactly when you need them to.

4. How a 14-day search actually unfolds

Any cloud engineering search has its best leverage during the first 48 hours. The brief—stack, seniority, must-haves, budget, and engagement model — is locked in on the first day of the kickoff call. Before any candidate gets a job description, the recruiting manager verifies the offer band on day two after we deliver a wage benchmark against actual placements.  Most failed searches die in this window, when the brief is loose and the budget hasn’t been pressure-tested.

Day three through Day six are dedicated to sourcing and pre-screening. The recruiter applies filters based on stack relevance, notice-period flexibility, English fluency, and certification level. The shortlist, which consists of four to six applicants with complete biographies, expected salaries, and start dates, is sent by day seven. Your team runs technical interviews — system design plus a live infrastructure-as-code task — through day ten, with the final round and reference checks landing on days eleven and twelve. By day thirteen the offer goes out, and contracts are signed on day fourteen, with onboarding scheduled for the following week.

Add roughly a week for senior roles and ten to fourteen days for lead and architect searches, where the candidate pool is thinner. The two ways this timeline breaks are predictable. The first is an internal stakeholder who isn’t aligned on the brief at kickoff, which causes the spec to change mid-sprint. The second is interview feedback that takes longer than 24 hours, which loses candidates to faster movers. Both are fixable if you call them out before kickoff, and our recruiters will push back on either pattern when we see it forming.

5. What your monthly budget actually buys you

Salary tables show numbers. Purchasing-power comparisons show what those numbers mean in practice — and they’re the comparison that usually moves a CFO. Here’s what the same monthly budget gets you across Europe’s main hiring markets in 2026.

The structural point is straightforward. A $5,000/month budget that hires a junior in Berlin hires a senior with production Kubernetes and one professional certification in Minsk. The talent pool isn’t smaller. The local cost base is. Cross-referenced against the Stack Overflow Developer Survey, senior cloud engineers in Eastern Europe report similar tooling, similar tenure, and similar self-rated proficiency to their Western peers — the gap is in pay, not in capability.

6. What pushes a candidate to the top of their band

The biggest single driver is production Kubernetes experience. Not “used Kubernetes” or “deployed to GKE for a personal project” — actual operational ownership of a cluster running real workloads, with the war stories to prove it. Engineers with this background routinely negotiate 15–20% above the median for their level, and the premium is justified by how rare the experience actually is. Cloud-native depth, especially familiarity with the broader CNCF ecosystem beyond Kubernetes itself, compounds the effect.

Multi-cloud fluency is the second major driver. Engineers who’ve shipped production work across two clouds — typically AWS and Azure — earn 15–20% more than single-cloud specialists at the same seniority. Professional-level certifications add another 10–15% on top of base when paired with demonstrable hands-on work. Cloud security specialization, including IAM architecture, threat modeling, and incident response, layers 10–20% more for senior roles. The economic logic is straightforward: each of these skills shortens time-to-impact for the employer, and the local market has internalized that pricing. A senior AWS engineer with production Kubernetes, an AZ-305 on the side, and security depth doesn’t negotiate from the senior band — they negotiate from the lead band, regardless of their actual title.

7. Bringing Belarusian cloud engineers onto your team

There are three practical engagement models for international employers. Outstaffing is the fastest — the engineer works as part of your team day to day, while the staffing partner handles employment, payroll, and compliance. Time-to-signed-offer is typically two to four weeks for mid-level roles. Employer of Record (EOR) is the cleanest structure for engineers you intend to retain long-term: the partner becomes the legal employer, but the engineer integrates fully into your team and reports to you. EOR adds a service margin but eliminates the operational overhead of cross-border employment. Direct hire is technically possible but requires a registered Belarusian entity, which only makes sense if you’re building a hub of fifteen people or more.

The recruitment.by team handles all three models, including the legal, payroll, and compliance scaffolding behind each. For most international employers hiring their first one to five cloud engineers in Belarus, EOR is the right structure — it’s compliant, predictable, and avoids tying up legal and finance bandwidth that’s better spent on the actual hire.

Next steps

If you’re scoping a cloud engineering hire in Belarus, the right starting point is a benchmark against live placements for your exact role, stack, and seniority. Send us the brief, and we’ll come back with a realistic salary band, a candidate availability read, and a sample shortlist within two business days. No commitment required, and the data is yours to use however you’d like.

Hiring Blockchain and Web3 Developers in Belarus: Stack, Skills, and Red Flags

Belarus has quietly become one of the most underrated talent markets for blockchain and Web3 hiring. Strong math and CS education, a regulatory framework that explicitly recognizes crypto, and a developer community that has been shipping smart contracts since “DApp” still needed to be explained — it all adds up to a hiring pool that punches above its size.

The catch: the market has changed a lot since 2021. Salaries have moved, top engineers are split between staying local and going remote-for-export, and the legal options for hiring devs in Belarus look very different from hiring in Berlin or Lisbon.

This guide walks you through what to look for when you hire blockchain and Web3 developers in Belarus — the technical stack you should expect on a senior CV, the right hiring model for your situation, and the red flags you can’t afford to miss.

Why Belarus for Web3

Belarus has been a serious software exporter for two decades. The High-Tech Park (HTP) in Minsk — the country’s special economic zone for IT — gave the industry tax incentives and, in 2018, explicit legalization of crypto operations under Decree №8. Companies that secure High Tech Park residency can issue tokens and run exchanges.

For founders building globally, that means three practical things:

• A developer base with hands-on production experience in EVM chains, Solana, Cosmos, and zero-knowledge stacks.
• Flexible payroll. Belarusian devs are used to working for foreign employers and being paid in USD or EUR.
• Lower burn rates. Senior Web3 salaries in Belarus typically land 30–45% below Western European rates, though the gap is narrower than it was three years ago.

The market isn’t frictionless. After 2022, a meaningful share of senior engineers relocated to Poland, Cyprus, Georgia, and the UAE. The talent that stayed includes strong mid- and senior-level developers who want stable foreign-paying work without leaving home, which — if you set up the right structure — plays well for distributed teams.

According to the Electric Capital Developer Report, Eastern Europe accounts for one of the largest non-US shares of active crypto developers globally — and Belarus contributes meaningfully to that figure.

The stack to look for in 2026

“Blockchain developer” is too broad to be useful in a job spec. What you actually need depends on your chain, your product, and the layer of the stack you’re hiring for.

Smart contract engineers (EVM). Solidity with deep familiarity with the Ethereum developer documentation and EIPs that affect your protocol. Foundry or Hardhat for testing. OpenZeppelin patterns. Working knowledge of Layer 2s — Arbitrum, Optimism, Base, zkSync — and bridging. Audit-ready code style: NatSpec comments, fuzz tests, invariant testing.

Smart contract engineers (non-EVM). Rust for Solana, NEAR, or Polkadot pallets. Move for Aptos and Sui (a smaller pool — price accordingly). Solana engineers should be comfortable with the Anchor framework and the Solana developer documentation, and fluent in account models that differ from EVM (rent, PDAs, sealevel runtime).

Full-stack Web3 engineers. TypeScript, React or Next.js, paired with wagmi, viem, ethers.js, or web3.js. Wallet integrations across MetaMask, WalletConnect, and embedded-wallet SDKs like Privy or Dynamic. The Graph for indexing, or custom indexers using Ponder or Subsquid.

Infrastructure and protocol engineers. Go for node infrastructure, MEV tooling, or sequencers. Familiarity with libp2p, gossip protocols, consensus mechanisms. Hands-on experience running validators or working with RPC providers.

For senior roles, you also want exposure to security tooling — Slither, Mythril, Echidna — and at least one external audit on a deployed contract. Surface-level knowledge here is the most common gap on Belarusian (and global) CVs.

Skills beyond the stack

The technical stack is the floor. The engineers who actually ship reliable Web3 products share a few traits that don’t show up in a tech list.

Security-first thinking. A senior Web3 engineer should walk you through reentrancy, oracle manipulation, MEV exposure, signature replay, and access-control bugs without flipping through notes. If they hesitate on these, they’re not senior — regardless of how many years they claim.

On-chain literacy. Ask them to walk you through a transaction they sent last week. Strong candidates will tell you the chain, the contract, the gas spent, and what they were debugging. Weak candidates get vague.

Audit experience. Has their code been audited? By whom? Can they show the report and explain findings they pushed back on? Engineers who’ve sat through an audit cycle are dramatically more careful in production.

Comfort with ambiguity. Web3 specs change. EIPs evolve, L2s update gas semantics, oracle providers shift pricing. You want people who can read a forum thread and adapt, not engineers who need finalized requirements.

Clear communication. This sounds soft but it isn’t. Distributed Web3 teams live in Discord, GitHub issues, and async docs. Engineers who can write a clear postmortem are worth more than ones who can’t.

Five hiring models, and when each makes sense

This is where founders most often get tripped up. You can hire the same developer in Belarus under five very different legal structures, and each has a different cost, speed, and risk profile.

Direct hiring. You either set up a Belarusian legal entity or contract the developer as an individual entrepreneur (IP). This gives you the tightest grip on the relationship and the lowest long-term cost per hire. The trade-off is administrative overhead: tax registration, local accounting, compliance with Belarusian labor law, and — if you want HTP tax benefits — an HTP residency application that can take months. Direct hiring makes sense if you’re committed to Belarus as a long-term hub and you’re hiring at least five to ten engineers.

Employer of Record (EOR). A local company employs the developer on paper, handles payroll, taxes, and labor compliance, and invoices you monthly. You manage the developer day-to-day; the EOR handles everything else. This is the fastest way to onboard — a strong candidate can start in a few days — and the cleanest path for a first hire. The downside is a flat monthly fee on top of salary, which becomes less efficient at scale.

Professional Employer Organization (PEO). PEO is a co-employment arrangement. You still need a local presence (or a structure that approximates one), and the PEO becomes a co-employer handling HR, payroll, and benefits administration. You get more control over employment terms than with EOR, in exchange for more compliance work on your side. Suitable for companies that already have local footing and want to outsource HR ops.

Outstaffing. With IT outstaffing, a Belarusian vendor employs the developer and dedicates them full-time to your project. You direct the work; the vendor handles employment and payroll. The line between outstaffing and EOR is thin — outstaffing tends to be IT-specific, often comes from a vendor with HTP residency (which carries tax benefits passed through in pricing), and usually assumes the engineer is sourced by the vendor as well as employed by them. Good for fast technical hires when you don’t have a candidate pre-identified.

Outsourcing. Full project delegation. You define outcomes; the vendor delivers them with their team and their process. You don’t manage the engineers. Outsourcing fits time-boxed scope — an MVP, a smart contract suite that needs to ship before a token launch, an audit-prep refactor. It’s the wrong fit for product engineering where you need long-term ownership and tribal knowledge to stay inside your company.

A simple rule of thumb: for one or two senior hires, start with EOR or outstaffing. For five-plus, look at HTP residency or direct hiring. For a finite project, outsource. The structure should follow the team plan, not the other way around. If you’re weighing EOR against PEO specifically, this comparison of both models in Belarus goes deeper on the trade-offs.

Red flags to watch for

Web3 is a young field with a lot of CV inflation. These patterns should make you pause — not auto-reject, but probe harder.

Years of experience that don’t match the timeline. “Six years of Solana” is impossible — Solana mainnet launched in 2020. Same for Aptos (2022) and Sui (2023). Watch the math.

No public on-chain footprint. Not every great engineer publishes everything, but a senior Web3 developer with zero verifiable on-chain artifacts is a yellow flag. Deployed contract addresses, GitHub repos with commits over time, forum posts on Ethereum Magicians or EthResearch — you should be able to find something.

Vague answers on deployed contracts. “I worked on a DeFi protocol” without a name, address, or even a chain is rarely real production experience. Real builders will tell you “I wrote the staking module on this protocol, here’s the Etherscan link.” If they say they can’t share for NDA reasons, ask for a sanitized example. If everything is NDA, that’s its own signal.

No mention of security tooling or audits. A senior smart contract engineer should reference Slither, Mythril, Echidna, or Foundry’s fuzzing without being prompted. A candidate who’s never sat through an audit and treats it as someone else’s problem isn’t ready for production money.

Only worked on questionable token launches. A CV stacked with fair-launch memecoins, anonymous projects, and short-lived “DeFi 2.0” forks is a pattern. Some of those engineers are excellent. Many are not. Ask what they’d do differently and what went wrong — the honest ones answer well.

Telegram-only communication and refusal to do a code interview. Web3 has a culture of pseudonymity for a reason, but a candidate who refuses any verified call, won’t share a portfolio you can verify, and only wants to talk in DMs is courting trouble. Hire people willing to be accountable.

Compensation expectations way below market. Counterintuitive, but a senior Solidity engineer asking for junior money is usually a junior who’s overestimated themselves. Get current comp data before you negotiate.

Where strong candidates actually are

The best Belarusian Web3 engineers are rarely actively job hunting. They sit inside HTP-resident companies, contribute to open source on the side, or freelance on protocols they care about. You’ll find them through GitHub contribution graphs filtered for CIS time zones, local meetups, referrals from existing HTP-resident teams, and recruiters who specialize in the local market.

A DM to a strong candidate’s GitHub profile — written by someone who clearly read their code — beats any job board post. When the message has to come from a third party, work with specialized recruiters who already have the relationships. You’ll skip the cold-outreach phase entirely.

For interviews, prefer a short paid trial task over a live coding round when possible. Smart contract work is unforgiving; a one-hour live session won’t tell you what a two-day mini-project will.

In conclusion

Web3 hiring in Belarus is one of those situations where the right setup pays off compounding. The talent is real, and the cost structure still makes sense even after the last few years of salary pressure.

What separates teams that get this right from teams that don’t isn’t the hiring model — any of EOR, outstaffing, or direct hiring can work. It’s the screening rigor. Web3 is unforgiving of bad hires in a way that few other fields are: a mistake in a smart contract isn’t a bug you patch next sprint, it’s a treasury you lost. The engineers who reach for fuzzing, who ask for audits, who treat your codebase like their own savings are worth waiting for.

If you’re ready to start, the fastest path is a short conversation with a recruiter who knows the local market. We help teams hire blockchain developers in Belarus from first conversation to signed offer in days, not months — including the setup choices we walked through above.

The market rewards founders who move quickly with the right diligence. Now you have both.

AI in Recruitment 2026: How Belarusian Recruiters Use ChatGPT, Sourcing Tools, and Automation

Hiring used to be a slow conversation between a job description, a stack of CVs, and a recruiter’s gut. In 2026, that conversation has a third participant: AI.

For Belarusian recruiters working with clients in the EU, US, and CIS, this shift isn’t theoretical. Time-to-hire is being cut in half. Sourcing pipelines that took weeks now fill in days. ChatGPT, once a curiosity, now lives in the daily workflow of nearly every IT recruiter in Minsk.

Here’s how AI is actually being used inside Belarusian recruitment teams this year — and what it means for international companies hiring talent in the country.

The Belarusian Recruitment Landscape in 2026

Belarus remains one of the most cost-efficient IT talent markets in the region. The Hi-Tech Park (HTP) still anchors the industry, and developers, QA engineers, and product specialists continue to graduate from strong technical universities each year.

What’s changed is the way that talent gets matched to companies. A few realities define the 2026 market:

• Demand for senior engineers, AI/ML specialists, and DevOps continues to outpace supply.
• Remote and hybrid setups are the default for international hires.
• Salary expectations have stabilized after the turbulence of 2022–2024.
• Compliance, payroll, and tax structures are now a real differentiator when choosing a hiring model.

Against that backdrop, AI tooling isn’t a “nice to have” anymore. It’s how recruiters keep pace.

ChatGPT in the Recruiter’s Daily Workflow

Ask any Belarusian recruiter what they actually use ChatGPT for, and you’ll get the same list with minor variations.

Writing job descriptions. A first-draft JD that used to take 40 minutes now takes 5. Recruiters paste the role brief, ask for a draft in the company’s tone of voice, and edit. The structure improves and the language gets cleaner.

Crafting outreach. Generic LinkedIn InMails see a 3–5% response rate. Personalized ones can hit 25–30%. ChatGPT is used to draft tailored intros based on a candidate’s profile, GitHub activity, or recent posts — at scale.

Screening calls and interview notes. AI summarizes recorded interviews into structured notes, flags red flags, and pulls out comparable answers across candidates so recruiters can compare side by side.

Translation and localization. Belarusian recruiters routinely work in Russian, English, and sometimes Polish or Lithuanian. GPT-class models handle translation of JDs, candidate communications, and offer letters almost instantly.

Candidate research. Background prep on an executive or niche tech candidate that once took half a day now takes 20 minutes.

The pattern is consistent: AI doesn’t replace the recruiter’s judgment. It handles the writing, the research, and the synthesis — so the recruiter spends more time on actual conversations.

According to LinkedIn’s Future of Recruiting research, most talent leaders now expect AI to fundamentally reshape sourcing and outreach within the next two years. Belarusian agencies are already living that reality.

AI Sourcing Tools That Are Actually Used

Sourcing is where the biggest productivity gains have landed. The market in 2026 has matured into a handful of tools that Belarusian agencies and in-house teams actively rely on:

• LinkedIn Recruiter with AI-Assisted Search. The default starting point. Natural-language queries return relevance-ranked lists instead of Boolean acrobatics.
• hireEZ and SeekOut. For deep technical sourcing across GitHub, Stack Overflow, conference talks, and patent databases.
• Fetcher and Gem. For automating top-of-funnel outreach sequences with personalization.
• Talentprise and Findem. For “people aggregator” searches that combine public web data into structured candidate profiles.
• Otter, Fireflies, and Read.ai. For interview transcription and post-call analytics.

A practical sourcing flow inside a Belarusian agency today looks something like this: an AI sourcing tool pulls 200 candidates, ChatGPT helps draft three variant outreach messages, an automation platform sends them at staggered intervals, and the recruiter focuses on the 30–40 candidates who reply. The funnel is the same. The math behind it is completely different.

For context on where the human side of the funnel still owns the work — and probably always will — our piece on how to evaluate a candidate in an interview is a useful companion read.

Automation Across the Hiring Funnel

AI sourcing is the loud part. Automation is the quiet part — and it’s where most of the time savings actually live.

The mature agencies in Belarus aren’t using all of these at once. They pick three or four where the ROI is obvious and resist the temptation to over-automate the parts of hiring that still need a human voice.

External research backs this up. The World Economic Forum’s Future of Jobs Report identifies AI-assisted hiring as one of the top three technology shifts reshaping HR globally.

Hiring Models in 2026: Direct Hiring, EOR, PEO, Outstaffing, and Outsourcing

AI has accelerated sourcing — but it hasn’t simplified the question of how a foreign company should legally engage Belarusian talent. That’s still a strategic decision. Here’s how the five most common models compare in 2026.

Direct Hiring

You set up a legal entity in Belarus (often inside the HTP), put candidates on your own payroll, and own the entire employment relationship. Best for companies planning a long-term presence, building a local leadership team, or hiring 20+ people. It’s the most control-intensive model and the most expensive to set up — but the most cost-efficient at scale.

EOR (Employer of Record).

A third party becomes the legal employer. They handle payroll, taxes, benefits, compliance. You direct the work. No entity required, setup in days. EOR has become the default for foreign firms hiring 1–10 specialists in Belarus, especially from the US and EU. If you’re trying to figure out where it differs from PEO, our EOR vs PEO breakdown for Belarus walks through the trade-offs honestly.

PEO (Professional Employer Organization)

PEO is co-employment: you share employer responsibilities with the PEO. You keep some legal obligations as the employer of record; the PEO handles HR, payroll, benefits administration, and compliance support. PEO works well for companies that already have a Belarusian entity but don’t want to run a full HR function in-country.

IT Outstaffing

Outstaffing means you “rent” specialists who remain employed by an outstaffing provider — often a Belarusian IT company or HTP resident. They work full-time on your projects under your management, but the provider handles all employment, payroll, and tax matters. It’s a middle ground between EOR and outsourcing: you get dedicated talent without entity setup, and you keep day-to-day control over the work.

IT Outsourcing

You delegate an entire scope of work — a feature, a product, a function — to an outsourcing partner. The partner owns the team, the management, and the delivery. You own the outcome. Outsourcing fits well for clearly scoped projects, MVPs, or non-core functions. It’s the lightest-touch model for the client and the heaviest-touch for the partner.

Quick orientation:

• Need a single senior dev fast, no entity → EOR
• Already have a Belarusian entity, need HR support → PEO
• Building a dedicated team you’ll manage directly → Outstaffing
• Need a finished product or feature delivered → Outsourcing
• Going long-term and large-scale → Direct hiring, usually inside the HTP

AI affects all five models the same way: faster sourcing, smarter screening, leaner ops. But the legal and tax structure underneath each one is what determines your real cost, your real risk, and your real timeline.

Where AI Still Falls Short

It would be dishonest to pretend AI has solved recruiting. The Belarusian teams using it most heavily are also the loudest about its limits.

Bias. AI ranking models inherit the biases of the data they’re trained on. Recruiters are running manual audits and resisting the urge to over-trust scores.

Candidate experience. Over-automated outreach reads like spam. Candidates ghost faster when they sense a bot. The teams winning in 2026 are using AI to prepare personalized human contact, not replace it.

Data privacy. GDPR, Belarusian data protection law, and client-specific NDAs all constrain what candidate data can be processed by which AI vendor. Gartner’s research on AI in HR consistently lists data governance as the top concern for HR leaders.

Hallucinations. ChatGPT will confidently invent a candidate’s previous employer if you let it. Verification stays human.

Cultural fit and motivation. No model has cracked these. They remain the recruiter’s job.

A Practical Playbook for 2026

If you’re a hiring manager or an HR lead working with Belarusian talent, the rollout pattern that’s working looks like this:

1. Start with one workflow, not ten. Pick the highest-volume task — usually JD writing or initial outreach — and automate that first.
2. Pick your hiring model before your tools. Are you running EOR, outstaffing, or direct hire? The answer changes which tools matter.
3. Audit the AI output for a month. Read what it generates. Compare it to your manual baseline. Tune.
4. Keep humans on the final 20%. Final screening, offer conversations, and reference checks belong to people.
5. Invest in your recruiter’s prompting skills. The gap between a recruiter who uses ChatGPT well and one who doesn’t is now equivalent to two years of experience.

For broader context on how a modern IT HR function should be organized to make all of this work, our piece on the structure and responsibilities of the HR department in a large IT company covers what good looks like.

Closing Thought

In 2026, AI isn’t a recruiting trend in Belarus anymore. It’s the operating layer underneath the work. ChatGPT writes the drafts. Sourcing tools build the pipelines. Automation runs the funnel. What’s left for humans is the part that was always the hard part anyway: judgement, trust, the actual hiring conversation.

The teams that win pair the tooling with the right legal structure underneath. Direct, EOR, PEO, outstaffing, outsourcing. AI makes all of them faster. Only the right structure makes the speed pay off.

If you’d rather work with a team already running this playbook every day, that’s what we do. Start with our IT recruitment services — it’s where this gets concrete.

How to Set Up an Offshore Development Center (ODC) in Belarus: A Step-by-Step Playbook

Before you start: is an ODC actually the right move?

Over the last several years, we’ve helped roughly 30 companies stand up operations in Belarus. The first thing we say on almost every intro call is the same: an ODC isn’t always the right answer. It becomes the right answer when the alternatives stop holding up — not a day sooner.

Here’s the rough math we run during those first conversations. Hiring fewer than five engineers on project-bounded work? Contractors or an EOR will beat an ODC on speed and cost, every time. Committing to ten or more engineers, a three-year-plus horizon, and direct control over hiring, IP, and management? Now the ODC starts to make sense. In practice, the tipping point usually lands somewhere between hire eight and hire twelve. That’s the moment the friction of juggling contractors quietly overtakes the fixed cost of just owning the entity.

This playbook walks through what that setup actually looks like in 2026. We’ve cut the theoretical parts. What’s left is what we’ve seen succeed and fail in practice.

Why Belarus for an ODC in 2026

The fundamentals of Belarus as a tech hub haven’t shifted much in the last decade. The geography around it has.

The country still produces some of the deepest infrastructure and product engineering talent in Eastern Europe, the legacy of two decades of work for EPAM, Wargaming, IBA, Viber, and a long list of product companies that flew under the radar. The talent network is still tight, even if a meaningful share of those engineers now sit in Warsaw, Vilnius, Tbilisi, Cyprus, or Serbia. For a modern ODC, that dispersion is actually useful. You can run a Belarus-registered entity that employs engineers across multiple jurisdictions, provided the contracting structure is set up right.

The other half of the story is the High Tech Park (HTP) — the regime that makes Belarus genuinely competitive on tax. We’ll dig into it in a moment, but the short version is this: HTP-resident companies operate under a substantially lighter tax burden in exchange for staying within a defined scope of IT activities. Almost every foreign tech company setting up an ODC here pursues HTP residency, and frankly, we struggle to name a case where it didn’t make sense to do so.

The HTP framework, and why everything else hinges on it

Almost every conversation we have with international clients ends up back at HTP. So it’s worth understanding properly before you start moving on the setup.

The High Tech Park is a special tax and legal regime the Belarusian government created in 2005 to anchor the IT sector. Foreign-owned subsidiaries can apply for residency, and once granted, the company sits inside a different tax structure than the rest of the Belarusian economy. The benefits stack up quickly: corporate income tax exemptions on most qualifying activities, reduced personal income tax on employee salaries, simplified currency operations, and a clean IP assignment framework that works well for international owners. There’s also an annual contribution to the HTP development fund, calculated as a percentage of revenue — that’s how the system funds itself.

The catch is scope. Your company has to operate within an approved list of IT activities. That list is broad — software development, consulting, R&D, fintech, cybersecurity, AI, and most things adjacent — but it isn’t infinite. If the business model wanders outside the approved boundaries, residency is at risk. For most software-focused ODCs this isn’t a real constraint. But you should go in clear-eyed.

The official HTP site at park.by carries the current activity list and application requirements. The English version is decent. Even so, we’d recommend working with a local advisor on the actual filing.

The setup, step by step

Eight steps. Realistic timing on each.

Step 1: Pick your legal structure. The vast majority of ODCs here are set up as Limited Liability Companies (LLCs). It’s the simplest path, permits 100% foreign ownership, has reasonable capital requirements, and meshes cleanly with HTP residency. Joint Stock Companies and branch offices exist as options too, but unless your headquarters structure demands one of those (a regulatory wrinkle in your home country, say), LLC is the default. Budget about a week for this decision, mostly because the right answer depends on what your parent entity looks like.

Step 2: Decide on HTP residency early. You can register the entity first and apply for HTP afterward — but it’s cleaner to plan both in parallel from day one. The HTP application demands a business plan, a defined activity scope, and a clear ownership structure. Working backward from those requirements will shape your incorporation paperwork. For almost every foreign company, pursuing HTP residency is the right call.

Step 3: Prepare incorporation documents. The founders’ resolutions, articles of association, charter, and other basic documents. Notarized and apostilled documents, along with attested translations into Belarusian or Russian, are required when the creator is a foreign entity. Although an LLC’s minimum authorized capital is small, most ODCs commit a larger amount to show local stakeholders how serious they are. Two to three weeks is realistic here, and most of that time is just waiting on translation and apostille turnaround back home.

Step 4: Register the entity. Filing happens with the local registration authority in the city where your office will be — Minsk, usually. Registration itself takes a few business days. After that, you’ve got tax registration, statistical reporting, and a bank account to open. The bank account is almost always the slowest piece, since foreign-owned entities go through extra compliance review under National Bank of Belarus rules. Plan three to four weeks total, from filing to a functioning bank account.

Step 5: Apply for HTP residency. Submit the business plan and supporting documents to the HTP administration. The supervisory board reviews applications on a regular schedule. Approval generally runs four to six weeks — sometimes faster if your application is clean and the activity scope lines up neatly with the approved list. A weak business plan or a fuzzy activity scope is the most common reason for delay.

Step 6: Set up HR and payroll infrastructure. This is where companies routinely underestimate the work. You need employment contracts that comply with Belarusian labor law, a payroll system that handles both local taxation and HTP-specific deductions, and a clean onboarding process for new engineers. Most foreign ODCs outsource payroll to a local provider in year one and only bring it in-house once they’ve reached scale. Our outstaffing and HR support services exist precisely for this part of the journey.

Step 7: Hire the first team. Country lead first — ideally before any of the engineers. Sourcing those first hires through a local recruitment partner shortens this stage considerably, because you skip the steep learning curve of figuring out where Belarusian engineers actually look for work. Our IT recruitment service runs this end-to-end. From kickoff to the first engineer’s start date, plan on eight to twelve weeks.

Step 8: Operationalize the office. Purchasing equipment, security, IT infrastructure, and deciding whether to operate a real office or go remote initially. Both the Belarusian labor code and the HTP framework explicitly support remote work, and most modern ODCs are now hybrid or remote by default. If you do want physical space, Minsk has well-developed coworking and serviced office options at sane rates.

Realistic timeline from decision to a fully operational ODC: four to six months. We’ve seen faster setups when every piece falls into place, and longer ones when the legal structure is unusual or the HTP application needs revision.

What it actually costs

Real cost ranges. Not estimates pulled from a brochure. These reflect what our clients have actually paid to set up Belarus ODCs in 2025 and 2026.

Compliance and audit overhead in year two, currency conversion friction (usually 0.5 to 1 percent on each transfer), and travel for headquarters leadership to visit on a quarterly basis are a few hidden expenditures that don’t appear in first quotations but consistently appear in actual budgets. None of these are deal-breakers. But added together, they tend to run $30K to $50K a year that companies routinely forget to plan for.

For broader benchmarking on Belarus’s IT sector economics, the Belarusian state statistics service publishes sector data that’s useful for sanity-checking your assumptions.

When an ODC is right — and when something else is better

In many of our initial calls, we advise the customer not to pursue a complete ODC, at least not for the first 12 months. Here’s the framing we use.

Direct B2B contracts or an EOR arrangement outperformed an ODC on all metrics for one to five engineers working on project-based work. Setup is faster, cost is lower, and you can scale down without legal baggage. For five to fifteen engineers where you’d rather not manage a foreign entity, a PEO arrangement is usually the smart play. The PEO carries employment, payroll, and compliance while you run the engineering work.

ODCs come into their own when you’re hiring 10+ engineers, planning to operate for at least three years, and want full ownership over hiring, IP, and culture. Around that headcount, the economics flip — the per-engineer overhead of contractor or EOR setups starts to exceed the fixed cost of running your own entity.

The cleanest route is really phased for many businesses. To test the team and the market, start with EOR or PEO. Once the long-term commitment seems genuine, move into a full ODC. We’ve guided a number of clients through this identical process, and it usually yields greater results than setting up the ODC right away.

Five mistakes we see on repeat

After enough setups, the same handful of mistakes show up again and again.

Skipping HTP residency because the application looks complicated. The tax savings on a three-year horizon usually clear six figures, even for small ODCs. And the application really isn’t that hard with a competent local advisor walking you through it.

Hiring engineers before the entity is fully operational. We’ve watched clients try to compress timelines by running recruitment in parallel with incorporation. It almost always backfires — engineers want to sign contracts before the company can legally issue them, and you end up in an awkward holding pattern.

Considering the ODC as a remote office instead of a real subsidiary. Belarus has its own labor law, its own tax framework, and its own compliance culture. Using HQ policies to manage a Belarusian company is a surefire way to cause conflict with both employees and authorities.

Underinvesting in the lead role. Everything that comes after is shaped by the first senior hire, including hiring practices, operational pace, and culture. Here, going cheap is without a doubt the most costly error we observe.

Not making plans for the geographic dispersion after 2022. Nowadays, a sizable portion of Belarusian engineers are employed in Poland, Lithuania, Georgia, or other countries. Payroll and contracts must manage that complexity from the outset. If not, retrofitting the structure after the fact will take months.

When to bring in a local partner

The honest answer: for the parts where mistakes cost the most.

You can handle the legal incorporation with any reputable Minsk law firm, and plenty of companies do. The harder piece to manage internally is the combination of HTP application, local HR infrastructure, and the first wave of hiring — three workstreams that all need to happen in parallel and all depend on a working knowledge of the local market.

Specialized partners like us deal with that combination on a regular basis. We’ve supported ODC setups for dozens of clients, and we typically run the HR, payroll, and recruitment layers while a local law firm handles incorporation. If you want to talk through whether an ODC is the right move for your situation, reach out and we’ll give you a straight read.

Talk to us

We help international companies set up Belarus operations every month. Whether that’s a full ODC, a phased EOR-to-ODC transition, or just figuring out whether the move makes sense in the first place — we’re happy to talk through it honestly.Get in touch for a 30-minute call. We’ll tell you what’s realistic for your timeline, your budget, and your goals, with no obligation attached. If an ODC isn’t right for you, we’ll say so.

How to Hire a Strong Project Manager for an IT Project in Belarus

Every CTO has hired this PM. Stellar CV, six certifications, glowing references. Six months in, they’re a very expensive coordinator with immaculate JIRA hygiene.

Stand-ups happen on time. The Confluence is tidy. Somehow nothing moves any faster than it did before.

It’s so common it’s basically a stage of building a tech company.

The reason isn’t bad luck. The PM market — and the Belarus market in particular — produces a lot of capable process managers and far fewer actual leaders. On paper, they look identical. In a polite 45-minute interview, they sound similar. They cost roughly the same. And there’s no obvious way to tell them apart unless you know what you’re listening for.

Below is how we listen for it. What we ask, what we ignore, what we red-flag. Plus the bits of the Belarus market most foreign hiring teams misread on the first attempt.

What “strong PM” actually means

Before you post anything, get clear on which version of the role you actually want. Three real types, and they don’t cost or behave the same.

The Delivery PM. The classic services-company PM. Owns scope, timeline, client comms, team morale. Makes complex engagements predictable. Most experienced PMs in Belarus came up through this archetype — the outsourcing economy was the schoolhouse. Strong choice for agencies, client-services teams, or any work with a defined endpoint.

The Technical PM. Closer to a tech lead with project skills. Reads code, pushes back on engineering estimates, mediates technical debates without picking sides. Rarer and pricier. The right call when the dev team needs an interpreter, not a scheduler.

The Outcome-Driven PM. The hardest hire. Owns outcomes, not just delivery. Comfortable with ambiguity. Makes prioritisation calls. Pushes back on the business when the spec is bad. The right call for product companies, startups, and anywhere the work isn’t already defined for them.

Here’s the trap most companies fall into: they post for “Senior Project Manager,” interview five people, and hire a Delivery PM when they actually needed Outcome-Driven. That mismatch stays invisible until about month four. Untangling it costs you a year.

The Belarus market over-produces Delivery PMs and under-produces Outcome-Driven ones. Both exist. The ratio is just uneven, and it’s worth knowing before you start screening.

Why Belarus specifically

You probably already have a reason to be reading this, but for completeness:

• Two decades of Western-client services work built a deep PM bench — EPAM, IBA, Itransition, Wargaming, and dozens of smaller shops everyone in the region knows by name.
• English in the PM layer is genuinely strong. Client-facing roles demanded it for years; the bar held.
• Full-day overlap with European hours. Partial overlap with US East Coast.
• Salaries run 40–60% below US tier-1 cities and 30–45% below Western Europe at comparable seniority.

HTP residency still offers real tax advantages for legal employment, both for the employer and the engineer (or PM) at the same gross rate.

The honest part nobody puts in their marketing copy: a meaningful share of senior PMs relocated in 2022–2024 to Poland, Lithuania, Cyprus, Georgia. They’re still Belarusian by training, language, and network — just employed under different jurisdictions now. Practically, that’s usually a feature, not a bug, for foreign hiring teams. The talent is more reachable than it was three years ago. The legal model just changed.

We’ve placed hundreds of PMs and IT roles across this region. The geography hasn’t gotten worse for hiring. The logistics have just shifted.

Writing a JD that doesn’t repel the right people

The job description is where most companies quietly lose strong PMs without realising it. Three rules:

• Be explicit about which archetype you’re hiring. Don’t write “manages projects from concept to delivery” and hope the right type self-selects. Say what you want.
• Be specific about methodology. “We run Scrum with two-week sprints, retros every other Friday, one production release per sprint” gives a candidate something to react to. “Familiarity with Agile methodologies” attracts everyone who took a four-hour course on Udemy.
• Be specific about scope. Team size. Number of stakeholders. Whether they own the roadmap or execute someone else’s. Those three numbers tell a candidate more about fit than any responsibility list will.

Common mistakes worth skipping:

Listing both PMP and CSM as required. Signals you don’t know what you want. Both are perfectly fine credentials — see PMI and Scrum.org — but they certify different things and “both required” reads as a shopping list, not a role.

• “5+ years experience” with no context on what kind of experience. Senior agency PM and senior product startup PM aren’t the same job.
• Eighteen-bullet responsibility lists, half of which contradict each other.
• Treating PMs as fungible with Scrum Masters or Product Managers. They’re not, and we’ll come back to that in the FAQ.

Lead with the work, not the perks. Engineers don’t change jobs for the foosball table. Neither do PMs.

The interview that actually filters

This is where most teams get it wrong, so this section runs a bit long. Worth it.

Three stages. Drop the brainteasers.

Stage 1: Project deep-dive (45 minutes)

Pick one project from their CV. Just one. Go deep:

• “Walk me through this project. Why did the company decide to do it?”
• “What was your role on day one vs day 60 vs day 180?”
• “What decisions did YOU personally make? Not the team — you.”
• “What did you get wrong, and what did you do about it?”
• “If you ran it again, what would change?”
• “How did you measure success? Who decided what success even meant?”

This stage on its own filters out around 60% of weak PMs in our experience. The pattern is consistent. They can’t talk about specific decisions because they didn’t make any. They can’t articulate failures because they don’t reflect on their own work. They retreat into JIRA-and-process language because that’s where they feel safe.

Stage 2: Live scenario (45 minutes)

A real situation, not a brainteaser. Something like:

“Your dev team tells you in a Wednesday standup they can’t ship feature X by the deadline two weeks out. The client is expecting it and has built a marketing campaign around the launch. The CEO doesn’t know yet. Walk me through the next 48 hours.”

Things to watch for:

• Do they go to data first, or jump straight to solutions?
• Do they manage up (CEO needs to know), or do they hide it?
• Do they negotiate with the dev team, or just take the estimate at face value?
• Do they reframe the problem — scope down? phase it? buy time? — or just communicate the delay?
• How do they handle the client conversation? Defensive or assertive?

There’s no right answer to the whole scenario. There are roughly 15 signals embedded in their response that separate strong PMs from process managers. You’ll start seeing them by the third candidate.

Stage 3: Stakeholder role-play (30 minutes)

Someone on your team plays a difficult stakeholder. A frustrated engineering lead. A scope-creeping client. A CEO making last-minute changes the night before launch.

Watch how the candidate handles direct disagreement, pushback, awkwardness. This is the hardest stage to fake. It’s also the best predictor of how they’ll behave with your actual team six months in.

Bonus question worth slipping in: “What do you read or follow about PM craft?” Strong PMs have opinions about specific people — Marty Cagan at SVPG, Lenny Rachitsky’s newsletter, that kind of thing. Weak ones say “I read a lot of articles.” Pattern-matches on real names; doesn’t pattern-match on generic ones.

Red flags vs green flags

Two columns. The single most repurposable visual in this post.

Salaries (quick)

Numbers move every quarter. Our salary research has the current ranges by archetype, seniority, and location. Three rules of thumb that hold across cycles:

• Outcome-Driven PMs cost 15–25% more than Delivery PMs at the same seniority. They’re also harder to find.
• Relocated PMs (Warsaw, Vilnius, Limassol) cost 20–35% more than the equivalent in Minsk. Cost of living indexed; nothing you can do about it.
• Technical PMs run 10–15% over standard PMs at the same level.

HTP-resident employment offers the same tax-efficient setup for PMs as it does for engineers. Which means HTP companies effectively offer more net to the candidate at the same gross rate — worth factoring when you’re competing against local players.

Where the good PMs actually live online

The channel mix is different from engineers. PMs maintain online presences engineers usually don’t.

• LinkedIn. The primary channel. PMs actively maintain profiles, post about their work, and respond to direct outreach. Senior PMs are noticeably more responsive than senior engineers — they’re used to relationship-building as a core skill.
• Telegram channels (CIS PM communities). Less crowded than LinkedIn. Senior+ PMs read them. Knowing which channels matters; that’s where agency knowledge actually compounds.
• Referrals from senior engineering hires. Strong engineers know which PMs they respect. They’re usually right.
• Alumni networks of major Belarus tech employers. EPAM, IBA, Itransition, Wargaming. Anyone who came out of those companies after five years has been trained on enterprise-grade delivery. The bench is substantial.
• Recruitment agencies. Most useful when you need a specific archetype, you’re hiring senior+, or you want someone else to do the Stage 1 filtering before your team spends interview hours. Our IT recruitment team typically delivers first vetted PMs within five to seven business days. That’s a plug. It’s also how the timeline compresses from months to weeks.

If you’d rather start with a flexible model and decide later, IT outstaffing is the other option. Useful when you want a senior PM running an engagement before you commit to full-time headcount.

Bottom line

Strong PMs are findable in Belarus. They just don’t separate themselves from process PMs by CV, certifications, or a polite 45-minute interview. They separate themselves in the deep-dive, the scenario, and the role-play. Run those, and you’ll see the difference. Skip them, and you won’t.

If your hiring team isn’t set up to run that loop — or you’re hiring across multiple jurisdictions, or you just want someone to do the filtering before your team spends interview hours — talk to us. We’ve placed PMs into product companies, agencies, and infrastructure teams across this region for over a decade. Worst case, you get a 30-minute conversation with people who’ve watched this pattern play out a few hundred times. Best case, you skip months of trial and error.

Get in touch — we’ll help you find the PM you actually need, not the one your JD accidentally described.

Building an Employee Referral Program That Works for IT Hiring in Belarus

Every IT employer in Belarus says the same thing in private: the best engineers don’t answer cold emails. They aren’t scrolling job boards on a Tuesday night. They’re heads-down on a sprint, and the only reason they’d talk to you is because a friend whose judgment they trust said you’re worth fifteen minutes.

That’s the whole game behind employee referrals. Done well, a referral program quietly becomes your most reliable source of senior hires — faster than headhunting, cheaper than job boards, and stickier than anything else you can run. Done badly, it’s a poster on the wall and a bonus nobody remembers.

This guide is the version we wish more clients had read before they launched their first program. It’s built specifically for the Belarusian IT context — HTP residency, BYN payouts, the way developers here actually network — and it focuses on what to do this quarter, not on theory.

Why referrals work especially well for IT hiring in Belarus

The Belarusian IT market is, by global comparison, tiny. Most of the senior pool came out of BSUIR or BSU, did time at EPAM or Itransition or a couple of mid-sized product companies, and stayed in roughly the same orbit. People know each other. People talk.

That makes referrals quietly powerful. The standard numbers — referred candidates getting hired at around 30 percent versus single digits for cold applicants, better retention, faster offers — hold up here too. But two things push the effect even further in Belarus.

First, density. A senior Java engineer in Minsk can probably list ten people at their level by name, off the top of their head. One good ask inside that group can reach the entire local market for that role in a week.

Second, trust. A friend’s honest take on your engineering culture and your pay carries more weight than anything your marketing team can produce.

And if you’re a High-Tech Park resident, there’s a bonus on top: your engineers already know peers who would happily switch for HTP tax treatment and benefits. They just need a reason to make the move.

Step 1 — Decide what your program is actually for

The honest reason most referral programs go nowhere is that they were launched without a job to do. The HR team wanted one. The CEO had seen one work somewhere else. So a generic version got bolted onto the careers page, with a generic bonus, for every open role. Two quarters later there’s no clean way to tell whether it worked, because nobody decided what “working” would look like.

So before you publish anything, sit down with the head of engineering and your finance lead, and pick the actual outcome you want over the next two quarters. 

It usually falls into one of four buckets. You’re trying to drop the cost-per-hire on senior IC roles, where agency invoices have started feeling absurd. Or you’re trying to fill stacks that ignore your job ads entirely — Go, Rust, Solidity, ML, senior DevOps, mobile leads, the usual hard-to-source list. Or you’re chasing better first-year retention, on the assumption (well supported by the data) that referred hires stay longer. Or you simply want to stop depending on a single recruiter or a single job board for most of your hires, because that dependency makes the cost line wobble every time the supplier raises pricing.

Pick one. Maybe two. Write it down somewhere your hiring manager and your finance lead can both see.

Then translate it into your actual hiring plan. Six senior backend roles open this year, average agency cost around $9,000 per placement, you fill two of them through referrals — the program has already paid for its bonuses several times over. The math gets convincing quickly once you stop talking in the abstract.

Step 2 — Design the bonus (this is where most programs go wrong)

Belarusian engineers are not naive about money. They know what a Middle Java role pays in Warsaw versus Minsk, and they can do the math on a referral bonus in seconds. Two mistakes to avoid:

• Bonuses that are too small to bother with. A 500 BYN reward for finding a Senior DevOps engineer is, frankly, insulting given what your alternative cost is.
• Bonuses that are too uniform. Paying the same for a QA Manual and a Senior ML Engineer tells everyone the program isn’t serious.

A tiering structure that actually motivates

Build a simple three-tier table by role difficulty, not by seniority alone. Think about how long the role typically takes to fill and what your alternative cost would be (agency fee, lost productivity, founder time).

• Tier 1 — Standard roles: Junior to Middle developers in mainstream stacks, QA, support. Bonus: roughly 1 monthly salary of the hired role, split (more on splits below).
• Tier 2 — Hard roles: Senior developers, team leads, DevOps, iOS/Android leads. Bonus: 1.5–2 monthly salaries.
• Tier 3 — Critical roles: CTO, Engineering Manager, blockchain or Web3 specialists, ML leads, niche stacks. Bonus: 2–3 monthly salaries, sometimes higher for a confirmed senior placement.

Pay it out in a way that protects you

The cleanest structure most Belarusian IT employers use is a split — for example, 30% on the new hire’s start date, 70% after the probationary period (Belarusian labor law allows up to three months). Some companies extend the second payment to month six. Both are reasonable; the goal is to align the referrer’s incentive with the hire actually working out, not just signing.

If you’re an HTP resident, talk to your accountant or your payroll provider before you publish the bonus amounts. Referral bonuses are usually treated as part of compensation and follow standard payroll taxes; structuring them cleanly upfront avoids awkward conversations six months in.

Step 3 — Make referring almost effortless

The biggest mistake companies make when designing referral mechanics is overengineering them. They build a beautiful submission flow with required CV uploads and a “preferred contact method” dropdown, they integrate it with the ATS, they put it behind SSO, and then they wonder why six months in nobody is using the thing.

The senior engineers you refer to are busy. They are mid-sprint. They have a code review open in another tab. The window of attention is about ninety seconds. If your process can’t fit inside that window, the thought passes and the candidate is lost.

So strip the process down. There needs to be one place where the current open roles live and where the bonus for each tier is visible without anyone asking. Notion, an internal wiki page, your ATS portal — it doesn’t really matter which, as long as it’s current. There needs to be one way to submit a referral. Not a form and a Slack channel and an email alias. One. Whichever one your team will actually maintain. The submission itself should ask for two things, the candidate’s name and a way to reach them, and treat everything else as a bonus.

And someone has to reply. Forty-eight hours, every time, even when the answer is no. The single fastest way to kill a referral program — and we have watched this happen at more than one Belarusian IT company — is to leave referrers in silence. They don’t read it as “still in progress.” They read it as “they didn’t take this seriously.” Three weeks of that and you’ve trained your best engineers to stop trying.

This is also where most in-house programs break down. Hiring managers are busy too. Internal recruiters get pulled onto whichever requisition is screaming loudest that week. The 48-hour reply discipline is genuinely hard to maintain without someone whose job it is. If you don’t have that person — or the bandwidth to make it part of someone’s job — outsourcing the inbox to a recruitment partner usually solves more than it costs.

Step 4 — Run it like a product, not a poster

Launching a referral program is easy. Keeping it alive past quarter two is the hard part. Treat it as an internal product with a small set of rituals:

• Monthly hot list. Email or Slack a short list of the three roles you’re most desperate to fill, with the specific stack and the bonus tier called out. Generic “we’re always hiring engineers” messages get ignored.
• Quarterly shout-outs. Publicly thank the engineers who referred someone, hired or not. The social signal that this is a real, valued program is worth more than the bonus itself.
• Onboarding mention. On day one, tell every new hire about the program. New employees come in with the freshest networks — they often refer their best former colleagues within the first 90 days.
• Tie it to the calendar. A small “summer referral push” with a one-month bonus boost on a specific role almost always outperforms a flat program. People respond to deadlines.

Step 5 — Measure four things, ignore the rest

You don’t need a dashboard with 30 metrics. You need four numbers, reviewed every quarter:

• Participation rate — what percentage of eligible employees referred at least one candidate this quarter. A healthy program in a 50-person engineering org sits between 20–35%.
• Referral-to-hire ratio — of referred candidates, how many got hired. Aim for 15–25% on focused roles; below 10% suggests you’re asking the wrong people or the bonus is too low to filter quality.
• Cost-per-hire — total bonuses paid divided by hires made. Compare to your agency or job-board cost honestly, including internal recruiter time.
• 12-month retention of referred hires — almost always higher than other channels, but if yours isn’t, something is broken in your onboarding or your engineers are referring the wrong fit.

Review these numbers quarterly with whoever owns talent. If a tier is underperforming, change the bonus, change the messaging, or change the roles in scope — but change something, and tell the team you did. Programs decay quietly; the response is to visibly iterate on them.

Common pitfalls (and how to dodge them)

• Letting referrals skip the screen. A referral is a warm lead, not a free pass. Run the same technical screen you’d run for any candidate. The fastest way to kill a culture of referrals is one bad hire that the team feels they can’t challenge.
• Quiet rejections. If you reject a referred candidate, send a thoughtful note to the referrer explaining why (in general terms). Engineers respect honest feedback far more than silence.
• Bonuses that arrive months late. The first bonus payout is your most-watched moment. If it’s slow, messy, or under-communicated, the program loses credibility you’ll never recover.
• Counter-offer wars. When a referred candidate gets a counter-offer from their current employer, your existing engineer is suddenly an emotional stakeholder.
• Bias and a narrowing pipeline. Pure referral pipelines tend to look like the people already at the company. Pair the program with intentional outbound on under-represented profiles, and track the composition of your hires honestly.

Layering referrals with the rest of your hiring stack

Referrals are a powerful channel, not a complete strategy. The most resilient IT hiring engines in Belarus combine three layers:

1. Referrals — your highest-quality, lowest-cost channel. Optimized for senior and trust-critical roles.
2. Targeted outbound — a dedicated sourcer or external partner running headhunting for the roles your network can’t cover. This is where an experienced IT recruitment agency earns its keep.
3. Employer brand work — engineering blog, conference talks, GitHub presence. The slow compound investment that makes both of the above easier over time.

If you’re a foreign company hiring into Belarus without a local entity, the operational side — contracts, payroll, social fund contributions, HTP positioning — is the part that quietly slows hiring down even when the candidate is ready to sign. EOR services and on-the-ground HR consulting usually pay for themselves on the first hire, simply by compressing the time from offer to first day of work.

A 30-day rollout plan

If you want to launch a referral program this month, here’s the shortest credible path:

• Days 1–5: Define the goal, the bonus tiers, and the payout structure. Get sign-off from finance and your payroll provider.
• Days 6–10: Build the one-page roles list and pick one submission channel. Write the FAQ.
• Days 11–15: Run a 30-minute all-hands launch. Show the roles, the bonuses, the process. Take questions live.
• Days 16–30: Follow up individually with your top 10 senior engineers. Personal asks convert; mass emails don’t. Track every referral that comes in.

The takeaway

An employee referral program is one of the few hiring investments where the ROI is genuinely obvious within a quarter. The mechanics aren’t complicated — bonus, process, communication, measurement — but the discipline to keep it running well is real. In a market like Belarus, where senior IT talent moves through trusted networks faster than through any job board, the companies that build this muscle simply hire better than the ones that don’t.If you want help benchmarking your bonus structure against the local market, layering referrals on top of targeted outbound, or running the entire IT recruitment pipeline end-to-end, our team does exactly this work every day. Get in touch — or read more on hiring strategy in Belarus on our blog.

From Manual QA to Automation QA: How to Hire (and How to Build the Pipeline Internally)

Hiring an Automation QA engineer used to be straightforward. Post a job, get resumes, pick the one with the most Selenium experience. Done.

That’s not the market anymore.

Senior automation engineers are getting three offers a week. Salaries have jumped roughly 25% in the last two years across most European markets. And every CTO we talk to says some version of the same thing: “We have three great manual QAs who keep asking to learn automation. Why can’t we just train them?”

Sometimes you can. Sometimes you absolutely shouldn’t.

This is a practical guide to both paths, hiring externally and building internally, and how to figure out which one fits your situation. Most teams end up doing both. The ones who get it right plan for that from day one.

Why this is harder than it used to be

A few things changed.

First, the role itself got bigger. An Automation QA engineer in 2026 isn’t just writing Selenium scripts. They’re owning CI pipelines, working with API contracts, sometimes touching infrastructure code. Some teams call this role SDET (Software Development Engineer in Test) and pay accordingly. Others call it Automation QA and pay 30% less for the same expectations. Guess which job posts get ignored.

Second, the talent pool is more global but also more selective. The Stack Overflow Developer Survey has consistently shown QA roles among the harder positions to fill, and remote work means your candidate in Lisbon or Tbilisi can take an offer from Berlin or San Francisco without packing a single box.

Third, and this is where most companies get stuck, the manual QAs you already have are watching. If you go external, the message they hear is “we don’t believe in you.” If you stay internal but don’t actually invest in the transition, they’ll learn automation on YouTube, get a certificate, and leave for a company that pays them like an automation engineer.

So this isn’t just a hiring problem. It’s an org strategy problem.

What “Automation QA” actually means in 2026

Before you write a job description or build a training plan, get clear on what you’re hiring or building toward. Three rough archetypes:

1. The SDET. Closer to a developer. Writes test frameworks, contributes to product code, lives in pull requests. Expect to pay near developer rates.
2. The Automation QA Engineer. Focused on test design and execution, but writes solid code. Owns the test suite, not the application code. Most teams actually need this person and accidentally try to hire an SDET.
3. The Hybrid Lead. Strong manual background, transitioned to automation, now leads a small QA team. Rare, valuable, and usually built, not hired.

Core skill checklist, the realistic version:

• One programming language they actually know — Python, JavaScript, Java, or C#. Not “exposure to.”
• A modern automation framework: Selenium, Playwright, or Cypress. Playwright is winning new projects right now; Selenium still dominates legacy.
• API testing — usually Postman or REST-assured at the code level.
• Git, CI/CD basics, and basic SQL.
• Testing theory — enough to argue intelligently about what to automate. We’ll come back to this. It matters more than the tools.

The ISTQB foundations certification is a decent proxy for that theory, but plenty of strong engineers never bothered with it. Don’t filter on it.

Path A: Hiring externally

The fastest way to add automation capability is to hire someone who already has it. Here’s what realistic looks like.

Timing

A senior automation engineer in a competitive market takes six to nine weeks from job opening to signed offer. Mid-level: four to six weeks. If you need someone shipping tests in three weeks, you’re not hiring — you’re bringing in outstaffed talent or working with a recruitment partner who already has a pre-vetted bench.

Where to look

Eastern Europe — Belarus, Poland, Ukraine — continues to be one of the best price-to-quality regions for QA automation talent. Strong technical education, English fluency, and salary expectations 30–50% below Western European equivalents for comparable skill levels. We’ve placed hundreds of QA engineers from this region into US and EU teams; our salary research breaks down the actual numbers by level and stack.

A job description that doesn’t repel good candidates

Three rules:

• Cut your required skills list in half. If you list 12 things, candidates assume you want a unicorn and skip the post.
• Be specific about the stack. “Experience with various testing frameworks” tells candidates nothing. “We use Playwright with TypeScript, run tests in GitHub Actions, and need someone who can extend our existing page object model” tells them everything.
• Lead with what they’ll build. Engineers want to know about the work, not your foosball table.

Interviews that actually filter

Drop the brainteasers. What works:

• Stage 1: Code review of a real (or realistic) test suite. Ask them what they’d change. Their answer tells you everything about how they think.
• Stage 2: A small live coding exercise — extend a framework, fix a flaky test, or write a test for a given user story. Sixty to 90 minutes, no more.
• Stage 3: Behavioral. Ask about a release that should have been blocked but wasn’t. Ask about a flaky test they had to fight with. Ask how they’d convince a developer to write more testable code.

If your process has more than four rounds, you’ll lose every candidate who has options. Which is all of them.

Red flags worth catching early

• Recites tools and frameworks but can’t explain why they’d pick one over another.
• No public code, no GitHub, no examples — and can’t share even sanitized samples.
• Treats manual QA as a lower form of life. Cultural poison.

If you want to skip the sourcing slog, our QA Automation recruitment team typically delivers first vetted candidates within five business days. That’s a plug, but it’s also how this process compresses from months to weeks.

Path B: Building the pipeline internally

Now the harder, often better path.

Who’s actually a candidate

Not every manual QA wants to or can become an automation engineer. The three signals we look for:

• They’ve already started learning on their own. They’ve written some scripts, taken some courses, asked questions in code review. Curiosity isn’t enough. Action is the signal.
• They’re comfortable with the command line and basic SQL. If they panic at a terminal, the runway is longer than you have.
• They understand why things break, not just that they break. Good test design comes from this instinct. You can teach Playwright. You can’t teach that.

If you have someone with all three, you have an automation engineer in six months. Without those signals, you have a manual QA you’re about to demoralize.

The 6-month roadmap, the actual version

This only works if you protect their time. The single biggest reason internal transitions fail: the trainee is still expected to do their full manual workload while “also learning automation on the side.”

That’s not training. That’s just burning someone out.

What it actually costs

• Trainee time: ~10–15 hours per week for 6 months.
• Senior mentor: ~3–5 hours per week for code review, pairing, and questions.
• Course budget: $500–$1,500 per person. Test Automation University is free and excellent; specific courses on Playwright or Selenium run $50–$200.
• Fully loaded cost: roughly $8K–$15K per person.

Compare that to the $80K–$150K loaded cost of hiring a senior automation engineer externally. The math is brutal in one direction.

Why most internal transitions fail anyway

• No protected time. The big one.
• No assigned mentor. “Just ask anyone on the dev team” is not mentorship.
• No real project to own. Practice exercises don’t teach you what real testing feels like.
• No exit criteria. When is the transition “done”? Without that, it stays in limbo forever.

If you don’t have a senior automation engineer in-house to mentor, internal transition is much harder. This is where some teams bring in an HR consulting engagement to map out the program, or hire one senior externally specifically to be the mentor.

So which path, and when?

A quick framework:

• Need automation live in under 3 months: hire. Don’t pretend training will be faster.
• Have 6+ months of runway and one or two strong manual QAs with the right signals: build. The economics are unbeatable when it works.
• Need three or more automation engineers: blend. Hire one strong senior, upskill two manual QAs around them. That senior becomes both an architect and a mentor — best ROI in QA hiring.
• No senior to mentor and no current automation engineers: hire first, build second. Don’t try to build without a mentor.

Standing up QA from zero: start with a full IT team package or outstaff while you figure out what you actually need.

Most companies pick the wrong path because they’re optimizing for budget instead of timeline, or timeline instead of quality. The right question isn’t “what’s cheapest?” It’s “what’s the actual cost of being wrong in six months?”

The hybrid most teams miss

If you take one thing from this post, take this one.

The highest-leverage QA hire isn’t the senior who writes the most tests. It’s the senior who writes good tests and mentors two or three internal transitions while doing it. That single hire turns into a four-person automation capability inside a year, at roughly half the cost of hiring four people externally.

This works if, and only if, you structure the role that way from day one. Write it into the job description. Bake mentoring into their KPIs. Give them protected time. Pay them like the multiplier they are.

It does not work if you hire a senior and quietly hope they’ll mentor in their spare time. They won’t. They’ll write tests, ship them, and leave when they realize they’re not getting the leadership growth you implied.

Bottom line

There’s no universally right answer to “hire or build.” There’s only the right answer for your timeline, your team, and the QA function you actually need 12 months from now.

If you’ve read this far, you probably have a specific situation in mind. Want a second opinion on which path fits? We’ve spent over a decade helping companies hire QA Automation and QA Manual engineers, build internal pipelines, and figure out the blend. Worst case, you get a 30-minute conversation with someone who has seen this play out a few hundred times. Best case, you skip months of trial and error. Get in touch — we’ll save you the wrong hires.

NDA and IP Assignment Agreements in Belarus: Protecting Code When Hiring Remote Developers

Here’s a sentence that has cost companies their own product: “We paid for it, so we own it.” When the developers writing your code sit in Belarus, that assumption is wrong — or at least, it isn’t automatically right.

The US concept of “work made for hire,” where the employer owns the code the moment it’s written, is not how Belarusian law works. In Belarus, the exclusive rights to what your developer creates belong to your company only if you’ve explicitly said so — in the employment contract, or in a separate IP assignment agreement. Skip that step, or rely on a contractor arrangement with no assignment in it, and the rights can sit with the developer rather than with you. You can pay in full for code you don’t actually own.

Add the question of confidentiality on top — is your source code and roadmap genuinely protected if a developer walks out the door? — and you have two agreements that decide whether you control your most valuable asset or merely hope you do. This guide explains how NDAs and IP assignment actually work in Belarus, the work-for-hire mistake that catches foreign companies out, and what it takes to protect your code when the people writing it are remote. One note up front: this is general information from people who recruit in this market, not legal advice for your specific agreements — for those, use a qualified Belarusian IP lawyer.

The mistake that costs companies their code — you don’t automatically own it

Start with the assumption that does the damage, because almost everything else follows from clearing it up. Foreign companies — especially those used to US rules — tend to believe that paying a developer means owning what the developer produces. Money changes hands, code gets written, the code is yours. Under US “work made for hire,” that’s broadly true for employees. In Belarus, it isn’t the default at all.

Under Belarusian law, the exclusive rights to a work created by an employee belong to the employer only if that’s specified in the employment contract or a separate agreement. There’s no automatic transfer at the moment of creation. The Civil Code governs this — its intellectual-property section was reissued in a new edition that took effect in November 2024, which among other things enshrined a “presumption of creativity”: a work is presumed to be the product of the author’s creative effort unless shown otherwise, and the author holds the exclusive rights by default. The copyright term itself now runs for the author’s life plus seventy years. The thread through all of it: the rights start with the creator, and they only move to you if a document moves them.

The consequence is blunt. Without explicit assignment, you may be paying for code whose rights you don’t hold — effectively licensing your own product from the person you hired to build it, without either of you having meant that to happen. This isn’t a technicality to tidy up before an audit. It’s the difference between owning what you built and discovering, at the worst possible moment, that you don’t.

IP assignment — how to actually own what you pay for

The fix is straightforward in principle and worth getting exactly right in practice. IP assignment is the explicit transfer of the exclusive — that is, the economic — rights from the creator to your company. It can live inside the employment contract, or stand as a separate IP assignment agreement, but either way it has to be explicit, written, and signed. A vague gesture at ownership doesn’t do the job; the assignment has to actually say that the rights move.

A good assignment does a few specific things. It clearly transfers the exclusive rights to the work — the source code, the documentation, the related materials — to the company. It addresses the relationship between the background IP a developer brings with them (their pre-existing tools, libraries, prior work) and the foreground IP created for you, so the line between the two is clear. And it accounts for moral rights: in Belarus, as in much of the world, the author’s personal non-property rights, such as attribution, sit separately from the assignable economic rights and aren’t transferred the same way. A well-drafted assignment is written with that distinction in mind rather than pretending it away.

Two modern points are worth building in. First, AI-generated code: when developers use AI tools, who owns the output is a genuinely unsettled question in 2026, so the agreement should address AI-assisted work explicitly rather than leaving a gap. Second, timing. The assignment should be signed before work starts, not retrofitted once the code exists — a developer who has already written your core module and not yet assigned the rights is in a very different negotiating position from one signing an assignment on day one. Get the paperwork done at onboarding, alongside everything else.

Employee vs contractor — where the rights slip away

The ownership rule has two versions, and the difference between them is where most companies get hurt. It turns on whether your developer is an employee on an employment contract or a contractor on a civil one.

For an employee, the rights transfer to the employer only if the employment contract or a separate agreement says so. So the employment contract has to either contain the assignment or be paired with one — present it as a given, but make sure the document actually exists. For a contractor working under a civil or service contract, the position is sharper still: the rights remain with the creator unless they’re assigned. There’s no version of “the contractor obviously meant to hand over the code” in Belarusian law. If the service contract doesn’t assign the rights, the contractor keeps them, however much you paid.

Here’s why this matters so much for remote hiring specifically: a great many Belarusian developers are engaged as contractors, not employees. That’s precisely the arrangement where IP most easily stays with the developer, because the assumption that payment equals ownership is at its most wrong and the default most firmly favours the creator. Identify which relationship you actually have, and make the assignment explicit either way — but treat the contractor case as the one to be most careful about, because it’s the one that quietly costs companies their code.

NDAs and the trade-secret regime — confidentiality that actually holds

Owning the code is half the protection. The other half is keeping your confidential information — source code, architecture, roadmap, client data — from walking out with a departing developer. Here the news starts good: confidentiality clauses and NDAs are generally enforceable in Belarus. Then comes the catch that most employers miss.

Information is only protected as a trade secret if the company has actually taken steps to keep it secret — a complex of measures the law expects, often called the trade-secret regime. This isn’t a formality. The Supreme Court’s intellectual-property board has held that information which was freely accessible, or which the owner took no real measures to protect, simply doesn’t qualify as a protected trade secret, regardless of what a piece of paper says. An NDA sitting on top of nothing is an NDA resting on air. The signature doesn’t create the protection; the regime does, and the NDA enforces it.

So what does the regime look like in practice? You define what counts as confidential, document it (commonly in an internal regulation on trade secrets), limit access to the people who genuinely need it, and sign NDAs with everyone who sees the protected information — employees and contractors alike. The NDA itself should define what’s confidential, set the scope and how long the obligation lasts (during the engagement and after it ends), and spell out the remedies for breach. Built that way, the NDA does its job because there’s a real trade secret underneath it. Signed without the regime behind it, it’s a comfort blanket, not a defence.

Why you can’t lean on non-competes

One more expectation worth correcting, because companies often reach for it. A non-compete clause — the kind that tries to stop a departing developer from joining a competitor or starting a rival — is subject to strict limitations under Belarusian law. You cannot rely on it the way some US companies do, and treating it as your main line of defence is a mistake.

The protection has to come from the two tools that do work: a strong IP assignment, so the departing developer takes no ownership of your code with them, and a strong confidentiality regime, so they can’t lawfully use or disclose your secrets. Don’t build your strategy on a non-compete that may not hold. Build it on the assignment and the trade-secret regime, which do.

The practical checklist — protecting code when hiring remote in Belarus

None of this is exotic. It’s standard practice, and the companies that come unstuck are almost always the ones who assumed US rules applied. The short version:

• Identify the relationship first. Employee or contractor — the IP rules differ, and the contractor case is the higher-risk one.
• Assign IP explicitly, in writing, before work starts. In the employment contract or a separate agreement; cover source code, documentation, and the line between background and foreground IP.
• Address AI-assisted code in the assignment, since ownership of AI output is still unsettled.
• Build a trade-secret regime, not just an NDA. Define and document what’s confidential, limit access, and take the measures the law actually expects.
• Sign NDAs with everyone who sees confidential information — employees and contractors — with clear scope, duration, and remedies.
• Don’t rely on non-competes. They’re strictly limited; lean on assignment and confidentiality instead.
• Keep the paperwork trail. Who signed what, and when. Clean chain-of-title is exactly what an investor or acquirer will ask to see.

Two scenarios from practice

Scenario A. The contractor who owned the code

A foreign startup engaged a Belarusian developer as a contractor to build a core module, paid in full, and shipped the product. The service contract said nothing about IP assignment — the founders assumed, as founders often do, that paying for the work meant owning it. The product worked, the company grew, and nobody thought about it again.

Then an investor’s due diligence asked for clean chain-of-title to the code, and the gap opened up. Under the civil contract, with no assignment, the exclusive rights to that core module had stayed with the developer the whole time. What should have been a single signature at the start became a renegotiation under pressure, mid-financing, with the developer now holding leverage nobody had intended to give them. The deal survived, but it was a bad few weeks and a worse precedent. The lesson is plain: with a contractor in Belarus, paying for the work is not the same as owning the rights. The assignment has to be explicit — and it costs a signature at the start or a great deal more later.

Scenario B. The NDA that held because the regime was real

A company hiring Belarusian developers did the unglamorous groundwork before it needed to. It defined its confidential information, wrote it into an internal trade-secret regime, limited access to the codebase and the product roadmap to the people who actually needed it, and had every developer sign an NDA tied to that regime. It felt like over-preparation at the time.

It wasn’t. When a developer left for a role at a competitor, the confidentiality obligations were enforceable — not because of the signature alone, but because the company had taken the real measures the law requires, so the protected information genuinely qualified as a trade secret. The NDA wasn’t a standalone scrap of paper; it sat on a foundation that made it mean something. The lesson pairs with the first: an NDA is only as strong as the trade-secret regime beneath it. Build the regime, and the NDA does its job when it matters.

Own it on purpose, protect it for real

When you hire remote developers in Belarus, owning your code and protecting your secrets aren’t automatic — they’re the result of two agreements done properly. IP assignment, because Belarusian law doesn’t hand you ownership the way US work-for-hire does; you have to take it explicitly, and most of all with contractors. And an NDA built on a real trade-secret regime, because confidentiality is only enforceable when you’ve taken the measures the law actually requires. Non-competes won’t save you. The assignment and the regime will.

The companies that keep control of their code are the ones that signed the right paperwork before the first line was written — not the ones who discovered the gap during due diligence or after a developer left. It’s a signature at onboarding versus a crisis later, and the difference between the two is entirely a matter of doing it on purpose, up front. Own it deliberately. Protect it for real. Everything else is hoping.If you’re hiring developers in Belarus and want to do it so your code and your secrets are actually protected — the right agreements, signed at the right time, for the relationship you actually have — get in touch with us. We place IT professionals across the Belarusian market and help employers structure hiring that holds up — including the onboarding paperwork that keeps your IP yours. One more time, because it matters: this article is general information, not legal advice. For your specific NDA and IP assignment agreements, work with a qualified Belarusian IP lawyer who can draft for your situation.

Stock Options and Employee Equity for Belarusian IT Employees: What’s Legally Possible

Equity is a standard part of the package in tech now. Stock options at a startup, RSUs at a scale-up, a slice of ownership meant to tie talented people to the company’s success. For Belarusian IT engineers — among the most sought-after in the region — equity offers are increasingly common, and almost always from a foreign employer or parent company.

That last detail is where the questions begin. Can a Belarusian employee legally receive and benefit from foreign equity? What happens at tax time? Does currency control complicate it? Most equity guidance online is written for someone sitting in San Francisco or Berlin, and it quietly assumes a tax and legal context that simply doesn’t hold when the employee is in Minsk.

This article looks at what’s actually possible — and what’s actually required — for a Belarusian IT employee with equity. The mechanics of options and RSUs, the Belarusian tax reality of foreign-source income, the currency and documentation side, and an honest bottom line: it’s possible and increasingly normal, but it rewards understanding the rules before you sign, not discovering them at tax-return time. One caveat up front, and we’ll repeat it, because it matters: equity taxation is genuinely complex and turns on the specifics of each grant. This is general information from people who recruit in this market — not tax or legal advice for your particular situation.

The mechanics — options vs RSUs, and how equity actually works

Before the Belarus layer, the universal part: what you’re actually being offered. Two instruments dominate, and they behave differently.

Stock options give you the right to buy shares at a fixed price — the strike price — once they vest. If the company’s value climbs above that strike, the options are worth something; if it doesn’t, they aren’t. RSUs, restricted stock units, work the other way around: they’re a promise of actual shares delivered to you on vesting, with nothing to buy. An RSU keeps some value unless the share price falls to zero, which makes it the lower-risk of the two from the employee’s side. Options carry more upside and more risk; RSUs carry steadier, smaller value.

Both come with vesting — the schedule that earns you the equity over time, typically three to five years, often with a one-year cliff. The cliff means nothing vests in the first year; stay past it and the equity starts accruing, usually monthly or quarterly, until it’s fully vested. So the lifecycle runs grant, then vesting, then — for options — exercise, then eventually sale. Each of those points can carry tax consequences, and understanding which instrument you hold and where you are in its lifecycle is the foundation everything else sits on. Get that clear first; the Belarusian layer attaches to specific points along it.

The foreign-company reality — why this is almost always cross-border

Here’s the fact that shapes everything else for a Belarusian employee, and the one the Western guides skip entirely. Your equity almost always comes from a foreign company — a foreign startup, the foreign parent of a local entity, a foreign client that became an employer. That single fact is what pulls Belarusian rules into the picture.

Foreign-issued equity is foreign-source income and foreign property. Which means the rules that apply to it aren’t only the issuing company’s home-country rules — they’re also Belarus’s rules on how its tax residents are treated on income and assets from abroad. And tax residency is a low bar to clear: spend more than 183 days in Belarus in a calendar year and you’re a Belarusian tax resident, taxed on your worldwide income. For most Belarusian IT employees, that includes the equity. So the mental model isn’t “I have shares in a US company, so US rules apply.” It’s “I’m a Belarusian tax resident receiving foreign-source income, so Belarusian rules apply too” — on top of whatever the issuing country does.

The tax reality — foreign-source income, self-declared

This is the central section, and the one to read most carefully. Income that a Belarusian tax resident receives from a foreign source — including income in kind, such as shares or securities — is foreign-source income subject to Belarusian personal income tax, at the standard rate of 13%. (The High-Tech Park rate has historically been lower and has shifted in recent years, so the exact rate for HTP-linked employees is worth confirming for the current year; the IT-sector tax picture is covered in our overview of taxes in IT companies in Belarus.)

The part that surprises people most is who handles it. Foreign-source income is self-declared. The foreign employer doesn’t withhold Belarusian tax — it can’t — so the obligation sits with the employee. In practice that means filing a personal income tax return by 31 March of the year after the income arose, and paying the tax by 1 June. Miss those and the problem is yours, not the company’s. Equity income doesn’t arrive with Belarusian tax already handled the way a salary does; it arrives as something you have to declare yourself.

Then there’s the currency question, which has a precise answer. Foreign-currency amounts are converted into Belarusian rubles at the official National Bank exchange rate on the date the income is actually received — and for income in kind, such as shares, that date is when the shares are transferred to you. So the value you declare isn’t a round number you choose; it’s the market value on a specific date, converted at a specific rate. Belarus also has a wide network of double-taxation treaties — around seventy — which matter where you’ve also paid tax abroad, because they bear on whether and how you can credit that foreign tax. That, too, is grant-specific.

Here’s where the honesty has to be loudest. Exactly when the taxable moment falls — at vesting, at exercise, at sale, or some combination — and exactly how the value is measured at that moment is genuinely intricate, and it varies by instrument and by the structure of the plan. This is not a place for a rule of thumb. The principle is clear and worth internalising: foreign equity income is taxable in Belarus and you declare it yourself. The application to your specific options or RSUs needs individual professional advice. Anyone who tells you otherwise about a complex cross-border equity grant is overselling their certainty.

The currency and documentation side

Beyond the tax itself, there’s the practical machinery of holding foreign shares from Belarus — and it rewards being organised from the start rather than scrambling later.

Receiving, holding, and eventually selling foreign shares — usually through a foreign broker — sits within Belarus’s currency-regulation framework, the same framework that governs other cross-border financial flows. It doesn’t make equity impossible; it makes it something to handle deliberately. And the documentation burden is real. To declare correctly you’ll want the grant notice, the vesting reports, the broker statements, and proof of any foreign tax you’ve paid — kept from the moment of grant, not assembled in a panic the following March. Reconstructing a multi-year vesting history from memory at tax time is exactly the kind of avoidable pain that turns a good opportunity into a stressful one.

One more practical thread: because tax residency turns on days of presence, anyone whose work involves real mobility — time abroad, relocations, remote stints in other countries — should keep records of it. Border crossings, travel documents, the basic trail. Residency can be the difference between owing Belarusian tax on the whole grant and owing it on part, and the records are far easier to keep as you go than to reconstruct after.

What’s possible — and what to be realistic about

So, the honest payoff to “what’s legally possible.” It is possible, and increasingly normal, for a Belarusian IT employee to receive and genuinely benefit from foreign equity. This isn’t a grey area to be nervous about; it’s an established part of how international tech compensates talent, and Belarusian engineers are well inside that world.

What makes it work smoothly is unglamorous: a clearly documented grant from a reputable foreign employer, understood up front, with the tax and currency steps planned rather than discovered. What to stay realistic about is equally plain. The tax is self-declared, and that obligation is yours. The value is often illiquid — shares in a private company can’t be turned into cash until a liquidity event like an IPO or acquisition, which may be years away or may never come. The FX and documentation steps are real work. And the rules can change, as rules do. None of that makes equity a bad deal. It makes it a real one — an opportunity that rewards going in informed rather than dazzled by the headline number.

For employers and recruiters — offering equity to Belarusian talent

The other side of the table matters too. Foreign companies recruiting Belarusian IT talent can offer equity, and increasingly need to in order to compete with the firms that already do. But there’s a right way to do it, and it isn’t just attaching a big notional number to the offer.

The companies that get value from equity offers to Belarusian hires are the ones that present them clearly — with documentation the employee can actually use for their Belarusian obligations, and with honest framing about tax, vesting, and liquidity. The recruiter’s role in that is real: explaining the equity component credibly, setting realistic expectations, and not overselling. A candidate who understands their offer — including the Belarusian tax and currency reality — values it correctly and doesn’t feel misled a year later when the tax return lands. That’s the same standard of clarity we bring to placing IT professionals generally; our IT recruitment services are built around matching strong candidates with roles where the whole package, equity included, is understood on both sides. And because the legal frame around hiring matters as much as the offer, our guides to the probationary period in Belarus and to background checks and candidate verification cover the adjacent ground every employer hiring here should know.

Possible, increasingly normal, and worth understanding first

Equity for Belarusian IT employees is legally possible and increasingly part of the landscape — almost always foreign-sourced, which is exactly what brings Belarusian tax and currency rules into play. The income is taxable and self-declared, the value converts to rubles at the National Bank rate on the date of receipt, and the documentation matters from the very first grant notice. The taxable-event mechanics are genuinely complex, so individual professional advice on a specific grant isn’t a nicety — it’s the sensible default.

For employers, offering equity to Belarusian talent is a competitive advantage when it’s done clearly and documented honestly. For candidates, it’s a real opportunity — best understood before signing rather than puzzled over a year later. The headline number on an equity offer is where the conversation starts. What it means for someone sitting in Belarus is where the real understanding begins.

If you’re a company recruiting Belarusian IT talent and want to build offers — equity included — that candidates understand and value correctly, or you’re navigating the hiring landscape here and want a partner who knows it, get in touch with us. We place IT professionals across the Belarusian market and help employers structure offers that hold up on both sides. A quick, important note: this article is general information, not tax or legal advice — for your specific equity grant, speak to a qualified tax professional who can see the plan documents.

Background Checks in Belarus: Legal Limits and Practical Alternatives for IT Hiring

Hiring a senior developer in Minsk. The standard playbook from back home kicks in. Identity verification. Prior employment confirmation. Criminal record check. Social media review. Maybe a credit check for a senior position. You’ve done this a hundred times. Then the recruiter sends back a polite note. Most of that isn’t allowed under Belarusian law for an IT role. The criminal record check is reserved for specific regulated positions — software developer isn’t one of them. The consent form needs statutory language you don’t have. And the “legitimate interest” basis you’d lean on under GDPR doesn’t exist as a legal basis under Belarusian data protection law at all.

Welcome to the gap between what feels like normal hiring due diligence and what Belarusian law actually permits. It’s wider than most foreign IT employers realise. It’s also entirely workable, once the framework is designed around it rather than retrofitted after the first candidate quietly declines and walks away.

Below: the legal framework that actually applies, what Belarusian law permits and what it doesn’t, the criminal record check question that catches almost every foreign client at kickoff, the cross-border data transfer issue that catches EOR setups, and the practical alternatives that produce better hiring decisions than US-style document screening ever did. Plus two possible cases from practice — including one where the playbook had to be torn up after six weeks of wasted recruitment effort.

The three laws that actually govern this

Three pieces of Belarusian legislation control what an employer can and can’t do when screening candidates. Foreign IT employers typically know about none of them at the kickoff call. Worth getting straight before the first job offer goes out.

The Labor Code

Article 26 lists the documents an employer can require from a candidate. The list is finite. Passport (or other ID). Employment record book. Education certificate. Military registration documents where applicable. Social insurance certificate. That’s essentially it. Anything outside this list — including criminal record certificates for a general IT role — needs a specific legal basis. You can’t add documents to the list as a contractual condition just because your global HR policy says so.

The Personal Data Protection Law (PDP Law)

Law No. 99-Z of 7 May 2021. GDPR-structured, but materially different in critical respects. The biggest difference for employment screening: legitimate interest isn’t a legal basis for processing personal data under Belarusian law, the way it is under GDPR. Consent is the practical foundation for almost everything an employer does beyond what Article 26 directly requires. The law reaches Belarusian and foreign employers handling Belarusian residents’ personal data — extraterritorial in the same way as GDPR is, with the same implications for offshore EORs and parent companies.

Edict No. 422 of 28 October 2021

The administrative framework. Supervisory authority is the National Personal Data Protection Center. Practical responsibilities for the data controller — your employer entity — include maintaining processing records, documenting consent, securing data transfers, and being able to demonstrate compliance on request. The Edict and its implementing acts are tracked on

The Belarusian national legal portal; the Center publishes its own guidance and supervisory materials at cpd.by.

What you can actually screen for

The operational core. What’s permitted — with the right consent framework — for an IT role in Belarus. Read this carefully. The shape is narrower than you think going in, and broader than you’d guess once you see it laid out.

Standard verification under Article 26

• Identity through passport. Part of the standard document set. No additional legal hook needed.
• Education certificates and diplomas. Also Article 26. Verifiable directly with the issuing university — most universities in Belarus and abroad will confirm a degree on request.
• Employment record book confirming prior Belarusian employment. The Belarus-specific document the candidate has. You look at it. Standard.

Permitted with proper consent

• Reference checks with prior employers. Written consent, prior employer willing to engage. Works well when the prior employer is responsive — which in the Belarusian IT market they often are, because the market is small and people stay in touch.
• Verification of professional certifications. AWS. Microsoft. Google Cloud. ISTQB. CKAD. The candidate cited them; the certifying body confirms them. Standard practice.
• Review of publicly accessible social media. LinkedIn, public GitHub, public X. Even publicly accessible content is still personal data being processed — needs consent and needs to be proportionate to the role.
• Technical assessments. Coding challenges, system design sessions, take-home projects. The primary signal for IT hiring, and entirely outside the personal data minefield.

Requires specific statutory basis (not available for general IT roles)

• Criminal record certificate. Only for positions in state security, law enforcement, education, healthcare, finance, customs, and a few other specifically regulated sectors. IT developer, designer, project manager, product manager, QA engineer, data engineer — not on the list.
• Credit history. Generally not permitted for employment without a specific regulatory basis. Senior finance roles within regulated financial institutions are the narrow exception.
• Medical examinations. Only where the role triggers a statutory medical-fitness requirement. Not a generally available employer tool.
• Polygraph or psychological testing. Heavily restricted. Requires specific statutory authority for the role. The number of IT roles with that authority is approximately zero.

The criminal record question — the mistake every foreign client makes

Foreign IT employers ask for this constantly. Almost always inappropriate. Worth its own section because the mistake is so common, the legal exposure so avoidable, and the conversation so tedious to have on day one of every kickoff.

The Belarusian criminal record certificate comes from the Ministry of Internal Affairs. Around twenty working days to issue. Routinely issued to individuals for their own purposes: visa applications, immigration, foreign employment. The employer-side question is whether you can require it as a hiring condition.

For most IT roles, no.

• There’s no general “we run criminal checks on everyone” model in Belarusian employment law. The check is statutorily tied to specific role categories. Software developer, product manager, designer, QA engineer — those categories aren’t on the list. There’s no umbrella authority for an employer to demand it across the board.
• Asking anyway, as a contractual condition, creates two layers of exposure. PDP Law exposure for collecting personal data without lawful basis. Labor Code exposure for requiring documents outside the Article 26 list as a hiring condition. Neither is theoretical.
• Voluntary provision is a different analysis. The candidate can voluntarily obtain and provide the certificate. The employer can voluntarily receive it. Different rules, different exposure. But genuine consent has to be genuinely voluntary — not extracted under threat of withdrawn offer.
• The narrow exceptions: roles touching state secrets, certain financial-services positions regulated by the National Bank, security roles in critical infrastructure, healthcare-adjacent IT roles handling sensitive medical data. Each requires its own analysis.

This comes up in almost every kickoff conversation with a new foreign IT client. The instinct comes from US, UK, or German hiring practices where pre-employment screening is the cultural default and nobody questions it. In Belarus the default is narrower. The framework is workable — but “run a criminal check on everyone” isn’t the route in, and trying to make it one creates problems faster than it solves them.

Social media checks 

Less black-and-white than the criminal record question. Still tightly regulated. Worth understanding before the recruiter does what feels like normal due diligence and creates a problem nobody noticed.

• Publicly accessible content (LinkedIn, public X, public GitHub) — generally reviewable. But the review processes personal data. Consent and proportionality still apply. You don’t get to wave them off just because the content was visible.
• Private content — off-limits. Friends-only Facebook, locked-down Instagram, private profiles. Attempting access through deception or pretexting creates clear PDP Law liability, and creates an unwinnable conversation with the candidate if it surfaces.
• Cached, archived, or historical content — same rules as live content. Findability isn’t the same as lawful processability. The fact that a Google search turns up a forum post from 2014 doesn’t make it a free game.
• Proportionality. Senior leadership in a public-facing role can justify deeper review. Backend developers can’t. The PDP Law requires the controller to demonstrate the legal basis and the proportionality of the processing — both, not either.
• Documentation. The Center can ask the controller to demonstrate compliance. “We looked at their LinkedIn” needs to fit into a documented framework — purpose, legal basis, retention period.

Cross-border data transfer — the thing that catches EOR setups

The aspect that catches multinational employers and offshore EOR providers more than any other. Personal data of Belarusian residents flowing to a foreign parent, an offshore HRIS, a US-based recruitment agency, an EOR provider sitting elsewhere — all regulated under the PDP Law. None of this is optional.

The framework requires the destination jurisdiction to provide an “adequate level of protection” for data subjects’ rights. Belarusian adequacy criteria aren’t identical to GDPR’s. Practical groupings:

• EU member states. Generally treated as adequate. Council of Europe Convention 108 membership matters here.
• EAEU member states — Russia, Kazakhstan, Armenia, Kyrgyzstan. Explicitly treated as adequate by the framework.
• United States. More nuanced. Depends on the specific entity, contractual safeguards in place, and type of data flow. Don’t assume — verify.
• Other destinations without adequacy — specific contractual safeguards required, or explicit informed consent of the data subject for the transfer.

Practical implication for foreign IT employers. If you’re a US tech company hiring Belarusian developers through a Belarusian EOR, the background screening data flow has to be designed for adequacy from day one. Retrofit fixes are awkward. Experienced Belarusian recruitment partners build this into their workflows automatically. Our EOR and payroll services are structured around exactly this compliance architecture — including the data-flow design for cross-border HR processes.

What actually works for IT hiring — the practical alternatives

Where the article earns its keep. Real techniques that work within the legal framework — and that produce better hiring outcomes than the document-heavy screening foreign IT employers default to.

Technical screening as the primary signal

For IT hiring, this is the single most predictive signal you can generate. Hands-on technical assessments. Live coding interviews. System design discussions for senior roles. Take-home projects with realistic scope. Pair programming sessions with the team the candidate would join. Public GitHub review where the candidate has meaningful contributions. None of this touches the personal data framework. All of it is more predictive of actual on-the-job performance than any document review. Foreign employers underweight this. Belarusian employers don’t.

Reference checks that actually work

Direct calls with prior managers, with the candidate’s written consent and the prior employer’s willingness to engage. Confirming employment dates, role, scope, reason for leaving. Asking specific behavioural questions instead of generic “would you hire them again” prompts — which produce vague positive answers regardless of actual performance. Cross-checking the candidate’s narrative against multiple independent reference points. Allowed. Works. Underused because it takes time.

Identity and credential verification

Article 26 document review handles identity and prior Belarusian employment. For credentials, verify directly with the issuing body — Microsoft, AWS, Google Cloud, ISTQB, vendor certification authorities. Education verification through the university. LinkedIn cross-check on dates, roles, scope using publicly accessible content. All inside the framework.

The probation period as your real safety net

Belarusian labour law allows probation periods of up to three months for most positions. Sophisticated Belarusian IT employers treat the probation period as the real background check — actual performance on actual work, which is more predictive than any document. The employer can terminate during probation with three days’ notice and minimal documentation. Build the probation period into your hiring framework deliberately and you get the equivalent of due diligence without the personal data exposure. Most foreign clients underuse this. The ones who get it right structure performance milestones at thirty, sixty, and ninety days, and treat the decision at day ninety as the real hiring decision.

Working with an experienced local recruitment partner

Belarusian senior IT talent is a relatively small market. Senior developers in Minsk are largely known quantities within the local community — references travel through industry networks rather than through formal channels. A local recruitment partner with established relationships can vouch for candidates based on long-term market knowledge no foreign recruiter can replicate. Concerns from prior placements surface naturally. Our IT recruitment service and HTP recruitment specifically are built around exactly this kind of local-market depth. Hard to retrofit; obvious in the results.

HTP-specific considerations

Brief but worth flagging — the firm’s audience overlaps heavily with Hi-Tech Park residents.

Hi-Tech Park residency simplifies many HR processes and brings real tax benefits. It does not change the PDP Law framework. HTP residents handling personal data operate under the standard constraints — same consent requirements, same Article 26 limits, same cross-border transfer architecture. HTP’s flexibility on labour terms (foreign worker hiring, contract types, remote work) doesn’t extend to relaxing personal data processing rules. Some new HTP residents assume residency benefits cover this too. They don’t.

Our HTP residency support covers the application and entry process. The HR processes inside the HTP framework still follow the standard PDP Law architecture.

The consent document — where most of the legal work lives

The single document doing most of the heavy lifting in any IT screening process. Get this right and the rest of the framework holds together. Get it wrong and you’ve built a hiring process on sand.

A working consent for personal data processing in IT hiring should:

• Identify the data controller — the employer entity, or the recruitment agency where the agency holds controller status.
• List the categories of personal data being processed. Identity data. Contact data. Professional data. Educational data. Reference data. Specific, not generic.
• State the purposes for processing. Recruitment evaluation. Employment relationship. Payroll. Regulatory compliance. Each purpose stated, each justifiable on its own.
• Identify the legal basis — consent under the PDP Law, plus statutory basis for Article 26 data where applicable.
• List third parties who will receive the data. EOR provider. Payroll provider. Parent company. Recruitment agency. Background verification provider where used. All named.
• Specify cross-border transfer destinations and the legal basis for transfer. Adequacy, contractual safeguards, or explicit consent.
• Set the retention period explicitly. For unsuccessful candidates, only as long as necessary for the recruitment process and any defensive purpose — six to twelve months is a typical range. For successful hires, the data shifts into the employment-relationship framework.
• Inform the candidate of their PDP Law rights. Access. Correction. Deletion. Withdrawal of consent. Each spelled out.
• Allow the candidate to consent to specific processing types separately where appropriate. Social media review as a discrete opt-in, for example.

Drafting that doesn’t meet these basics creates PDP Law exposure. We’ve seen consent forms drafted by foreign HR teams that wouldn’t survive a first read by the Personal Data Protection Center. The standard isn’t aspirational — it’s the operating baseline. Anything less and you’re relying on the Center being too busy to look.

Two possible scenarios 

Scenario A. The US fintech that learned the hard way

US fintech, series B, rolling out a global hiring program. Standard internal policy: criminal background check required for every role, every country, no exceptions. The US-based recruiter sent the consent form to the first Belarusian senior developer candidate — strong technical fit, six weeks of pipeline work behind them. The candidate read the form. Declined politely. Withdrew from the process. The recruiter flagged the issue. Five other shortlisted candidates raised the same concern in the next ten days. We were brought in to redesign the screening framework for Belarus. Keep the technical assessment depth — the part that actually produces signals. Keep the reference framework. Dropped the mandatory criminal check. Restructured the consent document to meet PDP Law standards. The role filled six weeks later. The framework now applies across the company’s other CEE hiring.

Scenario B. The Berlin scale-up with the proper EOR setup

Berlin-based scale-up hiring twelve Belarusian developers through a Belarusian EOR. German hiring instinct centred on prior-employer references as the primary signal. We helped structure the consent framework to meet PDP Law standards. Set up the cross-border data transfer architecture to enable the German parent to access HR data through compliant channels. Built the three-month probation period into the hiring workflow as the practical performance filter — milestones at thirty, sixty, and ninety days, with the day-ninety conversation as the real hire-or-not decision. Twelve months later: eleven of the twelve hires are still in role, and three have been promoted to senior positions. The framework that looked restrictive on paper proved entirely sufficient in practice when combined with strong technical assessment and structured probation.

Different profiles. Same underlying lesson. The Belarusian framework works when designed correctly from the start. The mistake foreign IT employers make isn’t failing to follow Belarusian law — it’s assuming their home-country playbook will translate without redesign. It won’t. But the redesign isn’t that hard, once someone walks them through it.

The decision framework — what to actually screen for

Practical checklist. Cut this out and give it to your recruiter.

Always (legally clean for any IT role)

• Article 26 document verification — passport, education, employment record book.
• Direct verification of education with the issuing institution.
• Direct verification of professional certifications with the certifying body.
• Technical assessment proportionate to the role.
• Reference checks with the candidate’s written consent.
• Documented consent for personal data processing meeting PDP Law standards.

For senior or sensitive roles (with a proper consent framework)

• Detailed reference checks with multiple prior managers.
• Public profile review with documented proportionality.
• Architectural and leadership-decision discussions for technical leaders.
• Multi-stage interview process, including non-technical leadership conversations.

For specific regulated roles only

• Criminal record certificate — only where statutorily required for the role category.
• Financial regulatory checks — only for regulated financial services positions.
• Healthcare-specific screening — only for roles handling sensitive medical data with a statutory basis.

Never (without specific statutory authority)

• Mandatory criminal record checks for general IT roles.
• Credit history checks.
• Polygraph testing.
• Mandatory medical examinations beyond labour code requirements.
• Private social media access through any means.
• Pretexting, deception, or undisclosed third-party investigation.

Frequently asked questions

Can we require a Belarusian criminal record certificate for a senior developer role?

Not as a legal matter. The certificate is required by statute for specific position categories — state security, law enforcement, education, healthcare, finance, customs — and a senior developer isn’t one of them. Asking for it as a contractual condition creates exposure under both the Labor Code and the PDP Law. Different analysis if the candidate volunteers the certificate. But volunteering has to be genuinely voluntary.

Our US parent runs background checks on everyone. Why can’t we do the same in Belarus?

Different legal framework. US background screening is built on the Fair Credit Reporting Act and a nearly universal culture of pre-employment due diligence. Belarusian employment law restricts what an employer can demand to a finite list. The PDP Law further restricts processing. The US, UK, and German playbook doesn’t translate without redesign. The framework is workable — just not by porting the US version wholesale.

What if the candidate volunteers their criminal record certificate?

Different analysis. Voluntary provision is permitted. But voluntary has to be genuinely voluntary — not extracted under threat of withdrawal of the offer. And the employer’s subsequent processing still requires consent and proportionality. Most foreign IT employers we work with abandon the criminal check altogether for general IT roles once they see what compliance actually requires. The information value is rarely worth the design overhead.

Does the PDP Law apply if we’re using a US-based recruitment agency?

Yes. If the agency processes the personal data of Belarusian residents, the law applies to that activity. Extraterritorial reach similar to GDPR’s. The agency must be set up to comply with proper data processing agreements between the agency, the EOR (if one exists), and the parent company. All three sides of the triangle need to be aligned.

How long can we retain data on unsuccessful candidates?

Only as long as necessary for the recruitment process and any related defensive purposes. Six to twelve months is a typical range, though the right number depends on the role and any potential dispute risk. The retention period should be specified explicitly in the consent document. Indefinite retention isn’t permitted, and “we keep CVs forever” is the kind of thing that catches you in a Center audit.

What happens if we get this wrong?

Administrative liability under Belarusian law, supervised by the National Personal Data Protection Center. Specific penalties depend on the violation type, the controller’s scale, and whether the violation was systematic. The reputational exposure with candidates is sometimes more significant than the legal exposure — Belarusian IT talent is sophisticated about data protection and notices when employers overreach. Word travels in a small market.

The framework that actually works

Belarusian law on background checks is more restrictive than foreign IT employers expect. That’s the honest framing. The fix isn’t a workaround or a clever document — it’s designing the screening framework around what actually works in this jurisdiction. Strong technical assessment. Direct credential verification. Reference checks are built on real conversations. A consent document that meets PDP Law standards. A probation period structured deliberately as a real performance test.

The IT employers we see succeed in Belarus aren’t the ones with the most thorough US-style background check apparatus. They’re the ones who designed for Belarus from the start — and who built their screening around the things that actually predict on-the-job performance rather than the things that feel reassuring in an HR audit.

If you’re building out IT hiring in Belarus and want to design the framework correctly from the start, get in touch. Short scoping call, framework review, structure recommended. Most foreign IT employers benefit substantially from that conversation happening before the first candidate hits the pipeline. After the first candidate walks it is later than it needs to be.