Tech Training for African women

The African Girls in Tech AI Academy – Cohort 10 by Africa Agility Foundation is now accepting applications for its 6-month AI-powered training program.

Available track:
📌AI & Machine Learning
📌Product Management
📌Product Design
📌Scrum Mastery
📌Data Analytics
📌Frontend Development
📌Backend Development
📌Mobile Development
📌Branding & Marketing

What you’ll gain:
🔹Practical, job-ready digital skills
🔹AI-powered workflows and tools
🔹Mentorship and career guidance
🔹Job opportunity and career sprints
🔹Experience building real-world projects
🔹Skills for global opportunities

Who can apply?
🔸African women aged 18–35
🔸Beginners and early-career professionals
🔸Anyone interested in building a career in technology

⏳Duration: 24 weeks (6 months)
✍️Format: Online
🎯Training: 16 weeks + 8 weeks mentorship & job opportunity sprints

🔗Apply: https://africaagility.org/africa-girls-in-tech/

📝Deadline: September 30, 2026

Registration is open for the STARK Official Hackathon.

Start with an idea. End with something real.

Teams of 2–5. Sep 09 → Oct 02. Free to enter. 11 prize packs.

Grab a teammate, bring an idea you actually believe in, and ship it.

Register here : https://stark-hackathon.vercel.app/register


do share this , if you belive this can help lots of people.

A Question Where O(n^3) Shines:

https://leetcode.com/problems/4sum/

class Solution:
def fourSum(self, nums: List[int], target: int) -> List[List[int]]:
quads = []
nums.sort()

for i in range(len(nums)):
if i != 0 and nums[i] == nums[i - 1]:
continue
for j in range(i + 1, len(nums)):
if j != i + 1 and nums[j] == nums[j - 1]:
continue
k = j + 1
l = len(nums) - 1
while k < l:
_sum = nums[i] + nums[j] + nums[k] + nums[l]
if _sum == target:
quads.append([nums[i], nums[j], nums[k], nums[l]])
k += 1
l -= 1
while k < l and nums[k] == nums[k - 1]:
k += 1
while k < l and nums[l] == nums[l + 1]:
l -= 1
elif _sum < target:
k += 1
else:
l -= 1

return quads

This made me smile and is a good trick to remember the solution.

Romantic two pointers

"If I wander to the end of the world and still cannot find you, I will take another path and search anew."

"And I shall do the same, my love."

https://leetcode.com/problems/intersection-of-two-linked-lists/

Google Artificial Intelligence Free Courses with Certificates 2026

Apply here: https://tinyurl.com/u7vdv8xz

Benefits:
• Free artificial intelligence courses offered by Google.
• Courses available in AI fundamentals, machine learning, and related fields.
• Self-paced learning with flexible schedules.
• Free certificates available upon successful completion, subject to platform policies.

For more courses and opportunities, visit:
https://www.opportunitiescircle.com/

Latency and response time are often used synonymously, but they are not the same. The response time is what the client sees: besides the actual time to process the request (the service time), it includes network delays and queueing delays. Latency is the duration that a request is waiting to be handled — during which it is latent, await‐ ing service

Martin-Kleppmann---Designing-Data-Intensive-Applications_-O’Reilly-Media-(2017)

I don't know if i have posted this before but here is a fancy word you could use next time you're talking about databases:

polyglot persistence:
It means using different types of databases or data stores within the same application, choosing each one based on the kind of data or workload it handles best.

For example, you might use PostgreSQL for relational data, Redis for caching, and Kafka for event streaming.

I was watching a video on distributed systems, and the lecturer mentioned MapReduce.

He said that in 2004, Google published a paper about MapReduce. At the time, Google was dealing with the huge challenge of indexing the content of the web, and processing that amount of data on a single machine could take weeks, months, or even longer.

And I love how companies come up with new and easier ways of doing things when they face a problem instead of just sticking to the norm.

That's what made me interested in MapReduce.

So, may I explain what it is?

I hope you said yes, because either way, I'll be explaining it.

MapReduce is a programming model for processing large datasets across a cluster of machines.

Instead of foolishly trying to count all the words on the entire web using one computer, we could divide the data across multiple machines and let them process different parts of it in parallel.

The basic workflow has three stages:

Map → Shuffle → Reduce

Mapping means processing the data assigned to each node and producing key-value pairs.

For example, if our input is:

"hello world hello"

The mapper could produce:

hello → 1
world → 1
hello → 1

After mapping, we have the Shuffle stage.

The shuffle groups the same keys together and distributes them to the appropriate reducers:

hello → [1, 1]
world → [1]

Then comes Reduce.

The reducer takes the values associated with each key and combines them:

hello → 2
world → 1

And there we have our result.

The nice thing about this is that we're not asking one machine to process everything. We're distributing the work across multiple machines and processing the data in parallel.

Since data may need to move between machines during the shuffle phase, data locality is also important. Ideally, we want computation to happen close to where the data is stored, so we can reduce unnecessary network traffic.

But, like almost every solution we'll talk about in distributed systems, MapReduce also has its downsides.

Iterative and highly interactive workloads aren't always a good fit for MapReduce.

MapReduce is great when you can break a problem into relatively independent pieces, process those pieces, and then combine the results.

Iterative algorithms are different because the output of one computation becomes the input for the next computation.

You can implement iterative algorithms using MapReduce, but it can become inefficient because you're repeatedly going through the Map → Shuffle → Reduce process and often writing and reading intermediate results.

And for interactive workloads, where a user expects an answer almost immediately, starting a large batch-processing workflow can introduce unnecessary overhead.

So MapReduce isn't a one-size-fits-all solution after all.

It's a great tool when the problem fits the model. And that's probably one of the biggest lessons I'm starting to appreciate in distributed systems:

There is rarely a single technology that's best for everything. It depends on the problem you're trying to solve.

We just secured a 2nd 🥈 place on stark hackathon. I cannot believe my eyes blenal 🍾🍾🍾

Don't ask if a number is prime. Just cross out the multiples and let the survivors speak for themselves.


https://leetcode.com/problems/count-primes/description/


https://www.youtube.com/watch?v=V08g_lkKj6Q

Another question to sharpen up your sieve of erathosthenes. If you know what sieve of erathosthenes is you're 65% done with the solution

https://leetcode.com/problems/closest-prime-numbers-in-range/

Hey guys! It's been weeks since I last shared something I've been learning, and today I feel like sharing because I find this topic really interesting.

And the topic is 🥁🥁🥁 REPLICATION! 🥁🥁🥁

Or may I say, the god of fault tolerance? 😂

replication means keeping copies of the same data on multiple machines connected through a network, Designing Data-Intensive Applications* by Martin Kleppmann

There are three main approaches to replication: single-leader, multi-leader, and leaderless replication.

I've been reading about single-leader replication, so let's talk about that today.

Leaders and Followers

How does it work?

Basically, we have one leader node and one or more follower nodes.

When a write request comes in, it goes to the leader. The leader updates its local storage and sends the changes to its followers through a replication log or change stream.

One thing to note is that write requests go through the leader, while read requests can be handled by either the leader or the followers.

But here's where it gets interesting.

Another important detail in replication is whether it happens synchronously or asynchronously.

Synchronous Replication

When a write request comes in, the leader waits for acknowledgment from its synchronous followers before confirming the write as successful.

This helps ensure that the acknowledged changes have reached the required followers, but it can increase latency. If a follower is slow or unavailable, the write may have to wait.

Asynchronous Replication

Here, the leader doesn't wait for its followers to acknowledge every write before confirming it as successful. It can continue handling other requests while replication happens in the background.

This improves write performance, but there's a trade-off. If the leader fails before some changes reach the followers, those changes could be lost during failover. Followers may also serve stale data because they haven't received the latest changes yet.

Asynchronous replication is often a practical choice when followers are geographically distributed because network delays can make waiting for every follower expensive.

So, is there a middle ground?

Yes! Semi-synchronous replication.

In this setup, the leader waits for acknowledgment from at least one designated synchronous follower, while replicating to the other followers asynchronously.

This gives us a balance between durability and performance. If the leader fails after the write is acknowledged, at least one follower should have received the change.

If the synchronous follower goes down, another follower may be selected to take its place, depending on the database system and its failover configuration.

And that's the basic idea of single-leader replication!

I think this is enough for today. Tomorrow, I'll share how we add new followers and handle node outages.

Hasta la vista! 👋

Although I called replication the god of fault tolerance 😂, fault tolerance isn't its only purpose.

Replication also helps with scalability by distributing read requests across multiple replicas, reducing the load on a single node.

It can also reduce latency by placing replicas closer to users geographically, so they don't have to send every read request to a server that's far away.

So, replication isn't just about keeping our data safe when a node fails. It's also about handling more traffic and making our applications more responsive.

Ever wondered where GitHub stores its own code? 👀

GitHub doesn't need some magical place outside the system.

Its engineers use private repositories on GitHub itself to build and maintain the platform.

Yep, GitHub uses GitHub to build GitHub.

Curious to see what’s behind the scenes? Explore their public repositories here 👇

🔗 https://github.com/github

I was watching a random system design video where the guy was asked to design a key-value store. He kept explaining his design, and then he said he would use an LRU eviction policy.

Right then and there, the interviewer cut him off and asked, "Why LRU?"

And I was caught off guard because I honestly didn't know what I would have answered.

So, before we're the next victims of this question, let's learn which policies fit which use cases.

LRU (Least Recently Used)

Evicts the item that hasn't been accessed for the longest time.

Useful for general-purpose caching when recently accessed data is more likely to be accessed again.

Examples: recently viewed web pages, product catalogues, and frequently revisited application data.

LFU (Least Frequently Used)

Evicts the item with the lowest access frequency.

Useful when some items consistently receive more requests than others over a long period.

Examples: popular product data, frequently requested recommendation results, and trending content.

TTL (Time to Live)

Items expire after a specified amount of time.

Useful when data becomes stale or loses its value after a certain period, regardless of how often it is accessed.

Examples: weather data, cached API responses, and temporary verification codes.

FIFO (First In, First Out)

Evicts the item that entered the cache first, regardless of how recently or frequently it was accessed.

Useful when a simple, predictable replacement policy is sufficient, such as in some buffers and queue-like storage systems.

Random Replacement

Evicts a randomly selected item.

Useful when a simple replacement policy is preferred and maintaining access history would add unnecessary overhead. It can also be reasonable for some workloads where access patterns are unpredictable.

So, next time an interviewer asks why you chose a particular eviction policy, don't just name one because it's familiar.

Think about the workload. How frequently is the data accessed? Does recency matter? Are some items consistently more popular? Does the data expire?

Because the best choice depends on the problem you're trying to solve.

Now we know what to say.

So I just came across an algorithm introduced by Brian Kernighan, and I admired it so much that I thought, why not share it?

It's called Brian Kernighan's Algorithm, and it's used to count the number of set bits (1s) in the binary representation of an integer.

In the past, whenever I wanted to count the set bits in a number, I would check how many bits were used to represent it. For example, let's say we're working with a 32-bit integer.

I'd loop through all 32 bit positions, shift 1 to the current position, and perform a bitwise AND with the number.

If the result wasn't zero, it meant the bit at that position was set, so I'd increment my counter.

But what's the downside?

To count the set bits, I had to check every single bit, even if the number had only one or two set bits.

Basically, even if only two bits were set, I'd still be checking all 32 positions.

And this is where Brian comes to our rescue!

He came up with a clever observation about what happens when we subtract 1 from a number.

Let's take 6 and 5 as an example:

6 = 00000110
5 = 00000101

Notice what happened?

When we subtract 1 from 6, the rightmost set bit becomes 0, and all the bits to its right become 1.

More generally, for a positive integer n, subtracting 1 flips its rightmost set bit to 0 and flips all the bits to its right to 1.

Now here's the clever part!

If we perform:

n & (n - 1)

we remove the rightmost set bit of n.

Let's see what happens with 6:

n       = 00000110
n - 1   = 00000101
------------------
n & (n-1) = 00000100

We went from 6 to 4, removing one set bit!

Let's do it again:

n       = 00000100
n - 1   = 00000011
------------------
n & (n-1) = 00000000

And now we're left with zero.

Since each operation removes exactly one set bit, we can keep repeating it and count how many times we do it until n becomes zero.

Here's the code:

def brian_kernighan(n):
    count_set_bits = 0

    while n:
        count_set_bits += 1
        n = n & (n - 1)

    return count_set_bits

And that's it!

The beautiful part is that we don't have to check every bit. The loop runs only as many times as there are set bits in the number.

If n has k set bits, the time complexity is O(k), compared with O(b) for checking every bit in a `b`-bit representation.

This is by far the best video I've found on Transformers. I was looking forward to learning more about Multilayer Perceptrons, but what can I do? At the end of the day, attention is all I need. 😁



https://www.youtube.com/watch?v=KJtZARuO3JY