Passing Technical Interviews With US and European Companies

Most people who fail these interviews are not failing on knowledge. They are failing on legibility.

The interviewer has forty-five minutes to decide whether you can be trusted with production systems and a mortgage-sized salary. They are not grading your solution the way a lecturer grades an exam. They are collecting evidence, under time pressure, about whether working with you would be productive. Almost everything that goes wrong in these loops goes wrong because the candidate optimised for the wrong thing.

So, stage by stage, what is actually being measured.

The loop, decoded

Most US and European engineering loops look roughly like this. Not every company runs every stage, and startups compress the middle.

Stage	What candidates think it measures	What it actually measures
Recruiter screen	Whether you are qualified	Whether you are real, available, affordable and coherent
Technical screen	Whether you can solve the problem	Whether you can reason out loud under mild pressure
Take-home or pair programming	Whether your code works	How you make decisions and what you consider "done"
System design	Whether you know the right architecture	Whether you can navigate ambiguity and trade-offs
Behavioural	Whether you are nice	Whether you have actually owned things and learned from failure
Manager or culture chat	Whether they like you	Whether you will be low-drag to manage remotely

Every one of those right-hand columns is a different skill from the left. Train the right column.

Stage one: the recruiter screen

Twenty to thirty minutes, non-technical, and candidates treat it as a formality. It is not. A meaningful share of rejections happen here and almost none are about engineering.

The recruiter is checking four boxes. Are you real. Are you available in a workable time frame. Is your salary expectation inside the band. Can you explain what you do clearly to a non-engineer.

That last one is the killer. If a recruiter cannot summarise your last two years in one sentence after speaking to you, they cannot sell you internally, and you will not move forward regardless of how good you are.

Prepare a ninety-second answer to "tell me about yourself". Timed, out loud, several times. Current role and stack, one thing you own, one thing you shipped that mattered, what you are looking for. Do not narrate your career from university. Nobody asked for a chronology.

Have your number ready. They will ask about compensation and hesitation costs you. If you have not calibrated it, the directional bands and the anchoring rules are here, and the main rule is that you never anchor on your current local salary.

Ask what the process is. How many stages, who with, what the technical screen format is, what the timeline looks like. Recruiters answer this happily and it lets you prepare specifically instead of generally.

One aside on recruiters, since it matters here. Whether a recruiter actually prepares you depends on how they are paid. Agencies that earn a one-time placement fee from the employer, which is how Addis-based Zemenay Tech and firms like it are structured, have every reason to brief you properly on the loop, because they are paid when you are hired and kept, not when you are submitted. Recruiters who earn per submission behave exactly as you would expect. Ask who is paying them, early, and you will know which kind you are dealing with.

Stage two: the technical screen, and the one habit that fixes everything

Forty-five to sixty minutes, live, usually a coding problem in a shared editor.

Here is the thing I most want you to take from this article, because it is the most common and most fixable gap I see in candidates across the region.

You have to think out loud, continuously, and most people do not.

The habit many of us were trained into is to sit with a hard problem quietly, work it through in your head, and present a clean answer once you are sure. In school this is correct behaviour. It avoids wasting anyone's time with half-formed ideas.

In a US or European technical interview, it reads as being stuck.

The interviewer cannot see your thinking. All they observe is a candidate who went silent for four minutes. They cannot distinguish "quietly designing an elegant solution" from "completely lost and too proud to say so", so they assume the second one and start dropping hints, which makes everything worse.

Meanwhile, the grading rubric at most of these companies has an explicit line item for communication. Silence does not score zero on it. It scores badly on it.

What thinking out loud actually sounds like

Not a monologue about your feelings. A running commentary on decisions.

"Okay, we need pairs summing to a target. Brute force is nested loops, O of n squared, works but I doubt that is what you want. Let me try a hash map instead. If I store what I have seen as I go, then at each element I check whether the complement exists, that gets me to a single pass. Edge case where the same element is used twice, I will handle that by checking before I insert. Let me code it."

Thirty seconds, and it has already demonstrated complexity awareness, trade-off reasoning, edge case thinking and a plan. Even if the code that follows has a bug, you have banked most of the signal.

When you genuinely get stuck, say that too. "I am not seeing the optimal approach yet. Let me talk through what I have ruled out." Being visibly stuck and methodical scores far better than being invisibly stuck. Interviewers hire people they can debug problems with. Show them what that is like.

Practise the talking, not just the problems

You cannot switch on continuous narration for the first time in a real interview while also solving an unfamiliar problem. Cognitive load will take the narration first, every time.

So practise out loud. Record yourself solving a medium problem while talking, and watch it back once, which will be unpleasant and useful. Do mock interviews with another engineer, in English, where they flag every silence longer than fifteen seconds. Ten of those change how you interview permanently.

Also do enough pattern practice that the problems themselves are not novel. Not because interviews are a good measure of engineering, they are not, but because you cannot narrate a problem that is consuming all of your attention.

Stage three: the take-home or pair programming

The take-home is not testing whether your code works. That is table stakes. It is testing your judgement about what "done" means when nobody is watching.

What actually gets read: whether there is a README explaining how to run it and what you decided, whether there are tests covering the right things rather than everything, whether the obvious error cases are handled, whether the structure is proportionate to the problem, and whether you stayed in scope.

Over-engineering fails take-homes as often as under-engineering does. A clean, well-tested, boring solution with a clear README beats a clever architecture with no documentation. Write a short "trade-offs and what I would do with more time" section at the bottom of the README. It converts everything you did not build into evidence of judgement rather than gaps.

When to decline a take-home

Be direct about this. There is a version of the take-home that is exploitative, and you are allowed to say no.

A reasonable take-home is three to five hours, scoped and stated. If a company asks for twenty hours of unpaid work, or the task is suspiciously close to a real feature in their product, or there is no stated time limit and the scope keeps growing, you are being used as free labour or tested on your willingness to be.

The professional way to decline:

"Happy to demonstrate the work. Given the scope, would you consider a time-boxed version of about four hours, a paid engagement at my normal rate, or a live pair programming session instead?"

Companies acting in good faith accept one of those immediately. Companies that refuse all three have told you something useful about how they treat people who work for them.

Stage four: system design

The most misunderstood stage. Candidates think they are being asked for the correct architecture. There is no correct architecture. They are watching how you behave when the problem is deliberately underspecified.

The sequence that works:

Ask questions first. Several. Who uses this, how many of them, read heavy or write heavy, what is the latency expectation, what has to be consistent, what is out of scope. Spending five minutes here is not a delay, it is the first thing being graded. Candidates who start drawing boxes immediately are demonstrating exactly the instinct that causes expensive mistakes at work.

State your assumptions out loud and write them down. "I am assuming ten million users, a hundred to one read to write ratio, and that we can tolerate a few seconds of staleness. Tell me if that is wrong."

Start simple, then scale under pressure. Draw the smallest thing that works, then let the interviewer push. When they say "now it is a thousand times bigger", you add caching, then replication, then sharding. Arriving with a fully distributed architecture in minute one skips the entire conversation they wanted to have.

Name trade-offs explicitly. "I will use a queue here so writes stay fast, which means the client sees eventual consistency, which is fine for a notification but not for a balance." That sentence is worth more than any diagram.

Do not bluff. If you have never run Kafka, say "I have not used Kafka in production, but the property I want here is a durable ordered log, so something in that family". Honest boundaries plus correct reasoning scores well. Confident nonsense fails instantly and burns the rest of the loop.

Stage five: behavioural, without sounding rehearsed

The structure people teach is situation, task, action, result. It works. The problem is that a rigidly delivered STAR answer sounds like a recital, and interviewers have heard ten thousand of them.

Use the structure as scaffolding, not as a script. Context in one or two sentences, enough for a stranger to picture it. Then the complication, meaning what made it hard, which is the part that carries all the interest and the part people rush. Then what you did, specifically, in first person singular, because "we" is the enemy of the behavioural interview and a wall of it makes your actual contribution invisible. Then the outcome, with a number if one exists. Then one line of reflection on what you would do differently, which is the sentence that separates senior-sounding answers from junior ones and which most candidates omit because they think admitting anything is a weakness. It is the opposite.

Prepare six stories, not twenty. A conflict with a colleague. A project that failed or slipped. A time you pushed back on a decision. Something you shipped under real constraints. A time you were wrong about something technical. Something you learned fast because you had no choice. Almost every behavioural question maps onto one of those six.

Rehearse the stories, not the sentences. Memorised wording sounds memorised. Know the shape and you sound like someone remembering.

Talking about work at a company nobody has heard of

A real disadvantage, and fixable in about two sentences.

When you say "I worked at [company]", a European interviewer gets zero information. They cannot tell whether that was a serious engineering organisation or a two-person shop, and the uncertainty does not resolve in your favour by default. So supply the context yourself, immediately and without defensiveness:

"It is a fintech in Addis with about forty people, twelve engineers, processing card and mobile money transactions for a few hundred thousand users. I owned the reconciliation service."

Twenty seconds, and now they can calibrate everything you say afterwards. Do the same on every story: users, transactions, team size, uptime requirements. Numbers are the universal translator between markets.

When your company was genuinely small, do not inflate it. Reframe it. Small companies mean broad ownership, which engineers from large companies often lack. "I was the only backend engineer, so I owned the schema, the API, deployment and on-call" is a strong sentence. Say it with a straight face, because it is impressive.

The same principle applies to your written application, and we went through it properly in writing a CV for someone with no local context.

The logistics, which lose more offers than people admit

None of this is glamorous. All of it is disqualifying when it goes wrong.

Audio matters more than video. Bad video is forgivable, bad audio ends the interview emotionally even if it continues technically. Wired headphones with a mic beat laptop speakers and most cheap Bluetooth. Test on a recorded call, not in settings.

Quiet room, controlled light. Light in front of you, not behind. A window behind you turns you into a silhouette for an hour.

Confirm the time zone in writing. Ethiopia, Kenya and Uganda are all UTC+3. Restate it in your confirmation email: "Confirming Tuesday 15:00 CET, which is 17:00 my time." Missing an interview over a time zone error is entirely avoidable and entirely fatal.

Have a connection backup and announce it. This is the part people get wrong by staying silent. Say it in the first thirty seconds:

"Quick note before we start: I have mobile data as backup, so if my connection drops I will rejoin within a minute, or dial in by phone. Here is my number just in case."

Ten seconds of preparation that converts a potential disaster into a demonstration of competence. If it does drop, do exactly what you said, rejoin, say "sorry, I was at the point of checking the edge case", and continue. Do not apologise three times. Interviewers remember composure far longer than a dropped call.

Charge everything, and know your power situation for the hour. If you are somewhere with scheduled outages, book around them.

Questions that make you sound senior

You will be asked if you have questions. "No, I think you covered everything" reads as low interest. Ask things only someone who has done the job would think to ask:

• What would success look like at the end of the first ninety days
• How do decisions get made when engineering and product disagree
• What does on-call look like, and how often does it actually fire
• How long does it take to get a change from merged to production
• What is the largest piece of technical debt the team is living with
• How does the team work across time zones, and what has to be synchronous
• Why is this role open

That last one is worth asking every time. The answer tells you whether you are joining a growing team or replacing someone who left in frustration, and the way it is answered tells you even more.

Ask two or three, not seven. It is a conversation, not an audit.

The uncomfortable summary

The candidates who pass these loops are not the ones who know the most. They are the ones who are easiest to evaluate.

Legibility is the skill. Narrate your reasoning. Supply context that a stranger cannot infer. Give numbers. Say the awkward thing about your connection before it becomes awkward. Admit what you have not done, and reason well about it anyway.

Practise out loud until it stops feeling strange. That one change will do more for your offer rate than another three hundred problems.