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 was 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 a small fix, respond to review, and move on. That taught me how to enter a repository, but it did not feel like working with the same team for weeks.

That gap was why I applied. I wanted sustained work: a codebase, a pod, a mentor, and enough time to discover what my first fix had missed.

A configuration that looked valid

The technical story I chose was aiu-trace-analyzer PR #98, in the IBM-developed trace-analysis project now under torch-spyre. It concerned profiles that enable or disable processing stages.

A pipeline can contain pipeline_barrier more than once. The old loader walked entries in order and matched the next requested setting by plain name. In a sparse profile, a repeated name could be consumed by the first occurrence even when that was not the occurrence the user meant.

Nothing had to crash. The configuration could look reasonable and still select the wrong stage. That made the matching rule more important than the size of the diff.

The three rules that shipped

• Bare repeated name: in a sparse profile, pipeline_barrier applies to every occurrence.
• Occurrence-qualified name: pipeline_barrier#2 targets the second occurrence.
• Complete profile: settings continue to match positionally, so repeated stages can have different enabled states.

The final code also preserves positional matchingMatch entries by where they appear in an ordered sequence. when all occurrences of a repeated name are listed but newer tail stages are absent. That compatibility detail matters: describing the rule as “the lists must have exactly the same length” would be too strict.

The PR description still discusses rejecting ambiguous bare names. The final implementation and tests instead apply them to all occurrences. For this story, the code that merged is the source of truth.

The change touched four files. In my original account, I recorded running nine focused stage-profile tests. That is a record of my preparation at the time, not a new test run of the repository for this update.

I had to relearn my own diff

Preparing to explain it was humbling. Remembering that I wrote the code was not the same as being able to walk another engineer through it.

I traced a profile through parsing, stage annotation, positional detection, repeated-name handling, matching, and the runtime checker. Why avoid mutating the input with popitem()? Why use one-based occurrence numbers? What happens to an unknown or misplaced stage? What do the tests prove, and what do they leave open?

I stopped trying to memorize a smooth speech. I wanted to be able to get interrupted on a line and still know which input had brought the program there. One code sample I could defend was more useful than a page of repository names.

Why the fellowship made sense

My reason for applying was not that I had finished learning open source. I could see what self-contained fixes had taught me and what they had not. I wanted to understand decisions that span several patches: how a team divides work, protects compatibility, and follows a change after the obvious test passes.

When I was selected as a Software Engineering Fellow in the Open Source Track, that sustained part was what I was excited to work on. This is my account of the code story I prepared, not a claim about which part determined the selection.

What I would do again

I would choose a project that can survive follow-up questions. Not automatically the biggest one: the one where I can explain the wrong turn, the test that caught it, and the tradeoff I still have to think about.

I would also save the exact submitted application, rather than piecing it together from drafts and preparation notes later.

If you are applying, make the behavior concrete enough to draw. Four boxes showing which stages are enabled tell this story better than the phrase “fixed ambiguous profile matching.” Then make sure your explanation agrees with the final code, not just the first PR description.

Reach out to compare notes, or read my Student Collective account for the more personal, campus-focused application story.

Inspect the example

This teaching model isolates the three matching cases in the figure. The production loader also validates ordered entries, handles unknown or misplaced stages, and works with the runtime checker. Its linked source and tests are the authority.

# A small teaching model of the three displayed cases, not the full loader.
def repeated_stage_flags(occurrences, key=None, complete=None):
    if complete is not None:
        if len(complete) != occurrences:
            raise ValueError("Complete profile must supply every displayed occurrence")
        return list(complete)
    if key == "pipeline_barrier":
        return [True] * occurrences
    prefix = "pipeline_barrier#"
    if not isinstance(key, str) or not key.startswith(prefix):
        raise ValueError("Use pipeline_barrier or pipeline_barrier#N")
    ordinal = int(key[len(prefix):])
    if not 1 <= ordinal <= occurrences:
        raise ValueError("Occurrence is out of range")
    return [i == ordinal for i in range(1, occurrences + 1)]

assert repeated_stage_flags(4, "pipeline_barrier") == [True] * 4
assert repeated_stage_flags(4, "pipeline_barrier#2") == [False, True, False, False]
assert repeated_stage_flags(4, complete=[False, True, True, True]) == [False, True, True, True]
for label, flags in [
    ("bare", repeated_stage_flags(4, "pipeline_barrier")),
    ("#2", repeated_stage_flags(4, "pipeline_barrier#2")),
    ("complete", repeated_stage_flags(4, complete=[False, True, True, True])),
]:
    print(label, flags)

bare [True, True, True, True]
#2 [False, True, False, False]
complete [False, True, True, True]

Run this example on the site · Download notebook Download Python

Sources

1. PR #98: all four final changed files
2. Merged-head stage-profile implementation
3. Regression tests including the positional example