Certificates Nobody Asks For: What Kenyan Employers Actually Check

There is a comforting belief among people learning to code: if I collect enough certificates, employers will take me seriously. It makes intuitive sense. In most fields, credentials matter. Doctors need licenses. Lawyers pass the bar. Accountants get CPAs. So surely a coding certificate from a recognized platform must carry weight?

In the Kenyan tech industry, it mostly does not. The startup CTO looking to hire a junior developer does not care whether you completed a Udemy course, an ALX program, or a Coursera specialization. They care whether you can write code that works, read code that someone else wrote, and solve problems you have not seen before. A certificate tells them you sat through a course. It does not tell them you can build anything.

This is not cynicism. It is how the industry operates. Talk to any hiring manager at a Nairobi tech company and ask them how much weight they give to certificates. Most will tell you the same thing: they skim past the certificates section on a CV and go straight to the projects, the GitHub link, and the technical interview. That is where the signal is.

The certificate industry knows this, which is why they market certificates to learners (who want validation) rather than to employers (who do not need it). The certificate makes you feel like you accomplished something. And you did, you finished a course. But the certificate itself is not what gets you hired.

When a Kenyan tech company is hiring a developer, they typically evaluate candidates through a combination of these things. None of them are certificates.

Your portfolio projects. Can you show me something you built? Not a tutorial project that every student submits. Something you thought of, designed, built, and deployed. It does not have to be complex. A well-executed todo app with authentication, data persistence, and clean code tells a hiring manager more than a certificate from Harvard's CS50. Even better: build something relevant to the Kenyan market. An M-Pesa payment tracker, a Nairobi event finder, a school fees management tool. These show you understand local problems and can solve them.

Your GitHub profile. Hiring managers look at your GitHub to see if you actually code regularly. They check commit frequency, the quality of your READMEs, whether your code is organized, and whether you have contributed to anything beyond tutorial exercises. A GitHub profile with consistent activity over several months is strong evidence that you are building real skills. A profile with one burst of activity during a bootcamp and then nothing for six months is a red flag.

Technical interviews. This is where it really matters. Can you solve a coding problem live? Can you explain your approach? Can you debug something that is broken? Can you talk through how you would architect a feature? No certificate prepares you for this. Only practice does. The technical interview is the great equalizer: it does not matter where you learned, only what you learned.

Communication and problem-solving. Can you explain technical concepts clearly? Can you break a vague problem into concrete steps? Can you ask good questions when the requirements are unclear? These soft skills often matter as much as the code itself, especially for junior roles where employers expect to invest in your growth.

There are situations in Kenya where certificates carry real weight. It would be dishonest to pretend otherwise.

Enterprise and corporate roles. Large companies like Safaricom, KCB, Equity Bank, and major multinationals often have HR processes that require documented qualifications. When you apply through their official portals, your CV is screened by HR before it reaches a technical manager. HR is looking for checkboxes: degree, certifications, years of experience. In these environments, a certificate from a recognized institution can help you get past the initial screening. It does not replace technical ability, but it gets your CV into the right pile.

Government and NGO roles. Government IT positions and NGO-funded tech projects frequently list specific certifications as requirements. This is partly about institutional accountability: when spending public or donor money, organizations want documentation that the person they hired has formal qualifications. In these contexts, a certificate is sometimes a hard requirement, not just a nice-to-have.

Cloud and infrastructure certifications. AWS, Azure, and Google Cloud certifications are a genuine exception to the "certificates do not matter" rule. These are rigorous, proctored exams that test specific technical knowledge. Employers hiring for DevOps and cloud engineering roles often list these certifications as preferred or required qualifications because they indicate verifiable, standardized knowledge. This is different from a completion certificate you get for watching video lessons.

Career transitions from non-tech fields. If you are a 35-year-old former accountant switching to software development, certificates provide some credibility during the transition. They are not proof of ability, but they demonstrate intentional investment in learning. For career changers, certificates can help bridge the gap between "I say I am a developer" and "I have evidence that I have studied development."

Outside of these specific contexts, certificates are decorative. Acknowledge the exceptions, but do not build your entire strategy around them.

If certificates are not the answer, what is? A portfolio of real projects. Not screenshots. Not mockups. Deployed, working applications that a hiring manager can click on and use.

Quality over quantity. Two or three well-built projects beat fifteen half-finished ones. Each project should demonstrate different skills: one might show frontend ability, another backend and database work, a third might integrate a payment API. Together they tell a story: "I can build complete applications from start to finish."

Solve real problems. Tutorial projects (a calculator, a weather app, a clone of Twitter) are fine for learning but weak for hiring. Build something that solves a problem you or someone you know actually has. A budgeting tool for university students. A booking system for a salon. An inventory tracker for a small duka. When a hiring manager sees that you identified a problem and built a solution, they know you can do the same thing for their company.

Deploy everything. A project that only runs on your laptop is invisible. Deploy it. Use Vercel, Railway, or any free hosting platform. Put the live URL on your CV and your GitHub README. When a hiring manager can click a link and immediately see your work running, the impact is completely different from reading a description of what you built. Deployment also shows you understand the full development lifecycle, not just writing code in a local environment.

Write clear READMEs. Your GitHub README is the first thing someone sees when they visit your repository. Explain what the project does, why you built it, what technologies you used, and how to run it locally. Include screenshots or a link to the live version. A good README shows that you can communicate about code, not just write it. Many hiring managers read the README before they read a single line of code.

Show your M-Pesa chops. If you are targeting the Kenyan market, integrate M-Pesa or another local payment method into at least one project. This is a practical skill that many Kenyan employers need, and most international courses do not teach it. A project with working M-Pesa integration immediately sets you apart from candidates who only have experience with Stripe or generic payment tutorials.

Your GitHub profile is a window into how you actually work. Here is what hiring managers look for and what signals they pick up on.

Commit frequency. Regular commits over months show consistency. A burst of activity during a bootcamp followed by silence suggests you stopped coding after the course ended. You do not need to commit every day, but a pattern of activity over time demonstrates that coding is a sustained practice, not a one-time event.

Commit messages. "fix stuff" and "update" tell a hiring manager nothing. "Fix null pointer exception in user registration flow" tells them you can describe what you changed and why. Good commit messages are a small signal, but they separate candidates who care about communication from those who do not.

Code organization. When someone opens one of your repositories, is the code organized into a sensible folder structure? Are there separate files for different concerns? Or is everything jammed into one massive file? Code organization demonstrates that you think about structure, not just functionality.

README quality. As mentioned above, your README is your project's first impression. A repository with no README is like a store with no sign. A hiring manager will look, see nothing, and move on. Take the time to write READMEs for every project you want people to see.

Contribution graph (the green squares). The contribution graph is not everything. Some great developers have sparse graphs because they work in private repositories. But for junior developers applying for jobs, a graph that shows consistent activity over several months is a strong positive signal. It is visual proof that you show up and write code regularly.

One important note: do not fake GitHub activity. Do not write scripts to generate empty commits just to fill in green squares. Experienced developers can spot this immediately, and it destroys your credibility. Real activity on real projects, even if it is sparse, is infinitely better than manufactured metrics.

Every hour you spend chasing another certificate is an hour you could spend building something. Here is how to allocate your time for maximum impact on your job prospects.

Stop after one or two certificates. If you have completed a structured course (freeCodeCamp, a bootcamp, a Coursera specialization), you have enough certificate-level credentials. Adding more does not meaningfully improve your chances. The third certificate does not make you 50 percent more hireable than two. It makes you maybe 2 percent more hireable and costs you 200 hours that could have gone toward building projects.

Spend 70 percent of your learning time building. Once you have the basics, shift heavily toward project-based learning. Build something, get stuck, figure it out, deploy it. This cycle, repeated across multiple projects, is what transforms you from "I completed a course" to "I can build things." The struggle of figuring things out on your own is where real learning happens.

Spend 20 percent on targeted learning. When your project requires a skill you do not have (say, connecting to a database or integrating an API), learn that specific skill. Watch a tutorial, read the documentation, and immediately apply it in your project. This "learn it when you need it" approach is far more effective than completing an entire course on a topic before you have a reason to use it.

Spend 10 percent on interview preparation. Practice coding challenges on LeetCode or HackerRank. Not obsessively, but enough that you are comfortable solving problems under time pressure. Practice explaining your projects out loud. Rehearse your story: who you are, why you are switching to tech, what you have built. This 10 percent investment has outsized returns when you land an interview.

The key insight is this: employers are looking for evidence that you can do the job. Certificates are weak evidence. Deployed projects, clean code, and a clear explanation of your work are strong evidence. Allocate your time accordingly.

This article is not saying certificates are completely worthless. They have a place. Completing a structured course gives you foundational knowledge, exposes you to concepts you might not discover on your own, and provides a learning path when you would otherwise be lost. The course itself has value. The certificate at the end has limited value.

The problem is when people treat certificate collection as a strategy. "If I just get one more certificate, I will be ready to apply." This is a form of procrastination disguised as productivity. Each new certificate feels like progress, but it keeps you in student mode instead of pushing you into builder mode, which is where hiring managers want to see you.

If you are currently enrolled in a course, finish it. Get the certificate. Learn everything you can. But then stop collecting and start building. Take what you learned and apply it to a project that matters to you. Deploy it. Put it on GitHub. Write about what you learned. Then, when you apply for jobs, you have something concrete to show, something a certificate can never replace.

At McTaba Labs, our marathon program includes structured learning and project building in the same experience. You learn a concept, then immediately apply it in a project that you deploy and keep. By the end of 26 weeks, you have a portfolio of working applications, not just a certificate. That is the model we believe in: learning through building, with mentorship and code reviews along the way, producing graduates who have evidence of what they can do.