How to Read Tech Job Descriptions as a Developer

Decoding requirements, understanding what employers really mean, and positioning yourself to get the interview

Here is something that happens to almost every developer in Kenya at some point.

You are browsing LinkedIn or MyJobMag, you find a role that sounds interesting, you start reading the requirements, and somewhere around the third bullet point you quietly close the tab. Five years of experience. Bachelor's degree in Computer Science or related field. Proficiency in React, Node.js, Python, Docker, Kubernetes, AWS, and four other tools you have heard of but never used professionally. Strong communication skills. Team player. Self-starter.

You think that is not me and you move on!!

This is one of the most expensive mistakes a developer in Kenya can make. Not because every job description is secretly achievable by anyone but some roles genuinely are out of reach at certain stages. But because most job descriptions are written by someone who wanted a perfect candidate, not someone who expected to find one. And the gap between what is written and what actually gets you hired is wider than most beginners realize.

This guide is about reading job descriptions the way a hiring manager actually thinks about them, positioning yourself honestly and strategically, and understanding the real hiring landscape in Kenya so you can work within it without losing hope.

Why Tech Job Descriptions in Kenya Look So Intimidating

Before you learn how to read a job description, you need to understand why they are written the way they are.

In most Kenyan companies, job descriptions are written by HR, sometimes by a recruiter, occasionally by the hiring manager, and rarely by someone who has a precise idea of what the role actually requires day to day. They pull from old postings, borrow from other companies, and add requirements because they sound relevant, not because every item on the list will actually be tested.

The result is a document that describes an ideal candidate who probably does not exist. Someone with five years of experience, a degree, three frameworks, cloud certifications, and the personality of someone who works great independently and in a team simultaneously. Companies post this hoping to attract the best possible pool of applicants, then they make tradeoffs in the actual hiring process based on who shows up.

Understanding this changes how you read every line.

Decoding Common Developer Job Requirements

Let's go through the things you will see most often in tech job descriptions and what they actually mean.

"5 years of experience required"

This is the one that stops the most people. Here is the honest reality.

Experience requirements are almost always a proxy for something else. What the employer actually wants is a developer who can work independently, handle unfamiliar problems, write code that does not break everything, and not need hand holding on basic concepts.

When a company says five years, they are trying to filter for that level of ability. But here is the thing two years of building real projects, working in a team environment, shipping features, and debugging production problems often produces that ability. A candidate with two strong years and a solid portfolio will get an interview for many roles listed as requiring five.

The rule of thumb used across the global tech industry is worth knowing: if you meet about sixty to seventy percent of the listed requirements, you are a reasonable candidate. Below that, the role is probably a stretch for now. Above that, apply without overthinking it.

Five years listed, you have two solid years? Worth applying if everything else aligns. Five years listed, you finished a bootcamp three months ago? That is a genuine gap, and your energy is better spent on junior focused roles.

"Bachelor's degree in Computer Science or related field"

Related field is doing a lot of work in that sentence. Business, mathematics, information technology, engineering most hiring managers interpret this broadly. And as covered in the previous guide, a strong portfolio often overrides the degree requirement entirely at the point where a technical manager gets involved.

Apply unless the company is a large corporate or multinational with strict HR gatekeeping, where the filter genuinely does happen at the CV screening stage.

"Proficiency in [long list of tools]"

When you see a list of eight technologies, the honest interpretation is that the company uses some of them, wants familiarity with others, and wrote the rest in because they seemed relevant. Nobody is proficient in all of them. Nobody is expected to be.

What matters is your core stack. If you are strong in React and they list React alongside six other things, you are relevant for that role. Do not disqualify yourself because you have not touched one tool on a list of ten.

"Strong communication skills"

This is in almost every job description and it is very important. It does not mean you need to be a public speaker. It means: can you write a clear email, explain a bug without confusing everyone, ask a question without wasting people's time, and participate in a meeting without going silent?

If English is a second language for you, this is not a barrier. Clear and simple beats impressive and confusing every time.

"Team player and self starter"

This is contradictory on purpose, and most companies know it. What they actually mean is: we do not want someone who shuts down without being given exact instructions, and we also do not want someone who ignores everyone else and does things their own way. In practice it means: show that you have worked with other people and also that you can solve problems independently. Your portfolio and your cover letter are where you demonstrate this.

"Experience with Agile or Scrum"

If you have not worked in a formal Agile environment, this is not a blocker. It means: understand how software teams organize work in sprints, communicate progress, and handle changing requirements. You can learn the basics of Agile in a weekend. Mention it in your cover letter if it comes up.

The Difference Between Must Haves and Nice-to-Haves

Most job descriptions mix two kinds of requirements without telling you which is which.

Must haves are the things the role genuinely cannot function without. If the job is building a React frontend and you do not know React, that is a real gap. If the role involves managing cloud infrastructure and you have never touched AWS or GCP, that is a real gap.

Nice-to-haves are the things that would make you a stronger candidate but are not dealbreakers. Usually these appear toward the bottom of the requirements list, sometimes under a heading like "Bonus points" or "Advantageous." Sometimes they are mixed into the main list without any label.

Your job when reading a description is to separate these two categories. Ask yourself: if I came in not knowing this specific thing, would the role be impossible? If yes, it is a must-have. If the company could train you in two weeks, it is probably a nice-to-have.

Focus your positioning on the must-haves. Be honest about the nice-to-haves and show willingness to learn.

How to Position Yourself When You Do Not Tick Every Box

This is where most developers in Kenya lose momentum. They read the description, identify three things they cannot fully claim, and either do not apply or apply with an apologetic energy that comes through in the cover letter.

Neither approach works.

Here is a better framework.

Lead with what you can do. Your CV, your cover letter, and your GitHub should front-load your relevant strengths. If the role needs React and Python, and you have both, those should be visible immediately. Do not bury the lede.

Address gaps briefly and honestly. If there is a tool or skill listed that you are still learning, a single sentence acknowledging it and showing that you are actively working on it is better than either hiding it or dwelling on it. "I am currently building with Docker and deploying on AWS in my personal projects" is a perfectly reasonable thing to say.

Show local relevance. This is underused and genuinely powerful in the Kenyan market. If your portfolio includes M-Pesa integrations, Daraja API work, Africa's Talking automations, or anything that reflects how Kenyan businesses and users actually work, mention it. It signals product fit in a way that generic project work does not.

Match your language to theirs. If the job description uses specific words "microservices," "REST APIs," "CI/CD pipeline" and these things appear in your actual experience, use the same language in your CV. Not to game a system, but because it makes it easy for the reader to connect your background to their needs.

The Honest Truth About How Jobs Are Filled in Kenya

This is the part most career guides skip, and it is too important to leave out.

In Kenya, a significant number of tech roles are filled through networks before they are ever publicly advertised. Someone knows someone. A hiring manager reaches out directly to a developer they met at a meetup. A referral comes through WhatsApp before the LinkedIn post goes up. An internship turns into a full role quietly, without a job description ever being written.

This is real. Acknowledging it is not cynical it is just honest about how the market works.

And here is the important thing: knowing this should not make you give up on public applications. It should tell you where else to put your energy.

The people who benefit from connections and referrals in Nairobi's tech scene did not get there by accident. They showed up at GDG Nairobi events. They shared what they were building on LinkedIn. They contributed to community projects. They helped someone debug a problem in a developer WhatsApp group. They were visible and useful before they needed a job.

Connections are built before you need them, not when you are desperate for them. If you are building in public, engaging in tech communities, and showing your work consistently, you are doing the work that eventually makes someone think of you when an opening comes up.

So do both. Apply through every formal channel you can find. And simultaneously, invest in being visible in spaces where Kenyan tech people gather.

A Practical Checklist Before You Apply

Before you submit for any role, run through this quickly.

Do you meet sixty percent or more of the listed requirements? If yes, apply.
Is your core stack genuinely relevant to the main responsibilities? If yes, apply.
Do you have at least one deployed project that demonstrates the kind of work the role involves? If yes, make sure it is in your CV and cover letter.
Can you explain in one paragraph what you would bring to this specific team? If yes, write that paragraph and use it.
Are there gaps you cannot honestly claim? Note them briefly in your cover letter, frame them as areas you are actively developing, and move on.

On Rejection and What to Do With It

You will apply for roles and not hear back. You will get to interviews and not get offers. This is not evidence that you do not belong in tech. It is just how hiring works everywhere, and it is especially common in entry and junior-level markets where supply of candidates outpaces available roles.

The developers who break through are not the ones who applied once and waited. They applied to fifteen roles while finishing their third portfolio project. They asked for feedback when they got rejected. They went back to communities, kept showing up, kept building. And eventually the timing, the skills, and the right opportunity aligned.

The market in Kenya right now is competitive and sometimes feels closed. It is not closed. It is selective. And selectivity rewards people who stay in motion, stay visible, and keep improving.

Do not let a job description that lists years of experience make you feel like an imposter. Use it as a map. Understand what it is actually asking for. Be honest about where you are relative to that. Position yourself well, apply strategically, and keep going.

Final Thoughts

Reading a job description well is a skill. Most people treat it like a checklist that either includes them or excludes them. Treat it like a document to decode understanding what the employer actually needs, what they are willing to compromise on, and how to make the case that you are worth talking to.

Kenya's tech market has real barriers. Connections matter. Timing matters. But skills and portfolio and strategic positioning matter too, and those are things you can control and build.

Apply more than you think you, should position yourself honestly, build in public, show up where developers gather, and do not close that tab the moment you see a requirement that does not perfectly describe you today.