The first time a European engineering lead runs a hiring loop for African candidates, something uncomfortable happens around CV number thirty.
They cannot tell the good ones apart.
Not because the candidates are worse. Because every heuristic they have built over fifteen years of hiring has quietly stopped working, and nobody warned them. The university names mean nothing. The previous employers mean nothing. The CV formats look strange. And in the absence of familiar signal, the brain reaches for whatever is left, which is usually how confident somebody sounds on a video call.
That is not vetting. That is vibes with extra steps.
So here is a vetting pipeline that works across borders, that takes eleven working days rather than six weeks, and that measures things which actually predict whether somebody will be good on your team.
Why your usual signals break
You do not know the universities
You know that a computer science degree from a certain set of schools means something in your home market. You have no calibration for Addis Ababa University, Makerere, Jomo Kenyatta, University of Nairobi, Ashesi, Covenant, or the University of Rwanda.
Two failure modes follow. You either treat all of them as equivalent, which throws away real information, or you unconsciously discount all of them against the schools you recognise, which throws away most of your candidate pool.
The fix is not to learn the ranking of forty universities. The fix is to stop using education as a filter at all past the junior level and replace it with something you can measure directly.
You do not know the employers
A candidate worked at a company you have never heard of. Was that a two hundred person fintech doing serious engineering, or a five person shop building WordPress sites?
You genuinely cannot tell from the name, and neither can your recruiter, and looking up the website tells you almost nothing because small serious companies and small unserious companies have identical websites everywhere on earth.
Ask instead. "How many engineers were on the team? What was the deploy frequency? Who made the architecture calls?" Thirty seconds of questions replaces an hour of guessing.
CV conventions are different
CVs from many African markets follow older, more formal conventions inherited from British and continental templates. Longer. More personal detail. Lists of technologies rather than narratives of impact. Sometimes a photo, a date of birth, a marital status, a list of references with phone numbers.
To a hiring manager used to the modern one page American resume, this reads as unpolished. It is not. It is a different local norm being followed correctly. Penalising it selects for candidates who have been coached on Western CV conventions, which correlates with prior access to Western employers, which is not the thing you are trying to measure.
Confidence is not competence, and across cultures it is not even correlated
This is the big one and almost nobody controls for it.
Interviewers reward candidates who self promote fluently, interrupt comfortably, claim credit directly, and answer with certainty. Those behaviours are culturally learned, not skill correlated. In many East African professional contexts, deferring to seniority, understating individual credit and answering carefully rather than quickly are marks of professionalism, not of weakness.
Put a candidate with those norms into an unstructured interview with an interviewer who reads assertiveness as ability, and you will systematically reject strong engineers while hiring confident mediocre ones. You will also never find out, because rejected candidates do not send you their subsequent career trajectory.
The only reliable defence is structure. Same questions, same order, scored independently before discussion. Boring, and it works.
What to measure instead
Four things, in this order. Everything else is optional.
1. A scoped paid work sample
Not a take home that eats a weekend. A tightly scoped piece of realistic work, four to six hours maximum, paid at a fair rate.
Pay for it. I will keep saying this. Unpaid multi-day take homes select for candidates with free time and no competing offers, which is the opposite of what you want. Paying also changes the relationship: you are buying a few hours of work, which means you can reasonably expect professional quality and reasonably give clear requirements.
Make the task resemble the job. If the role is maintaining a mature codebase, do not give a greenfield algorithm puzzle. Give them a small slice of something realistic: an endpoint to add with existing conventions to follow, a bug to fix in provided code, a component to build against a real design.
What you are scoring: does the code work, is it structured sensibly, did they follow the conventions in front of them, did they ask clarifying questions before starting, did they say anything about the tradeoffs they made.
That last one matters most. An engineer who submits working code plus three sentences on what they would do differently with more time is telling you more than the code does.
2. A walkthrough of something they already built
Forty five minutes. They pick a project, ideally with the code in front of them, and walk you through it.
This is the highest signal per minute of anything in the funnel and it is criminally underused.
You want them to explain the problem, why they made the choices they made, what broke, and what they would change. You want to interrupt with real questions. "Why a queue here rather than a direct call?" "What happens if this request times out halfway?" "Who else worked on this and what did they do?"
You find out fast whether they actually built it, whether they understood it or copied it, and whether they can explain technical decisions to another engineer. Somebody who did the work can go arbitrarily deep. Somebody who did not runs out of detail in about four minutes.
It also neutralises the confidence bias better than anything else, because a quiet candidate talking about their own work gets animated in a way that no behavioural question produces.
3. A live debugging session on real code
Sixty minutes, pairing, on a small repository with a genuine bug seeded in it. Not a puzzle. A plausible bug: an off by one in pagination, a race condition in a background job, a config that works locally and fails in staging.
They get the repo, they get to run it, they get to search the internet, they get to ask you questions. You watch how they work.
What you learn here is not obtainable any other way: how they form hypotheses, whether they read error messages properly, whether they change one thing at a time or flail, whether they narrate their thinking, and how they behave when stuck. Being stuck is the most informative five minutes of any interview, because being stuck is most of the job.
This stage also happens to be the most resistant to AI assisted cheating, which we will get to.
4. Written communication, tested deliberately
Everybody says communication matters. Almost nobody tests it, and then everybody complains about it later.
For an async, distributed team spanning time zones, written communication is not a soft skill. It is the primary interface. A brilliant engineer who writes three word Slack messages and no PR descriptions will cost your team more hours than they save.
Test it directly. Give a short scenario and ask for a written response, thirty minutes, in their own words. Something like: "You picked up a ticket, started work, and discovered the requirements conflict with how the existing system behaves. Write the message you would send to your team lead, who is asleep for the next six hours."
Score it on: did they state the problem clearly, did they include enough context that the reader can act without a follow up question, did they propose an option rather than just raising a problem, is it a reasonable length.
This one question predicts async performance better than any technical stage. It is also the fastest to grade.
The eleven day funnel
Time boxed, with the wall clock budget alongside the effort budget, because they are different problems.
| Stage | Candidate time | Your time per candidate | Elapsed | Pass rate to expect |
|---|---|---|---|---|
| Application screen | 0 | 5 min | Day 1 | 25 to 40 percent |
| Written scenario | 30 min | 10 min to grade | Day 2 to 3 | 50 to 60 percent |
| Project walkthrough | 45 min | 45 min plus 10 to score | Day 4 to 6 | 40 to 50 percent |
| Paid work sample | 4 to 6 hrs (paid) | 30 min to review | Day 7 to 9 | 60 to 70 percent |
| Debugging pair session | 60 min | 60 min plus 15 | Day 10 | 60 to 70 percent |
| Decision and offer | 0 | 30 min debrief | Day 11 | Offer |
Pass rates are directional, drawn from what I typically see rather than from any dataset, and they will vary enormously with your sourcing quality.
Total interviewer effort per candidate who reaches the end: roughly three and a half hours. Total elapsed time from application to offer: eleven working days.
Three rules that make it hold together.
Never leave a candidate waiting more than forty eight hours between stages. The single biggest cause of lost hires is not rejection, it is silence.
Schedule the next stage during the current one. Not afterwards, not by email thread. Put it in the calendar while you are both on the call.
Score before you discuss. Every interviewer writes their score and rationale independently, then you compare. The moment somebody says "I really liked her" before scores are in, the panel converges on the loudest opinion in the room.
Candidate experience, honestly
Strong candidates are not sitting around waiting for you.
A good senior engineer in Nairobi or Addis with English, remote experience and a visible GitHub is being contacted regularly. If your process takes five weeks and involves seven rounds, you will not lose the weak candidates. You will lose exactly the ones you wanted, because they took the offer from the company that moved in ten days.
Some specifics that cost you good people and that you can fix this week.
Unpaid work over four hours. Insulting at senior level, and it filters by free time rather than skill.
Scheduling at your convenience only. UTC+3 gives you real overlap. Use it. Do not make somebody in Kampala take a call at 11pm because your calendar was full.
Silent rejection. Ghosting is a reputational cost in a market smaller and more connected than you think. Every engineering community in every one of these cities talks. A two line rejection email costs you thirty seconds and buys you a referral pipeline.
Vague compensation. Say the range in the first conversation. Both sides are wasting time otherwise, and in cross border hiring the expectation gaps are wide enough that finding out at offer stage is a disaster. If you are unsure what to anchor on, the Ethiopian cost breakdown sets out realistic bands.
No clarity on the employment model. Candidates will ask whether this is a contract or employment, and they care, because it affects their pension, their loan eligibility and their sense of security. Have an answer. The employer of record versus direct hire comparison covers what you are actually offering under each structure.
The AI cheating question, without the paranoia
It is 2026. Some candidates use AI assistance in interviews. Some use it well, some use it to fake competence they do not have, and the discourse about it has gone somewhere unhelpful.
Let us be proportionate.
First: an engineer using AI tools to work faster is not cheating. That is the job now. If your interview process penalises AI use while your actual codebase is built with AI assistance every day, you are selecting against your own working environment. Ban it in interviews and you will hire people who are worse at the job you are hiring for.
What you actually care about is whether they understand what they produce and can operate when the tool is wrong. That is a narrower and much more testable question.
Practical measures, in order of how much they help:
Weight the live debugging session heavily. It is the hardest stage to fake. A model can suggest fixes. It cannot narrate a hypothesis, respond to your interruption, or explain why it ruled out the other three possibilities. Watch the process, not the output.
Interrogate the work sample rather than just grading it. Fifteen minutes on their submitted code. Why this structure, what happens under this edge case, change it live to handle a new requirement. Somebody who generated it without understanding it falls apart immediately and politely.
Allow AI explicitly, and say so. "Use whatever tools you use at work, and be ready to explain every line." This removes the incentive to hide it, which is the behaviour that actually corrupts your signal.
Keep the project walkthrough about their history. No model knows what happened on their team in 2024.
What not to do: proctoring software, eye tracking, demanding screen recordings, three separate identity checks. It is invasive, it is a terrible candidate experience, it disproportionately annoys exactly the senior people you want, and it does not work well anyway. The best defence against faked competence is a process that tests real work under real conditions, which is what you should have been running regardless.
There is a separate and more mundane problem worth naming: identity substitution, where the person interviewing is not the person who shows up. It is rare, it is not region specific, and one video call with a camera on plus consistent voice across multiple stages catches essentially all of it. Do not build a surveillance apparatus for an edge case.
Where a partner earns their fee
You can run all of this yourself. Plenty of teams do, well.
What you cannot easily do yourself is the layer before the funnel: knowing which of two unfamiliar former employers is a serious engineering shop, knowing whether a salary expectation is aggressive or modest for that market and level, and knowing which candidates have actually worked async for a foreign employer rather than just saying so.
That is local market knowledge, and it is what you are buying when a recruiter charges a fee. It is also why the incentive structure of that fee matters. A partner paid on a recurring markup earns whether the hire lasts or not, while one working on a single placement fee with a six month replacement guarantee attached has tied their revenue directly to your vetting outcome. Zemenay's model in Addis is built that way deliberately. When you evaluate any recruitment partner, ask what happens financially if the hire fails at month four, and let the answer tell you how much they believe their own screening. The full landscape of providers is covered in the East African outsourcing company breakdown.
Frequently asked questions
How long should a technical hiring process take? Under three weeks from first contact to offer, and ideally under two. Beyond that you are not selecting for quality, you are selecting for candidates without alternatives.
Should take home assignments be paid? Anything over about two hours, yes. Pay a fair hourly rate for the estimated time. It improves completion rates, improves quality, and removes the fairness objection entirely.
How do I assess English proficiency for remote work? Not with a test. With a written scenario response and a normal conversation where you actually disagree with them about something technical. What you need is somebody who can push back clearly in writing, and that is exactly what those two exercises measure.
Are degrees a useful signal when hiring in Africa? Weakly, and only at junior level where there is little else to go on. Past two years of experience, the work sample and the project walkthrough tell you far more than any institution name you cannot calibrate.
Should I allow candidates to use AI tools during interviews? Yes, explicitly, and then test whether they understand what they produced. Banning it pushes usage underground and selects against the way your team actually works.
One last thing
Most bad cross border hires are not skill failures. They are process failures dressed up as skill failures.
You did not test communication, so you found out about it in month two. You did not watch anyone debug, so you never saw how they handle being stuck. You let confidence stand in for competence because you had no other calibration.
Fix the process and the talent question mostly answers itself.
