Technical Interviews in Kenya: What Actually Gets Asked

If your mental image of a technical interview comes from YouTube videos about FAANG companies, reset your expectations. The Kenyan interview landscape is different. While a few companies have adopted Silicon Valley-style processes with whiteboard algorithm challenges and system design rounds, the majority of Kenyan employers use more practical, project-based approaches.

This makes sense when you think about it. A Nairobi fintech startup hiring a full-stack developer needs someone who can build a payment integration next week, not someone who can reverse a binary tree on a whiteboard. Their interview process reflects that priority. They want to see you write real code, work with real tools, and solve problems that resemble the actual work.

That said, the interview process varies significantly by employer type. Banks and large corporates (Safaricom, Equity Bank, NCBA) tend to have more formal, multi-round processes. Startups often keep it shorter and more conversational. Pan-African companies like Andela use processes that blend local and international standards. International companies hiring remote Kenyan developers usually follow their home-country process, which might include algorithm rounds.

Across all employer types, one pattern is consistent: Kenyan interviewers value communication. They want to hear you think out loud. They want to see how you approach a problem, not just whether you get the right answer. A candidate who talks through their reasoning, asks clarifying questions, and explains their tradeoffs will outperform a silent genius who produces correct code without explanation. Development is collaborative work, and the interview is where companies assess whether you can collaborate.

The Take-Home Assignment

This is the most common format at Kenyan startups and mid-size companies. You receive a project brief, typically with a 48-to-72-hour deadline, and build a small application or feature. Common assignments include building a REST API with specific endpoints, creating a frontend dashboard that consumes an API, or implementing a specific feature (like user authentication or a payment flow).

What evaluators look for in take-homes: clean code structure, proper error handling, tests (even basic ones), a clear README, and thoughtful architectural decisions. They are not looking for a production-ready application. They are looking for evidence that you think like a developer. If you submit a take-home with no error handling, no comments, and a single 500-line file, that tells them something. If you submit well-organized code with clear naming, separation of concerns, and a README that explains your decisions, that tells them something very different.

Live Coding and Pair Programming

Some companies skip the take-home and go straight to a live session. You share your screen (or sit at a shared computer) and work through a problem together with an interviewer. This format is common at startups where the CTO or lead developer conducts interviews personally.

The problems tend to be practical: "Here is a bug in our staging environment. Walk me through how you would debug it." Or "Build a simple form that validates input and submits to an API." The interviewer is watching your process as much as your output. Do you read the error message before jumping to conclusions? Do you check the documentation when you are unsure? Do you write a test before fixing the bug? These habits matter more than speed.

System Design Conversations

For mid-level and senior roles, expect a discussion about how you would design a system. "How would you build a notification service that handles 100,000 messages per day?" or "Design a payment reconciliation system for M-Pesa transactions." These conversations test your understanding of databases, caching, queues, API design, and scalability concepts.

At the junior level, system design questions are lighter. You might be asked how you would structure a database for a blog application, or how you would organize a React application with multiple pages and shared state. The goal is to assess whether you think about architecture at all, not whether you can design at Netflix-scale.

The Traditional Interview Panel

Banks and large corporates often use panel interviews with multiple interviewers, typically an HR representative, a technical lead, and sometimes a department head. The technical questions in this format tend to be more structured: "Explain the difference between SQL and NoSQL databases." "What is RESTful API design?" "Describe a challenging project you worked on." Prepare concise, specific answers. Panel interviews reward clarity and confidence.

Based on what developers in the Kenyan market consistently report, these are the technical areas that come up most frequently in interviews.

JavaScript and TypeScript fundamentals. Closures, promises, async/await, the event loop, scope and hoisting, array methods (map, filter, reduce), and error handling. If you are applying for a JavaScript-heavy role, you should be able to explain these concepts clearly and write code that uses them correctly. "What is the difference between let, const, and var?" is a common warm-up question. "Explain how promises work and write a function that fetches data from two APIs in parallel" is a more substantive one.

React and frontend frameworks. Component lifecycle (or hooks), state management, how rendering works, and performance optimization. Expect questions like "When would you use useEffect versus useMemo?" or "How would you structure a React application with shared global state?" If the company uses a specific framework, they will ask about it. Read their job listing carefully and prepare accordingly.

API design and HTTP. RESTful API conventions, HTTP methods and status codes, authentication (JWT, OAuth), and error response formats. A common practical question: "Design a REST API for a library management system. What endpoints would you create? What would the request and response bodies look like?" Being able to sketch out an API on the spot demonstrates that you think in terms of interfaces and contracts, which is what backend development is really about.

Database and SQL. Basic and intermediate SQL (SELECT, JOIN, GROUP BY, subqueries), database normalization, indexing, and the differences between SQL and NoSQL databases. Kenyan fintech companies love SQL questions because their systems are database-heavy. "Write a query that returns the top 10 customers by transaction volume in the last 30 days" is a realistic interview question at a Kenyan bank or fintech.

Git and version control. Branching strategies, how to resolve merge conflicts, what a rebase does versus a merge, and how to write good commit messages. These seem basic, but they come up regularly because collaboration depends on clean Git practices. Being able to explain your team's Git workflow in a previous project (or bootcamp) shows you understand collaborative development.

Problem-solving and debugging. You might be given a piece of broken code and asked to identify the bug. Or you might be asked to optimize a slow function. These questions test your debugging process more than your knowledge. Do you read the error message? Do you check inputs and outputs? Do you form a hypothesis before changing code? Demonstrating a systematic approach to debugging is more impressive than getting the answer immediately.

Let us address this directly because it causes a lot of anxiety. For most developer roles at Kenyan companies, heavy LeetCode preparation is not necessary. That is not to say algorithms do not matter. Understanding basic data structures (arrays, objects/maps, stacks, queues) and common patterns (sorting, searching, two-pointer, recursion) is useful. But spending three months grinding through hundreds of LeetCode Hard problems to prepare for a Nairobi startup interview is a misallocation of your time.

Here is why. Kenyan companies, especially startups and mid-size firms, interview for practical capability. They want to know if you can build a feature, debug a problem, or design an API. Algorithm puzzles tell them whether you can reverse a linked list, which is not the same thing. The correlation between algorithm contest performance and on-the-job productivity is weak, and many Kenyan hiring managers know this.

There are exceptions. If you are applying to Andela, which uses a more international interview process, expect some algorithm-style questions. If you are targeting a remote role with a US or European company, their process might include a LeetCode-style round. Large Kenyan companies like Safaricom sometimes include algorithm questions, particularly for competitive roles.

The practical recommendation: spend a few hours familiarizing yourself with basic algorithm patterns. Be able to solve LeetCode Easy problems comfortably. Understand Big O notation at a conceptual level (why is searching a sorted array faster than searching an unsorted one?). Then invest the rest of your preparation time on the things that actually come up in Kenyan interviews: building projects, understanding your framework deeply, practicing SQL, and getting comfortable talking through your code out loud.

If you have spent weeks on LeetCode and feel like you are not getting interviews at Kenyan companies, the problem is probably not your algorithm skills. It is more likely your CV, your portfolio, or your networking. Redirect your energy accordingly.

Effective interview preparation for the Kenyan market is less about memorizing answers and more about building genuine competence. Here is a preparation plan that works.

Week 1-2: Audit your fundamentals. Go through the common topics listed earlier in this guide. For each one, ask yourself: "Could I explain this to another developer clearly?" If the answer is no, study it until you can. Write code examples. The act of explaining a concept (even to yourself) reveals gaps in your understanding that passive reading does not.

Week 2-3: Build a "demo day" project. Create one small project that you know inside and out. Something you can walk through line by line in an interview. Ideally, it should use the tech stack of the companies you are targeting. If you are applying to fintech companies, build something that handles payments. If you are applying to e-commerce companies, build something with a product catalog and cart. Know every architectural decision you made and why. This project becomes your go-to reference when interviewers ask "tell me about something you have built."

Week 3-4: Practice talking through code. This is the most overlooked preparation step. Find a friend, a classmate, or a fellow bootcamp graduate and do mock interviews. Take turns being the interviewer and the candidate. Practice explaining your thought process while writing code. Practice asking clarifying questions before jumping into a solution. Practice admitting when you do not know something and describing how you would find the answer. If you cannot find a practice partner, record yourself solving a problem and watch it back. The cringe is valuable.

Ongoing: Study the company. Before each interview, research the company thoroughly. What does their product do? What tech stack do they use? (Check their job listings, GitHub repos, and engineering blog if they have one.) What challenges might they face at their scale? Having specific, informed questions to ask at the end of the interview signals genuine interest and preparation. "How does your team handle deployments?" is a better closing question than "What is the salary range?"

Our full-stack developer bootcamp at McTaba Labs includes interview preparation as part of the curriculum because we know the technical skills alone are not enough. We run mock interviews, review CVs, and help graduates understand what Kenyan employers are specifically looking for. The Tech Foundations course (KES 2,999) is a good starting point if you want to build the fundamental knowledge that underpins every technical interview.

You have prepared. You have done your research. Now you are in the room (or on the Zoom call). Here is what separates candidates who get offers from those who do not.

Think out loud. Silence is your enemy in a technical interview. When you receive a problem, do not immediately start coding. Talk through your understanding of the problem. Restate it in your own words. Ask clarifying questions. "Should this function handle edge cases like empty arrays, or can I assume the input is always valid?" These questions show maturity and save you from building the wrong thing.

Start with a plan, then code. Before writing a single line, outline your approach. "I am going to create a function that takes these inputs, validates them, queries the database, and returns a formatted response. Let me start with the validation." This gives the interviewer a roadmap of where you are going. If your approach is wrong, they can redirect you early instead of watching you go down a dead end for twenty minutes.

Handle mistakes gracefully. You will make mistakes. Everyone does. What matters is how you respond. If your code has a bug, acknowledge it. "I see the test is failing. Let me trace through the logic to find where the error is." Debugging your own code under pressure is a skill that interviewers actively evaluate. Getting flustered and guessing randomly is a red flag. Calmly reading the error message and working through it systematically is a green one.

Admit what you do not know. If you are asked about something you have never worked with, say so honestly. "I have not used Redis in production, but I understand it is an in-memory key-value store used for caching. In my projects I have used similar caching patterns with local state." This answer shows honesty, conceptual understanding, and the ability to draw parallels. Faking knowledge always backfires because the follow-up question will expose the gap.

Ask good questions at the end. When the interviewer asks "Do you have any questions for us?" this is not a formality. It is part of the evaluation. Ask about the team structure, the development process, how they handle code reviews, what the biggest technical challenge is right now, or what success looks like in the first three months. These questions tell the interviewer that you are thinking about the role seriously, not just collecting job offers.

The interview is over. What happens next matters more than most candidates realize.

Send a follow-up message within 24 hours. A short email or LinkedIn message thanking the interviewer for their time and reiterating your interest. Mention something specific from the conversation. "I really enjoyed discussing the payment reconciliation challenge your team is working on. It is similar to a problem I tackled in my M-Pesa integration project." This is not sucking up. It is professional courtesy that reinforces a positive impression.

If you receive a take-home after the interview, treat it like a professional deliverable. Follow the instructions precisely. Include a README with setup instructions and your design decisions. Write tests if the brief does not explicitly exclude them. Submit it before the deadline, not at the last minute. The take-home is often the deciding factor between candidates who interviewed equally well.

If you do not hear back within a week, send a polite follow-up. "Hi, I wanted to check in on the status of my application for the Developer role. I remain very interested in the position and happy to provide any additional information." One follow-up is professional. Three follow-ups in the same week is not.

If you are rejected, ask for feedback. Not every company provides it, but many Kenyan companies will share brief feedback if you ask politely. "Thank you for letting me know. I would appreciate any feedback on my interview that could help me improve." This feedback is gold for your next interview. Common themes in rejection feedback include insufficient depth in a specific technology, unclear communication during the coding exercise, or lack of practical project experience.

If you receive an offer, do not accept immediately unless the offer is exactly what you want. It is completely acceptable to ask for a day or two to consider. Review the full package: salary, benefits, equity (if offered), working hours, remote policy, and growth opportunities. If you have other processes in progress, let them know you have received an offer and ask about their timeline. Negotiation is expected and professional, as long as you approach it respectfully.

Every interview, regardless of the outcome, is preparation for the next one. Keep notes about what went well, what did not, and what you want to improve. Candidates who debrief themselves after each interview improve faster than those who just move on to the next application.