Zimbabwe and regional technology news and updates



Nyaradzo logo

Hiring A Developer? Devcenter’s Free eBook Could Be Of Use

Last December, we shared Devcentre’s State of Code Jobs document which shared interesting insights on Nigerian software development trends. The startup has now released a 2-part eBook giving tips on Hiring developers.

The document titled 7 Mistakes Managers Make When Hiring Nigerian Developers explores the Nigerian context but I felt most of the information I browsed through is applicable to Zim’s context as well.

The 2 books include the following information;

  1. The use of Copy & Paste Job Descriptions/ Failure to create an honest Job Advert
  2. Scheduling in-person interviews as the first next step after applications
  3. Moving Too Slow
  4. Having unrealistic expectations
  5. Interviewing too many candidates
  6. Lack of a definite onboarding plan
  7. Discarding candidates for future hire

Each mistake acts as a chapter that describes the mistake itself along with giving advice on how to actually ensure the same mistakes aren’t made after reading the book.

Both books contain a combined total of 25 pages making this a concise read that should take interested parties a day or two to go through but save them the long hours associated with a terrible hire.

Download 7 Mistakes Managers Make When Hiring Nigerian Developers Part I here.

Download 7 Mistakes Managers Make When Hiring Nigerian Developers Part II here.

Quick NetOne, Econet, And Telecel Airtime Recharge

6 thoughts on “Hiring A Developer? Devcenter’s Free eBook Could Be Of Use

  1. Interesting. Point 2, “Scheduling in-person interviews as the first next step after applications” is interesting. In S.A, sending a coding assignment or any other form of assessment without talking to the candidate first is considered one of the reasons companies fail to attract talent. It’s more advisable to explain the tech stack to the candidate first. It has to be noted that if you are good, there are endless high paying opportunities in S.A. I can’t say the same for Zim and Nigeria.

    1. Explaining your tech stack can yield false results, because some candidates will claim they are familiar with it, when they aren’t. Then they will immediately go for a crash course.

      FYI: Try mentioning a fictional language or platform, you’ll be amazed how many people say they think they have, or they have, heard of it.

      Next thing you could find you are hiring them when they aren’t the best fit for you.

      Tech stack, should be explained post assessment. Because assessments should focus on the stack layers. But, again you find some companies assessing someone on Android Java development yet they are looking for a C# Xamarin developer. Why? Because the outsourced assessment company doesn’t provide Xamarin tests.

      1. Hiring is not easy. Been surprised both ways where I am now. Someone who claims to be very good or at least experienced, but our interns outperform him…then someone who comes in as a beginner or intern or is quiet/not expressive and becomes a top performer.

        For seniors, we are specific on tech specs, because its a mentoring role, we don’t have much flexibility or time. If it’s a hands on position, we don’t want to have to spend time teaching the fundamentals of Java or .Net or Angular etc. We usually have existing, particular projects in mind when filling the position.

        For junior to intermediate, we accept that people are willing to/can learn, so we are more flexible. People with fundamental knowledge like DB design, general programming, are analytical(we give simple problem scenarios, handwritten and see how they cope…while we wait 😀 )

        Generally I hate overly academic type questions and will always be the one who questions the questions from my colleagues.

        We usually assess the character first with a mixed team of people, then we discuss, then we shortlist. A person really needs to be team fit. We avoid arrogant and negative types. Though that’s easy to fake I suppose.

        The short-listed ones will then go for an IKM( test, because it’s rather expensive to have every applicant do that in the beginning.

        In the past, I have attended assessments where they setup a PC, with the IDE for you and give you problem statements to solve….usually the whole day, and usually seemingly trivial questions, which are very hard lol.

        For one job, they did a cognitive test with Revelian (, then a full day of programming tasks.

        Some companies will pair you up to tackle a problem with one of their team members and you get to be involved in a full typical day…like scrum/daily standard, look at a story, breakdown, code then go through a code review session. If you survive that and they like you, they like you.

  2. Just reading through the document on item 4, Having unrealistic expectations, reminded me of your developer job advert. You had a generic job advert for a developer. I commented advising you guys to be more specific, but Nyahasha replied saying they had been lied to before so they had taken this route. I wonder how he takes this report. This extract got me thinking of the conversation:

    “Being specific goes a long way in setting expectations. For example, hiring for React Native
    developer, not “Flutter/React Native/Ionic” and if you’re flexible just say Hybrid.”

    I’m not attacking your team, I understand hiring is hard and there is no perfect formula.

    1. I hear you, the complexity of the process does mean that sometimes mistakes will be made but also there is a possibility that if you stumble upon a formula that works you try that out instead. As with all things, there’s always room to improve I guess

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.