How I got into the MLH Fellowship

The PR count was the easy part

By the time I applied to the MLH Fellowship, I had 17 merged open-source pull requests. That made for a clean line on the application. It did not answer the question I cared about.

Could I stay inside one unfamiliar codebase long enough to become useful?

Most of my contributions were narrow by design. Find a bug. Reproduce it. Send the smallest fix. Respond to review. Move on. That taught me how to enter a repository without making a mess, but it did not feel like working on a team for weeks at a time.

That gap was my reason for applying. I wanted the sustained part: one codebase, a pod, a mentor, and enough time for the first idea to be wrong.

The bug I chose to talk about

My technical code story was IBM aiu-trace-analyzer PR #98. It fixed a profile loader that behaved badly when a pipeline used the same stage name more than once.

Imagine a pipeline with pipeline_barrier near the beginning and another pipeline_barrier later. The old loader walked the pipeline and matched settings by name. In a sparse profile, it could consume the setting at the first match and silently apply the user's intent to the wrong occurrence.

Nothing crashed. That was what made it annoying. The configuration looked valid while doing the wrong thing.

The fix gave repeated stages clear rules. An unqualified name applied to every occurrence. A key such as pipeline_barrier#2 selected one occurrence. A complete profile still matched positionally. I changed four files and ran nine focused stage-profile tests.

I had to relearn my own diff

Preparing for the interview was humbling. I knew I had written the code, but “I remember writing this” is not the same thing as being able to walk another engineer through it.

I traced one profile through parsing, stage annotation, positional detection, recurring-name handling, matching, and the runtime checker. I made myself answer the questions that would be awkward if I had skipped them. Why remove popitem()? Why are occurrence numbers one-based? What happens with an unknown stage? What do the tests prove, and what do they leave open?

I stopped trying to memorize a smooth speech. The smoother it sounded, the less I trusted it. I wanted to be able to get interrupted on any line and still know where I was.

One code sample you can defend is worth more than a page of repositories you can only name.

Why MLH made sense for me

My application was not “I already know open source, so let me in.” It was closer to the opposite. I knew how to ship self-contained fixes, and I could see exactly what that approach was not teaching me.

I wanted review that lasted longer than one pull request. I wanted to see how a team makes decisions across a real codebase, how work gets divided, and what happens after the obvious test passes.

That was the honest bridge between what I had done and what I wanted next. When I was selected as a Software Engineering Fellow in the Open Source Track, that gap became the thing I was most excited to work on.

What I would change if I applied again

I would save the exact form submission immediately. I kept drafts and preparation notes, but I should have kept one clean copy of what the reviewer actually received.

I would also spend less time arranging company names. A reviewer can scan a GitHub profile. The useful story is why a repeated stage name creates ambiguity, how the wrong behavior survives silently, and why the new matching rule is easier to reason about.

If you are applying, pick the project or PR that can survive follow-up questions. Do not automatically pick the biggest one. Pick the one where you remember the wrong turn, the test that caught it, and the tradeoff you still do not love.