12 - Open source as resume¶

What this session is¶

Why OSS contributions outweigh almost everything else on an AI resume, and how to get them right.

The honest claim¶

A single merged non-trivial PR to huggingface/transformers or vllm-project/vllm is worth more than a year of unverified "AI experience" on a resume.

Why: it's verifiable. The hiring manager can read your PR. They can read the maintainer thread. They can see how you take feedback. They can see whether your code compiles. None of those are visible from a job title.

This is especially true if you're transitioning from outside AI. OSS contributions bridge the gap that "I taught myself AI for 12 months" otherwise can't.

What counts and what doesn't¶

Counts	Doesn't count
Merged PR with real code changes	Star on a repo
Merged PR with a meaningful test added	Forking and "improving" something privately
Sustained contributions to one project over months	One typo fix, claimed as a contribution
Documentation PR that fixes a real gap	"Issue created"
A new feature merged after maintainer review	A PR opened but never merged
A bug-fix PR with the failing-test-first	A 5000-line PR maintainers won't review

The bar isn't "contribution exists." The bar is "real engagement with a project."

The high-leverage projects to contribute to¶

For each specialization, the projects whose names recruiters recognize:

Applied LLM¶

langchain-ai/langchain
run-llama/llama_index
microsoft/autogen
crewAI-Inc/crewAI
promptfoo/promptfoo

Inference / serving¶

vllm-project/vllm
huggingface/text-generation-inference
ollama/ollama
ggerganov/llama.cpp
sgl-project/sglang

Fine-tuning¶

huggingface/transformers (Trainer-side)
huggingface/peft
huggingface/trl
axolotl-ai-cloud/axolotl
unslothai/unsloth

MLOps¶

mlflow/mlflow
kubeflow/kubeflow
ray-project/ray
wandb/wandb (client library)
bentoml/BentoML

Eval / safety¶

EleutherAI/lm-evaluation-harness
explodinggradients/ragas
promptfoo/promptfoo
confident-ai/deepeval

Pick ONE. Get deep. Three superficial contributions across three projects is worse than five real PRs into one.

How to start (the 4-week plan)¶

Week 1: Orient¶

Clone. Build. Run tests. Get the dev loop working.
Read CONTRIBUTING.md.
Read 5 recently merged PRs end-to-end. Look at what good "looks like" in this project.
Lurk on the Discord / Slack / GitHub Discussions if it exists.

Week 2: First small PR¶

Find a good first issue or a clear typo/doc gap.
Open the PR. Follow the template exactly.
Address feedback promptly.
Goal: one merged PR.

Week 3: Real bug fix¶

Find a bug issue that's been triaged but unassigned.
Reproduce it.
Write a failing test first.
Fix it. Make the test pass.
Open the PR with both the test and the fix.

Week 4: Small feature or improvement¶

Find a help wanted or feature-request issue with maintainer interest.
Comment to claim. Wait for approval.
Implement. Add tests. Update docs.

After this 4-week sprint, you have 2-3 merged PRs in one project. That's the start of a real contribution profile.

How not to flame out¶

The common failure mode: big, ambitious first PR. The PR sits for months. You give up.

Avoid this by:

Starting small.
Reading maintainer signals (which issues do they actually respond to?).
Asking before doing: "I'd like to take on issue #1234. Is that direction correct?" Wait for a 👍.
Splitting big work into small PRs. Each PR should be reviewable in 30 minutes.

How to talk about it in interviews¶

Wrong: "I contributed to PyTorch."

Right: "I contributed three PRs to vLLM over four months - one fixed a memory leak in the KV cache eviction logic, one added support for [specific model], one improved the docs around [specific topic]. The first one involved working with the maintainer to redesign the test."

Specifics. Always specifics. Hiring managers can smell vagueness.

The "I want to but I'm intimidated" problem¶

Common. The fix is to do the smallest possible thing first.

Pick a project.
Open CONTRIBUTING.md. Read it.
Find the smallest doc PR. A typo. A confusing sentence.
Open the PR. Get it merged.
The intimidation evaporates after the first merge.

The first PR is the hardest. Everything after is easier.

What if a project rejects your PR¶

Normal. Doesn't reflect on you personally.

Reasons: - They didn't want that feature. - Style mismatch. - Already being worked on internally. - Bad timing (release week, maintainer vacation).

Try a different issue. Or a different project. Don't dwell.

The compounding effect¶

Sustained contributions to one project for 6+ months make you a contributor, not just an outsider with PRs. You'll be:

Cc'd on related issues.
Asked to review others' PRs.
Mentioned in release notes.
Recommended to companies hiring in the space.

This is the long game. The first PR is the start.

What you might wonder¶

"What if my PR sits for weeks?" Normal for big projects. Polite check-in after a week. Sometimes longer. Don't take it personally.

"What if I don't know the language well enough?" Pick the project carefully. langchain is mostly Python. llama.cpp is C/C++. vllm is Python with CUDA. Match your skill.

"What if there are no 'good first issues' I can do?" Look at recent merged PRs. The shape of contributions tells you what's wanted. Sometimes the unlabeled issues are easier than the labeled ones, which get claimed instantly.

"Should I contribute to research code (e.g., a paper's reference implementation)?" Less recruiter-friendly than mainline projects. Fine if it's your specialization. Better as project #4 after the well-known ones.

Done¶

Have one target project.
Have the 4-week start plan.
Know how to talk about contributions.

Next: Interview prep - what they actually ask →