What Actually Gets People Hired in Tech

Breaking into tech isn't just about technical skills. Drawing on real experiences and insights from AmaliTech, this article explores what hiring managers are really looking for and how you can position yourself for success.

Loading

At AmaliTech we train people into technical careers, sit in their interviews and read their portfolios. When people ask us how to get a job in tech, especially with no experience, what stops them is almost never what they assume it is.

A few years ago a woman was teaching French and phonetics to pre-schoolers in Takoradi. She had no technical background at all. Then she made an unlikely decision: she went to Takoradi Technical University to study software engineering, retraining from scratch in a field she had no history in. If you had asked anyone, back when she was teaching, to name the people least likely to end up writing software for international clients, she would have been on the list. She came to AmaliTech through National Service, and today she is one of our Senior Developers.

Around the same time, a young man in Accra finished an IT degree and started applying for jobs. He had the qualification and he had done the coursework, and he spent months getting nowhere, because nobody would give him practical experience and nobody would hire him without it. He eventually found his way to us, and he is a Software Engineer now.

Hold those two people next to each other for a second, because if you are trying to get into this industry, they tell you more about how hiring really works than any careers advice you have been given.

You are not being kept out by the degree

Almost everyone we train arrives believing the same thing: that what stands between them and a technical job is a qualification they do not yet have.

Augustine's story complicates that. He did the degree, did the coursework, and still spent months unable to get hired. The one who got stuck was the one who arrived with the paper qualification behind him.

So, it is worth asking the person who would know. Salami Suleiman, our Head of Training in Ghana, built the systems the whole programme runs on, and over the years he has come to a clear view about what separates the people who succeed. It is not more technical ability. He points to communication, adaptability, flexibility, and the ability to work with a team. In some ways, he says, those have become almost more important than the technical skills themselves.

a balance of soft skills and hard skills

That is a hard thing to hear when you have just spent three years and a lot of money getting qualified. But it is also good news, because the things he is describing are things you can start building today, whatever is or is not on your CV. If you are trying to get into tech without a degree, or with a degree that has not opened any doors yet, this is the part that matters.

Do not reject yourself

This is the mistake that costs people the most, and you have almost certainly made it.

You open a job description. There are twelve requirements. You meet nine of them, decide you are not qualified, and close the tab. No application, no rejection, nothing at all. You have removed yourself from a process before it even started, and the person hiring never knows you existed.

Here is what is easy to miss. Out in the industry, most job descriptions are written in layers. A handful of things genuinely matter, and they usually sit near the top. Most hiring managers know this, and few of them expect any single person to match every line.

So, when a role interests you, look hardest at what it is really asking for, the actual problem the team needs someone to solve. If that is something you could do, that is reason enough to put yourself forward and let them make the call. Whether you turn out to be the right fit is what the process is for. Deciding it yourself, before anyone has had the chance to see what you can do, only guarantees the answer is no.

What can look like modesty when you close that tab is often just a rejection you have handed out on someone else's behalf.

When we ask about your project, we are not asking what you built

In the mock interviews we run with every cohort, one question sorts people faster than any technical screen: walk me through a project you worked on.

Most people answer by describing the build. You set up the database, then you wrote the API, then you connected the front end. All of it true, and all of it tells us almost nothing about you, because a sequence of steps is a record of what happened and leaves out every choice you made along the way.

What we are listening for is a choice. Give us the problem in a sentence, then the constraint that made it hard, then what you decided to do about it and why, then what happened as a result. The constraint is the part nearly everyone leaves out, and it is the part we care about most, because building something is easy enough when there is nothing standing in the way, and we want to know how you handled it when there was.

We can tell when a project came from a tutorial

It usually takes about thirty seconds, and the giveaway is not the code but the README.

A tutorial project reads like it went perfectly. A real person usually makes a mistake in it somewhere, something you got wrong before you got it right, and it shows. If there is no misstep anywhere, no dead end, nothing you had to back out of, that often tells us the project followed a set of instructions that had already ironed all of that out.

plan build improve

So, build one thing that solves a real, slightly irritating problem you have personally run into, and scope it small enough that you finish it. That single project will do more for you than five polished clones of somebody else's tutorial. A clone shows you can follow along. Anybody hiring you is trying to find out something harder than that, which is whether you can think for yourself. This is how people with no formal experience build something real to show, and it is often what gets them hired.

And nobody is going to come looking for you

One last thing, and this one is not really your fault. Most of Africa's startup funding lands in a handful of cities, which means the people making hiring and investment decisions are mostly looking at a very small part of a very large continent.

We see what that does. Across our hubs in Accra, Kumasi, Takoradi and Kigali, we meet people with real skill built a long way from any tech scene, with nobody around to vouch for them. Work that nobody can find is, for the purpose of getting hired, not very different from work you never did.

So put it somewhere a stranger can find it. A public repository, a short write-up, something someone can click on. It does not have to be polished.

None of this asks you to be a better engineer than you already are. Augustine got in, and so did the woman who used to teach phonetics, and neither of them managed it by going back for another certificate first.

What usually stops people is not the obstacle they are staring at. It is the decision they made quietly, on their own, before anyone had the chance to disagree with them, that the door was shut.

© 2026 amalitech.com | All rights reserved