Coder Legion - Recent posts tagged bias

Why Do Neural Networks Need the Chain Rule? How do we apply it?

Fri, 03 Jul 2026 09:32:00 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star git-lrc on GitHub to help more developers discover the project. Do give it a try and share your feedback for improving the product.

In the previous article, we introduced backpropagation and learned that neural networks improve by reducing prediction errors.

We also saw that backpropagation relies on two fundamental ideas:

The Chain Rule
Gradient Descent

But we haven't yet answered an important question:

How does we calculate wieghts and biases to decrease the error?

To answer that, let's look at a very small neural network.

A Simple Neural Network

Imagine a neural network with:
Similar to the previous example.

One input neuron
Two hidden neurons
One output neuron

Calculating Last Bias In the last layer

Let's asssume we have wieght and bias of all hidden layer and we only want to find last bias b3

Now from gradient descent, we can update the last bias b3 using the partial derivative of loss with respect to b3

The Error rate is done with Residuals.
Residual = Observed - Predicted

SSR = Sum of (Observed - Predicted)^2

So, We take 3 samples for training

Starting, Ending and middle values.

Finaly By calculating SSR.

Use of Chain Rule

We actually calculated b3 only using gradient descent.

Now Using chain Value generated from the weight and bias of previous layers

Predicted = Top Layer + Bottom Layer + Bias (b3)

Using Chain Rule we can write Dirivative of SSR with

dssr/db3 = dssr/dpredicted * dpredicted/db3

dssr/dpredicted = (Observed - Predicted)^2

As predicted, it is not constant and we are dirving it.

dssr/dpredicted = 2*(Observed - Predicted)*(d(Observed - Predicted))/dpredicted)

dssr/dpredicted = 2*(Observed - Predicted)(-1)
dssr/dpredicted = -2(Observed - Predicted)

For dpredicted/db3

dpredicted = Top Layer + Bottom Layer + Bias (b3)
Both Top Layer and Bottom Layer is constant for this calculation
dpredicted/db3 = 1

Finaly dssr/db3 = -2*(Observed - Predicted) * 1

Slop Calculation and Learning

Now we have 3 values of predicted for 3 samples

dssr/db3 = Σ(-2*(Observed-Predicted))

dssr/db3 = -2 * [(Observed1 - Predicted1) * 1 + (Observed2 - Predicted2) * 1 + (Observed3 - Predicted3) * 1]

dssr/db3 = -2 * [(Residual1) + (Residual2) + (Residual3)]

dssr/db3 = -2 * (ResidualSum)

For our training data I got slope = -15.7

step size = slope x learning rate

step size = -15.7 x 0.1 = -1.57

new b3 = old b3 + step size

new b3 = 0 + (-1.57) = -1.57

Then again, recalculating SSR with new b3 we got slop.

slop = -6.26

step size = -6.26 x 0.1 = -0.626

new b3 = -1.57 + (-0.626) = -2.196

Similarly after calculatinng multiple times utile we get step size close to 0.

Final Result
We found the optimal
b3 = 2.21

Conclusion

We could able to apply these chain rule, gradient descent and backpropagation in a very small neural network.

In next article we will discuss how to calculate wieghts and biases in same neural network.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.

⭐ Star git-lrc on GitHub

Working Twice as Hard to Be Seen as Average: Life as a Latino Developer

Wed, 11 Feb 2026 05:29:42 +0000

I walked into the conference room with my laptop to set up the infrastructure demo. Before I could connect to the projector, someone asked me to refill the coffee first.

I had a computer science degree. I was working in infra and support. But they saw a Latino face and assumed “service staff,” not “software engineer.”

This was in Brazil. My own country.

If the bias is this strong at home, imagine what it’s like abroad.

When I Moved Abroad

That coffee moment in Brazil taught me the bias runs deep, so deep it exists even at home.

But when I moved abroad? I learned what intensity means.

No one asked me to refill coffee anymore. The bias evolved. Got sophisticated.

I exceeded all expectations. Top performer. Multiple successful projects. When my first promotion came up, leadership hesitated.

Not because of my work, that was undeniable. But because something about me didn’t fit their mental model of what “senior” looks like.

It wasn’t just that moment. It was every single day.

Every code review scrutinized harder. Every meeting where I had to prove my point twice. Every technical decision questioned just a bit more. Every accomplishment met with surprise instead of recognition.

The weight isn’t in one coffee incident or one delayed promotion.

The weight is in living it every day, in ways so subtle that calling them out feels like paranoia—until the pattern becomes undeniable.

You’re Not Imagining It

If you’re a Latino developer, you’ve felt it. That sense that you need to work twice as hard to prove half as much. That your accent makes people second-guess your skills. That your degree from a Latin American university is worth less.

Here’s the data: You’re not imagining it.

Latinos are 19% of the US population but only 5.9-8% of the tech workforce
At Google in 2020, despite a $150M diversity commitment, Latinos made up just 5.9% of employees
In core computer/math roles, only 8.3% are Latino

Research on imposter syndrome shows it’s “especially prevalent in underrepresented racial and ethnic minorities” (NIH). Forbes notes that “minorities face bias that makes it harder for them to be promoted or selected for certain roles.”

This isn’t personal failure. This is structural exclusion.

The Google Interview

Ten years of experience. Proven delivery. Strong references.

I made it through all the Google interview rounds. The feedback was good.

Then: rejected. No clear explanation.

I kept replaying the system design interview. I knew my architecture was sound. But did I explain it the way they expected? Did my phrasing sound uncertain when I was being thoughtful? Did my accent make them doubt my competence?

I’ll never know.

But I know this: technical competence wasn’t the only thing being evaluated.

Research on technical interviews confirms it. interviewing.io found that “implicit biases sneak in and people aren’t even aware of them.” Non-native speakers face an inherent disadvantage in interviews where “effective communication is key to success.”

Here’s the nuance: You might be fluent in English, but cultural differences in how you convey ideas still come across as weakness.

Brazilian communication style is more relationship-focused, context-aware. North American style is more direct, transactional. Neither is wrong, but one gets judged as “unprofessional.”

The Hidden Barriers

These aren’t isolated incidents. They’re patterns.

The Name Effect
Resumes with Latino/Hispanic names get fewer callbacks. Even before the interview, the name creates bias. Some developers anglicize their names to get past this filter.

The Cultural Fit Trap
“Cultural fit” is often code for “thinks and communicates like us.” When you express ideas differently—even if technically sound—it gets labeled as not fitting in.

Timezone as Invisible Labor
Working from Brazil/LATAM for North American companies? Early morning or late night calls are YOUR problem to solve. You adjust. They don’t. This invisible labor never counts in performance reviews.

The Credential Discount
Your degree from a top Brazilian university isn’t seen as equal to a North American degree, regardless of actual education quality.

The Promotion Ceiling
High-performing Latino mid-level developers get held back from senior roles. The bar for “leadership presence” or “communication skills” becomes a convenient filter.

The Paradox

Here’s the weird part: this structural imposter syndrome (the one society applies to us and we apply to ourselves) makes us work 10x harder to achieve what others achieve easily.

Which makes us excellent engineers. But also exhausted humans who never feel like we’ve done enough.

This isn’t just personal. It’s social, structural, cultural. We do it to ourselves, AND the world does it to us.

The same trait that drives us to over-deliver also prevents us from recognizing our own value. We minimize our contributions. We overestimate North American tech. We stay silent in meetings. We accept lower salaries.

What We Bring

Flip the narrative. What do Latino developers bring that North American tech culture often lacks?

Work ethic – We’re willing to go further, learn more, prove ourselves repeatedly.

Resourcefulness – Building with constraints makes better engineers. We know how to do more with less.

Cultural intelligence – Navigating multiple cultures IS a technical skill. We understand global markets beyond the Silicon Valley bubble.

Relationship-building – Brazilian emphasis on personal connections creates stronger, more cohesive teams.

Multilingual abilities – Our “accent” is proof we’re multilingual. That’s a skill, not a weakness.

These are competitive advantages. But only if companies recognize them.

What To Do About It

For Latino Developers:

Document everything – Bias thrives in ambiguity. Keep records of your work and wins.

Build in public – Blog, contribute to open source, give talks. Create undeniable proof of competence.

Find the right companies – Look for Latino leadership or strong D&I track records. Culture starts at the top.

Practice technical communication explicitly – Mock interviews with native speakers help.

Leverage networks – Connect with groups like SHPE (Society of Hispanic Professional Engineers).

Own your accent – Reframe it as proof of multilingual ability, not a deficit.

For Allies and Managers:

Question your assumptions in code review – Am I judging the code or the communicator?

Separate technical competence from communication style – Different doesn’t mean worse.

Audit promotion decisions for bias – Are Latinos hitting a ceiling in your org?

Value multilingual abilities as a skill – Not just a neutral trait.

Champion Latino developers actively – Advocate for them in senior roles when they’re ready.

Not Just a Brazil Story

I wrote this from the perspective of a Brazilian software engineer. But these patterns aren’t unique to Brazil or Latin America. They’re not unique to tech.

This is what happens when you’re perceived as “other” in spaces built by and for one dominant culture.

The coffee. The furniture. The Google rejection.

These moments happen to Latinos across industries. To Africans in European companies. To Asians in Western firms. The details change. The pattern doesn’t.

The Honest Truth

Some days I feel confident. I know I’m good at what I do. I see the systems I’ve built, the people I’ve mentored, the problems I’ve solved.

Other days, the imposter syndrome wins. I wonder if I’ll ever be “enough.” I replay conversations, second-guessing how I phrased things. I see another rejection and wonder if it was my accent.

That’s okay.

Naming the reality doesn’t make it go away. But it does make it visible. And once it’s visible, we can change it.

If you’re a Latino developer: You’re not imagining it. You’re not alone. Your work is valuable. Your perspective matters. Keep pushing forward.

If you’re an ally: Look around your team. Who’s missing? Whose ideas get dismissed? Who has to work twice as hard to get half the credit?

Now you know. What will you do about it?

References

Per Scholas: Latino Representation in Tech
SQ Magazine: Diversity in Tech Statistics 2026
NIH: Imposter Phenomenon in Racially/Ethnically Minoritized Groups
BairesDev: Breaking Barriers – Tackling Imposter Syndrome Among Minorities in Tech
Forbes: How To Navigate Imposter Syndrome – A Hispanic Perspective
ACM: Fairness and Bias in Algorithmic Hiring
interviewing.io: Unconscious Bias in Technical Interviews

The post Working Twice as Hard to Be Seen as Average: Life as a Latino Developer appeared first on sudoish.