DEV Community: Lorraine Moyo

Technical interviews are one of the best health checks a developer can get.

Lorraine Moyo — Mon, 01 Jun 2026 10:19:13 +0000

Usually, they start with knowledge-based questions. If you've been coding for as long as I have, you can explain most of the concepts because you've worked with them in practice. Then comes the coding challenge.

The challenge I received initially felt like a random function. I was all over the place trying to solve it. Afterwards, I realized something important: there was a standard approach the industry expects. When you're employed and focused on delivering work every day, it's easy to lose touch with those evolving standards.

I finished the interview hopeful that I'd get the role, but regardless of the outcome, it reignited something in me. I wanted to sharpen my Python skills.

I started looking at HackerRank exercises and LeetCode problems, but quickly realized that wasn't the path I wanted to take. I wanted to learn from the people shaping the future of software engineering. Right now, that's companies like Anthropic.

I found a course that aligned perfectly with where I want to be in my career. And, unbelievably, there was the exact type of solution I had struggled with during the interview. The very interview that exposed a gap in my knowledge ended up leading me to the resource that helped close it.

I wish I had found it sooner.

But maybe that's the point.

Sometimes an interview isn't there to get you the job. Sometimes it's there to show you where the market is, what the current standards are, and what you need to learn next.

So my advice is simple: interview.

I know it's hard. We have jobs, kids, Hyrox training, side projects, and we need rest. Preparing for interviews takes time and energy.

But interviewing is like going for a health check as a developer. It tells you what's strong, what needs work, and whether you're still aligned with where the industry is heading.

And sometimes, the most valuable thing you get from an interview isn't an offer.

It's direction.

Designing a robust monitoring tool

Lorraine Moyo — Tue, 26 May 2026 18:42:06 +0000

Core Engineering principles

Observability first
A service must never be silent. I must build in structured logging and health checks so that I know why and when my crawl failed.

Fail-fast & Graceful Recovery
I always assume a resource provider has anti-scraping measures, so I design for failure. The code should be able to handle 429 Too many requests or 403 Forbidden errors by implementing exponential backoff and rotation strategies

Decoupling
Keep the fetcher (network I/O), parser(data extraction) and notifier (external API interaction) logic strictly seperated.

What is the challenge?

Now that I have defined our core engineering principles let me analyse the challenge that I am trying to solve
In order to create a linkedIn post-monitoring tool, I must consider that LinkedIn is a massive, dynamic site. If I simply run a script to GET a url every 10 minutes, I am highly likely to reach a rate limit or get flagged as malicious activity

So how do I address the "Bot Detection" challenge?
Cem Dilmegani from AI Multiple has some useful solutions to the challenge.
The next edition will entail the trade offs

Should I refractor?

Lorraine Moyo — Mon, 19 Aug 2024 21:07:34 +0000

When dealing with spaghetti code at work, you generally have two primary options: refactoring the code or trying to understand and maintain it as is. Here's a breakdown of the pros and cons of each approach:

Option 1: Refactoring the Code
Pros:

Improved Code Quality
Easier to maintain in the future
Increased stability

Cons:

Time-consuming
Risk of introducing new bugs**
Possible downtime
Requires deep service knowledge

Option 2: Understanding and Maintaining the Existing Code
Pros:

Service continuity
Preservation of legacy logic
Good for short term

Cons

Maintaining the service is a headache
Decreased developer morale
Underlying issues increase

What do you guys do when faced with a new service that will potentially be your baby to take care of?

Choosing a python framework

Lorraine Moyo — Mon, 08 Jan 2024 15:20:34 +0000

I've recently switched to a new role and moved away from the tedious CRUD operations and moved onto data transformations and more interesting things in the world of python and I think at some point I lost my passion bc it was all work and no play work. I had no motivation to actually create something - I still don't but I believe I will find it along this learning journey.

You get people who know what they want from the word go and then you get us who figure it out along the way. We just ensure the car has enough fuel, enough money in the bank account to book accomodation in some little town we'll find along the journey and we just drive. Call it unprepped, call it winging it - call it whatever but lets start this journey

So I don't know what kinda app I want to build. The only spec I know is that it's going to be data intensive. I already know about django and fastapi.

Conditions to consider when choosing a framework

For me as someone who is building a personal project in terms of learning and becoming a better dev - I'd say my most important conditions would be

Documentation
Scalability
Performance

I will elaborate on the above points with the comparison between Django and Fast API

Setting up one-to-many & many-to-many relationships in Entity Framework Core

Lorraine Moyo — Mon, 24 Oct 2022 12:54:29 +0000

The Entity Framework is one of my favorite Object Relational Mapping Tools. It has extensive support for schema migrations, and change tracking and it also supports LINQ Queries.

It also works with one of my favorite SQL databases; SQLite.
What's there not to love about the Entity Framework Core? It is especially great when your want to focus on the application logic because EFC will automatically generate the SQL code for you.
What's there not to love about the Entity Framework Core? It is especially great when your want to focus on the application logic because EFC will automatically generate the SQL code for you.

In order to ensure that the Entity Framework Core generates accurate SQL code, you must have well-written model classes that clearly state the relationships between the entities

Let's get to the meat of this article

Relational Databases reduce duplication, let's say we have a Gym data records table that has athlete's, workouts, and personal trainers;
if the data is recorded in a non-relational approach we would have a long list of different Athletes that do the same Workouts, with the same Personal Trainer.

This means that if 50 Athletes attended a workout called Cardio, held by one personal trainer, we would have to record the workout classes and the personal trainer's name 50 times, God Forbid the Personal Trainer's name changes and now we must update the 50 duplicate occurrences.

Relational Databases have entities such as Athlete, Workout Plan, and Personal Trainer that relate to one another by Foreign Keys, and together they make managing data easier and less prone to errors

One-to-Many Relationships

One-to-many relationships look at two unique entities/tables for example a Personal-Trainer and a Workout Class

A single Personal Trainer can conduct multiple workout classes and that forms our one-to-many relationship.
To show this one-to-many relationship for the Entity Framework to generate our SQL code our Model classes should look like this:

The Personal Trainer Model creates a collection of Workout Model

 public class PersonalTrainer
    {
        public int Id { get; set; }
        public string Name { get; set; }
        public string Surname { get; set; }
        public ICollection<Workout> Workouts { get; set; }

    }

The Workout Model class declares the Foreign Key and adds a navigation property of Workout.

public class Workout
    {
        public int Id { get; set; }
        public string Title { get; set; }
        public int MetabollicEquivalent { get; set; }
        public int Duration { get; set; }
        public int PersonalTrainerId { get; set; }
        public PersonalTrainer PersonalTrainer { get; set; }

A cheat method that I like to use

First I create an Entity Diagram showing the one-to-many relationship
The entity that is "One" always has a Collection of the "Many" entity
The "Many" Entity will have a Foreign Key

Many-to-Many Relationships

Many-to-Many relationships are actually entities that have a one-to-many relationship between them both ways. For example a Workout can have multiple Athletes and Athletes can do multiple Workouts. This relationship is represented by creating a join table and then relating the entities to the join on a one-to-many relationship as follows:

Easy right!

Now to configure a model for such a relationship is just as simple:
The Athlete class will create a collection of the Join Table That We will create called AthleteWorkout

public class Athlete
    {
        public int ID { get; set; }
        public string Name { get; set; }
        public string Surname { get; set; }
        public decimal Weight { get; set; }
        public decimal Height { get; set; }
        public DateTime StartDate { get; set; }
        public ICollection<AthleteWorkout> AthleteWorkouts { get; set; }
    }

and Workout class will do the same

 public class Workout
    {
        public int Id { get; set; }
        public string Title { get; set; }
        public int MetabollicEquivalent { get; set; }
        public int Duration { get; set; }
        public int PersonalTrainerId { get; set; }
        public PersonalTrainer PersonalTrainer { get; set; } 

    }

Then the join table AthleteWorkout class will have the navigation properties of both Athlete and Workout and their Foreign Keys

public class AthleteWorkout
    {
        public int ID { get; set; }
        public int AthleteId { get; set; }
        public Athlete Athlete { get; set; }
        public int WorkoutId { get; set; }
        public Workout Workout { get; set; }
    }

Understanding how relationships work is fundamental when you have to create the joins and navigation properties of Models.

In the next article, I will look at how we configure the models that we created for our ApplicationDbContext class.

Opensource Newbie

Lorraine Moyo — Tue, 02 Nov 2021 08:23:21 +0000

I often ask myself when will I ever stop referring to myself as a code newbie when I have been in the world of coding for the past 4 years. There are so many aspects to explore in this coding universe of ours that I find myself constantly being a newbie at something. I have decided to embark on a personal journey with open source and it feels completely new - I know nothing - Even after watching 10 tutorials. 4 months into my job as a low-code front end developer and I still feel like a newbie.

As I embark on this open source journey I hope you will enjoy the ride with me, and hopefully by the end of this year I will be blogging about how I successfully contributed to open source and put my name out there.