Ernesto Spruyt, Author at Tunga

Why Your Certificates Don’t Matter (And What Actually Does)

Posted on February 16, 2026 - 9:22 am by Ernesto Spruyt

A lot of developers believe certifications are a meaningful lever for getting hired internationally.

They are not.

Hear me out.

Certificates can help you pass an automated screen. They signal you’ve invested time in learning. But once a human is involved, once someone is actually deciding whether to hire you, they rarely move the decision in the way people think they do.

What moves the decision is simpler, and harder: how you show up, and how you operate.

And those are not the same as “more credentials”.

The Nairobi moment

Last week I was in Nairobi for the Africa Tech Summit. We organized a side event through Tunga Academy on landing international tech jobs. The response was overwhelming: we had to close registration at 450 people.

The room was packed. Mix of junior, mid-level, and senior developers. Most had never worked for an international client.

During the panel discussion – myself, Timothy Maenda from StartHub, and Irene Mwangi from Power Learn Project – I brought up something that comes up regularly in our conversations with developers.

Certifications.

“In real hiring decisions,” I said, “I’ve almost never seen a certificate make the difference. Neither have my clients”. All three of us were unanimous. But the room struggled to accept it.

Someone asked: “Then why is it always listed in job descriptions?” (my answer: “Out of habit”)

This moment has stayed with me because it reveals something bigger. Developers are investing enormous energy in the wrong places. Not because they’re foolish (they’re anything but). But because they can’t see what the hiring side actually focuses on.

What we actually look for at Tunga

When we evaluate candidates for international roles, we’re trying to answer two practical questions fast.

1) How do you show up?

Not as a personality assessment. As signal quality.

Can I quickly understand who I’m dealing with? Can you communicate like someone who has thought about the other side of the screen?

At the Nairobi session, we put a few LinkedIn profiles on the screen, volunteers from the audience. One had a photo, but the person was standing too far away. “I can’t see who you are,” I said. There was not a clear signal of intent, context, or seriousness about the role they were seeking.

People recognized it immediately. Some uncomfortable laughter.

The point isn’t grooming or polish. The point is awareness. Remote work is mostly communication. If your primary professional surface doesn’t communicate clearly, you are losing points before anyone has even spoken to you.

2) How do you operate?

This is what we generally – though perhaps incorrectly – call “soft skills”.

It’s not soft. It’s delivery.

Can you find your own work when things get quiet? Can you surface blockers early, clearly, and with options? Can you manage expectations without waiting to be asked? Can you ask good questions when context is missing?

Here’s an example from Tunga’s everyday practice: the client says their developer isn’t productive enough. At the same time, the developer is frustrated because they don’t have enough work.

What’s happening is usually not laziness or incompetence. It’s a mismatch of assumptions.

The client expects the developer to proactively identify tasks, ask questions, create clarity. The developer expects the manager to assign work when there’s more to do.

Both make sense inside their own frames. But in a distributed environment, those frames collide. And the collision looks like underperformance on the part of the developer.

In international teams, taking initiative is not a bonus. It is expected.

Why this gap exists

Problem-solving is a skill. Like any skill, it requires repetition. And repetition depends on your training environment.

I learned this partly through a football academy project in Uganda. Ugandan coaches kept asking: why don’t more of our talented players make it to European leagues? European clubs want players who make autonomous decisions under pressure, in real time. That ability is trained through practice.

But in Africa, in many educational contexts (both in schools and at home) the pedagogical culture tends to be hierarchical. Initiative is regularly penalized instead of encouraged. Taking risks and making mistakes often isn’t safe. The result is less practice in autonomous decision-making.

The same pattern shows up regularly in candidates wanting to join our platform: strong technical competence, but weaker autonomy in collaboration.

This isn’t permanent. But it is what needs addressing. That’s why we started Tunga Academy.

The market paradox

Eleven years ago when we started Tunga, there was a shortage of strong developers across Africa. Today, the situation has flipped.

The talent pool has grown enormously. But local job markets haven’t kept pace. The promise many developers heard – “learn to code, get a well-paid job” – runs into the reality of limited local demand.

So the pull toward international work grows. And international opportunities do exist. European and North American companies are looking for exactly the technical talent Africa produces.

But the barrier is rarely technical skill. It’s whether people can operate in the collaboration model those teams assume.

If anything, that barrier is becoming more important. As AI handles more standardized technical work, what scales in value is judgment, clarity, initiative, expectation management. The human mechanics.

Where to invest your energy

This is where most developers can make a practical shift.

Less time optimizing for credentials as an end in themselves. More time building stronger self-presentation and stronger operating behavior.

Concretely, that means:

Communication skills: Learn to manage expectations clearly. Practice giving and receiving feedback. Develop the ability to ask precise questions when context is missing.
Assertiveness training: Build comfort with speaking up, challenging assumptions respectfully, and advocating for what you need to do your work well.
Problem-solving practice: Work on real projects where you have to make decisions with incomplete information. Contribute to open source. Build something yourself.
Professional visibility: Improve how you present your work. Document your thinking. Show your process, not just your output.

Certificates can sit somewhere in that picture. But they’re not the lever.

What we do at Tunga Academy

We learned in hospitality how to see across frames and anticipate friction. Tunga Academy applies that: our job is to help people build the signals and behaviors that international teams actually respond to.

Problem-based development, not theory-first. No promises of jobs. Just ruthless clarity about what moves the needle, and structured practice around that. This is why our assertiveness training, for example, has become unexpectedly popular: it fills a gap people feel but can’t always name.

Closing the gap

Standing in that room in Nairobi, I could see both frustration and hope. These developers have worked hard to get where they are.

But the obstacle isn’t what they think it is.

Once you can see that certificates matter less than communication, that grinding technical skills matters less than initiative, the path becomes clearer.

The talent is real. The opportunities are real. What’s needed is seeing what’s actually in the way. That gap is closeable, and now let’s close it!

What Software Developer Job Postings Are Really Telling Us

Posted on February 10, 2026 - 10:53 am by Ernesto Spruyt

We track 1000s of software developer job postings daily across Northern Europe and North America at Tunga. And we talk to the CTOs and founders posting them. Many of those job postings describe an impossible person.

A “Senior ML Engineer” position posted in January 2026 requires “5+ years experience with LLM fine-tuning and RAG architecture.”

But LLM fine-tuning entered mainstream practice in 2023. And RAG architecture achieved production adoption only in 2024.

The mathematics don’t work.

And this isn’t someone being unreasonable. It’s someone who knows the world is changing rapidly but doesn’t have time to fully grasp how. So they list everything they think they might need, just to be safe.

Our data confirms the pattern. Job descriptions in 2025 are 30-40% longer than equivalent roles in 2023, almost entirely from more granular technical requirements. But the technologies specified haven’t existed long enough for developers to accumulate the experience requested.

According to IBM, 99% of developers are still “exploring” AI agent development. Yet postings increasingly demand “experience with agentic AI frameworks.” The agentic coding market is projected to grow from $7.8 billion in 2025 to $52.6 billion by 2030. Tools like Claude Code and Devin achieved production readiness mid-2025. Gartner forecasts 40% of enterprise applications will embed AI agents by the end of 2026, up from less than 5% in 2025.

That’s 700% growth in twelve months. The talent pool cannot have developed proportionally.

What we’re seeing isn’t a description of the current market. It’s anxiety about the future, expressed as present-tense requirements.

The Seniority Paradox

Here’s something we saw recently: a developer who’d been highly successful in a senior role for one of our clients – strong technical work, good communication, reliable delivery – applied for a senior role at a different company. They were rejected for “lack of seniority”.

Same developer. Same skill level. Different company, different outcome.

This happens because “senior” doesn’t mean the same thing everywhere. For some companies it means framework proficiency. For others it means learning velocity and judgment. The distinction matters enormously, but job postings don’t clarify which one they mean.

Over 50% of software developer postings are now senior-level, compared to 30% historically. During the same period, entry-level postings increased 47% from their 2023 lows. Both ends growing simultaneously.

When we analyze postings using “senior,” certain language appears consistently: “fast-growing team” (73% correlation), multiple positions listed (68%), remote work where historically on-site (81%), detailed benefits sections (64%). These correlate with competitive pressure and hiring difficulty, not necessarily work complexity.

And this: 89% of “senior” postings require 7-10+ years experience, but 76% require experience with technologies less than five years old. Companies are designating roles as “senior” partly to signal they’re willing to pay competitively, partly to filter for people who won’t need hand-holding. Whether the actual work requires senior judgment is often a separate question.

What Leadership Doesn’t Know Yet About AI

When we talk to company leadership about agentic AI, there’s a consistent pattern. They know it should be an opportunity to produce code at scale. They know their competitors are exploring it. But they struggle to fully grasp how it actually works in practice.

How do you organize software development when AI agents handle implementation? How do you ensure quality? What does “scalable” even mean in this context? They don’t know what to ask for in hiring, don’t know what to screen for, don’t know how to evaluate it.

So they add “experience with AI agents” to the posting and hope candidates will figure it out.

The disconnect: top candidates leave the market within 10 days of active job search, according to multiple recruiting agencies. Average time-to-fill is 44 days globally. If the best candidates commit in 10 days but your process takes 44, you never meet them. You’re interviewing whoever is still looking in week three.

Glassdoor found company-specific factors (interview stages, stakeholder availability, decision authority, approval processes) explain more variance in time-to-fill than role or candidate factors. Variables entirely within company control.

Specialized agencies report 7-14 day time-to-fill working with identical candidate pools. The difference is process: fewer stages, faster decisions, clearer requirements.

The constraint isn’t talent scarcity. It’s that by the time companies figure out what they actually need and move through their process, qualified candidates have already accepted other offers.

What Companies Say Versus What They Screen For

Communication ranks as the most frequently mentioned skill across nearly 2 million tech job postings. More than Python, JavaScript, or any framework!

Yet most processes screen exclusively on technical qualifications in early stages. Soft skills get evaluated in final rounds, if at all.

Here’s what we see from the developer side: many strong developers focus almost entirely on technical skills. They know intellectually that communication matters, but they have trouble imagining what “soft skills” actually encompasses in practice. What does “strong communication” mean day-to-day? How do you demonstrate “collaboration effectively across teams”? It’s abstract until you’ve done it.

So developers optimize for what they can measure: learn another framework, build another project, get another certification. Meanwhile, companies screen out candidates before their communication can be evaluated, then complain they can’t find people who can communicate.

The shift from execution-focused development (write code to spec) to orchestration-focused development (direct AI agents, communicate across functions, make architectural decisions) makes communication more predictive of success than framework mastery. But neither side has fully adjusted to this yet.

The Subsegment Rebalancing

Machine Learning Engineer postings grew 40% year-over-year (following 78% the previous year). Frontend-only positions declined 24-33%. Full-stack grew 9%, but now means: backend systems + frontend frameworks + AI integration + cloud infrastructure + DevOps fundamentals.

These skills historically developed through different career paths. Companies are asking for combinations that accumulate through distinct specializations, expecting to find them bundled in individual candidates.

Some exist. But at much lower density than posting volume suggests.

What Actually Works

The companies we see successfully hiring do a few things differently:

They separate core from aspirational. Internally, they know what the role genuinely requires day one versus what would be nice to have. The developer with 80% of core requirements plus demonstrated learning velocity will outperform someone with 100% of stated requirements but no adaptation evidence, especially when half the “required” technologies didn’t exist two years ago.

They optimize for process speed. When you know top candidates move in 10 days, every scheduling delay and approval bottleneck becomes visible as the actual problem. It’s not about rushing decisions. It’s about eliminating artificial friction.

They screen for what actually predicts success. If communication matters, evaluate it early. The technical filter that eliminates candidates before their communication can be assessed is screening for what’s easy to measure, not what determines outcomes.

They reconsider where they look. The patterns we observe – impossible requirement combinations, process bottlenecks, screening mismatches – affect local markets everywhere. They’re structural, not geographic.

We work with senior developers in Africa who have 8 years building distributed systems, strong communication developed working with international clients, and are learning agentic AI right now like everyone else. They sometimes get screened out of European and US processes for lacking specific credentials or local experience, while companies complain about talent shortages.

When everyone is learning agentic AI simultaneously (because the tools are six months old) “10 years Silicon Valley experience” stops being the differentiator it was. Architecture skills, communication ability, and learning velocity become primary.

What makes alternative talent models interesting isn’t cost arbitrage. It’s that developers systematically overlooked by credential-focused screening often possess what companies say they need. And they’re available while local markets remain gridlocked.

What This Means for Developers

We see many developers focus intensely on technical skills while underweighting soft skills, partly because “strong communication” or “collaboration” remains abstract until you’ve experienced what it means in day-to-day work with distributed teams.

The reality: soft skills now predict success more strongly than framework mastery. When 73% of backend postings mention “AI collaboration experience,” they’re asking whether you can work effectively in an environment where AI handles implementation while humans handle judgment, communication, and strategy.

Tool expertise has shorter half-life than ever. RAG wasn’t a term in 2023. By 2025 it’s “required.” This pattern continues. What persists: ability to learn tools quickly, understand their constraints, know when to use them.

Specialize in durable layers, not transient tools. The market demands specialization while punishing over-specialization in technologies that change yearly. Specialize in problem domains and architectural patterns: distributed systems, resilient data pipelines, interfaces humans use. Learn current tools to solve those problems, but recognize tools as temporary implementations of durable patterns.

Geographic barriers are narrowing. The “you’re not from here” disadvantage has narrowed substantially. Not because standards dropped, but because barriers that kept people out – local tool experience, local network, proximity – matter less when everyone learns the same new tools simultaneously and teams are distributed by default.

You still need to prove capability through portfolio work, open source, clear communication, and learning velocity. But the window is unusually open right now.

Where This Leaves Us

Job postings describe institutional anxiety, not market reality. They’re written by busy founders who know the world is changing but don’t have time to fully understand how, so they list everything that might matter.

The result: postings that describe impossible people, processes that screen out qualified candidates, and qualified candidates who move through the market faster than companies can respond.

For companies: The ones succeeding aren’t writing better job postings. They’re recognizing the divergence between what postings say and what success requires; then adjusting process, screening, and geographic constraints accordingly.

For developers: Tool mastery has never mattered less and human skills have never mattered more. The market is simultaneously more accessible (geographic barriers down, new tools level the field) and more demanding (communication and adaptability are baseline, not bonus).

The friction we’re seeing creates two futures: one for those stuck optimizing credentials that don’t exist, processes that don’t work, and local talent pools already exhausted. Another for those willing to see what’s actually changing.

When salary data meets real people: navigating African developer compensation

Posted on February 5, 2026 - 8:50 am by Ernesto Spruyt

The negotiation that keeps breaking, and what actually fixes it

Every few weeks, we watch the same pattern repeat. A European company quotes a budget based on “Africa rates.” An experienced developer in Lagos or Nairobi quotes something close to European levels. Both numbers make sense. Both feel fair to the person giving them. And yet the conversation stalls.

The awkwardness isn’t about bad faith. It’s about different maps of the same territory.

If you’re hiring developers from Africa, or you’re a developer navigating international opportunities, you’ve likely felt this friction firsthand. One side expects a significant cost advantage. The other expects compensation that reflects capability, not geography. Both are looking at market data. Both are being reasonable. And yet something fundamental isn’t connecting.

That disconnect is costing both sides opportunities they’d otherwise want.

What you’ll find here

Three things we keep seeing in our daily work placing African developers with European and North American clients:

First: Country-by-country salary bands (low, median, high) for the African markets we work in, normalized to EUR per month. Not perfect data, but honest data.

Second: Why purchasing power and lived costs matter more than most salary discussions acknowledge, and why both developers and companies miss this.

Third: What actually creates the premium in distributed work. It’s not “remote work” as a skill. It’s something more specific, and more human.

The pattern: both sides are using different anchors

Here’s what we hear, week after week:

From developers: “A European developer doing my job makes €70,000. If I’m delivering the same quality work, why should I accept less?”

From companies: “Hiring from Africa means more complexity: time zones, cultural navigation, higher risk of mismatch. The cost advantage should offset that risk.”

Both positions make sense in isolation.

The developer is right that capability should drive compensation. The client is right that distributed work creates friction and uncertainty.

And this is where most salary negotiations get stuck: in the gap between what feels fair based on output and what feels reasonable based on context.

What usually happens next

In our experience, there are two paths from here.

Path one: proactive navigation

Our teams step in early. We paint the picture of what the other side is seeing.

To the developer: “Based on your skills and experience, this is what the market will actually bear. You’re competing globally now, not just locally. If you want to push higher, that’s your choice, but understand what you’re up against.”

To the company: “Here’s what this looks like from the developer’s perspective. They’re leaving a stable job to take a risk on you. This rate reflects both capability and market reality. If you want to negotiate down, you’ll likely lose this person to someone who gets it.”

We’re not pushing anyone. We’re showing them what the other side sees. Usually, that works.

Path two: the negotiation “succeeds” but the relationship doesn’t

Sometimes one side feels they got a bad deal but accepts anyway. The developer takes it because they need the opportunity. Our client agrees because they’re out of options.

Then, a few months in, something breaks. The developer feels undervalued and starts looking elsewhere. Or the client feels they’re overpaying and starts managing to the penny rather than to the relationship.

What looked like a successful negotiation becomes an early termination. That’s the real cost.

Why we track this data (and what it can’t tell you)

We track salary data because it gives both sides a shared reference point. Not a script for what to pay, but a map of what’s actually happening in the market.

Country-level bands exist, but they’re wider than most people expect

What this tells you:

“Africa” is not one price level. Median salaries differ by multiples across countries.
Even within a single country, the spread between median and high can be dramatic.
Some markets have tight bands. Others are two-speed: a small top tier prices into international work, while the median remains locally anchored.

What this doesn’t tell you:

What’s “fair” for any specific person
What drives someone from the median band into the upper band
How to have the actual conversation when expectations don’t match

The data is a starting point, not an ending point.

Cost of living reshapes the story more than either side expects

We include purchasing power comparison not to argue that developers should accept less, but because ignoring it creates distortion on both sides.

When you compare salaries in purchasing power terms rather than nominal terms, the distance between “Africa” and “Europe” shrinks materially in lived terms, even when it remains large in nominal terms.

For developers: European salaries look high in nominal terms. But much of that difference gets absorbed by taxes, rent, and local costs. The gap is real, but it’s not as wide as the headline numbers suggest.

For companies: You’re not getting “cheap” talent when you hire senior, production-ready developers. You’re getting access to capability that’s structurally underpriced; but that mispricing is correcting, especially at the top end.

The top end is pulling away from the middle

In multiple markets, the high end is several times the median. This isn’t trivia. It’s a structural signal.

The market isn’t moving as one block. A small share of developers are increasingly priced on international benchmarks, while the median remains locally anchored.

For companies: Hiring senior “global-ready” profiles isn’t about finding a cheap location. It’s about finding scarce capability. You’re competing with other international companies.

For developers: The path to global compensation is real, but selective. The difference isn’t geography. It’s what kind of responsibility you can carry without constant supervision.

What actually determines the premium (and why “remote” isn’t the skill)

We get asked constantly: what makes the difference between a developer who stays at local pricing and one who commands near-European rates?

The difference is almost always this: can you reduce risk and friction for the people around you, especially when they can’t see you?

Here’s what that looks like:

You ship and support production systems, not just features. When something breaks, you fix it.
You take initiative within boundaries. You don’t wait for instructions, but you ask clarifying questions before you’re stuck.
You communicate proactively. You surface problems early. You don’t let misunderstandings accumulate.
You structure and document your code so someone else can pick it up.

Put differently: you make distributed work easier, not harder.

This is what clients pay for at the top end. Not the ability to write code remotely. The ability to own outcomes when supervision is expensive and trust is essential.

And this is where cultural adaptation matters. European clients sometimes describe African developers as “passive” or “waiting for instructions.” African developers in turn can describe European clients as “demanding initiative without clear direction.”

Both observations are real. The friction comes from different cultural defaults around authority and autonomy. Developers who navigate this well – who can read context, take initiative when needed, and ask for clarity when it’s not – are the ones who break out of local pricing.

The moment things shift: when uncertainty evaporates

Many of our clients have never been to Africa. They’ve never hired from there. “Remote African developer” is an abstraction, and abstractions are uncomfortable. They don’t know what to expect.

Then the first interview happens.

The camera works. The sound is clear. The connection is stable. The developer speaks fluent English, asks smart questions, and demonstrates expertise.

What the client feared was a high-risk unknown becomes a specific person they can evaluate like anyone else.

That shift – from abstract risk to concrete evaluation – is where the salary conversation often becomes easier. Not because the developer proved they’re “cheap,” but because they proved the client’s mental model was incomplete.

For developers: Yes, you’re proving more than a European developer would need to prove. That’s the reality. But once you’re proven, the dynamic changes.

For companies: That first conversation is your moment of recalibration. If you go in expecting problems and come out impressed, adjust your frame. This person isn’t a compromise. They’re capabilities you wouldn’t have found otherwise.

We prepare developers for this. We always do a prep call; checking technical setup, discussing how to show up professionally, and reframing the stakes: if it’s not meant to be, there will be other opportunities.

Why negotiating for the quick win breaks the long game

Here’s something we tell both sides:

Success is not a quick hit in a negotiation. Success is negotiating for a strong foundation for long-term collaboration.

When a client pushes too hard on price, they might “win” the negotiation. But they lose the relationship. The developer accepts because they need the work, but they’re looking for the next opportunity from day one.

When a developer holds out for a number that’s genuinely out of market, they might feel they stood their ground. But they lose the opportunity. Meanwhile, another developer takes the role and builds the track record that opens the next door.

The goal isn’t to squeeze the other side. The goal is to find a number that both sides can live with and build on.

This is what we mean when we say Tunga is human-first. It’s not soft. It’s structural. Relationships that start with one side feeling exploited don’t produce great work.

What we actually do differently

If a client went to a typical recruiting agency, the salary conversation would be: “What’s your budget? We’ll find someone in that range.”

If a developer tried to negotiate directly, the conversation would probably stall on the first number that didn’t match.

What we do is different:

We show both sides the other side’s perspective

We don’t just relay numbers. We translate worldviews.

To a developer: “Imagine you’re the client. You’re looking at a resume from someone you’ve never met, in a country you’ve never visited. What would you be thinking? What would make you feel safe?”

To a client: “This developer has a job. Would you quit your job on a maybe? What would need to be true for that to feel like a good bet?”

That reframing (asking people to inhabit the other perspective) changes the tone. It moves from positions to problems.

We come with context, not just numbers

When we send a client a shortlist of candidates, we include rates upfront. No surprises.

And we explain how we got there. We show the market data. We explain the developer’s background. We translate between the client’s worldview (risk, cost, alternatives) and the developer’s reality (scarcity, opportunity cost, purchasing power).

We’re willing to walk away to maintain trust

If a developer quotes a rate that’s genuinely out of market, we tell them: “That’s your choice. But you should know you’re competing globally at that price. We’re fine if you don’t want to pursue this, but we’re not going to misrepresent the market.”

If a client’s budget is unrealistic, we tell them the same: “You can try, but you’ll either get someone who’s not actually senior, or you’ll lose the people you want.”

We’d rather lose a deal than lose credibility. That stance, being willing to let the deal fall apart rather than distort the truth, is what makes the trust work.

How to read this market (without losing the thread)

If you’re hiring developers from Africa:

Expect meaningful differences by country, and even more by seniority
Treat the median as a baseline and the upper band as the scarcity premium for proven capability
Remember: you’re not hiring “cheap” developers. You’re hiring capability that’s structurally undervalued, and that mispricing is correcting
Budget pressure increases sharply for senior, production-owning profiles. Mid-level hiring still offers advantages, but only if your expectations about autonomy are realistic

If you’re an African developer looking at international opportunities:

Global-level compensation exists, but it’s priced on responsibility and reliability, not location alone
When adjusted for purchasing power and tax, the gap with Europe is smaller than it looks
Only a minority earn at the global top end, and they’re priced on scarcity; the ability to reduce friction and carry outcomes independently
Growth comes from moving into roles where you make distributed teams easier to run, not harder
The most consistent path upward is ownership: shipping, supporting, and communicating under real production conditions

For anyone trying to make sense of distributed work and fair compensation:

Salary data is necessary, but not sufficient. The numbers give you a map. They don’t tell you how to navigate.

What actually makes these relationships work is the layer underneath the numbers: trust, transparency, and a willingness to see the other side’s position even when it conflicts with your own.

Where this leaves us

The data in this post will be wrong within a year. The market moves. Salaries shift.

But the pattern underneath won’t change:

Distributed work only works when both sides treat it as a relationship, not a transaction.

Salary negotiations are not pricing exercises. They’re trust-building exercises. They’re the first test of whether two parties can navigate complexity, misalignment, and uncertainty together.

The teams that do this well don’t avoid the hard conversations. They have them early, honestly, and with respect for what the other side is actually dealing with.