A merged pull request can say more about an engineer than a polished resume, but getting there is not a matter of generating code and pressing Submit. In this interview with Bruno Schaatsbergen, a Terraform contributor and former HashiCorp engineer, the recurring theme is reviewer effort: understand the project, propose a wanted change, explain it clearly, and take responsibility for what you send.
Read the project's rules and recent merged work before coding. Solve a real, bounded problem; make the behavior and tests easy to verify; and treat review as collaboration, not an entitlement. AI can help investigate and implement, but the contributor must understand and own the result. Open-source history can become career proof, not a guaranteed job pipeline.
Watch the Interview
Credit: The original interview and examples belong to the video creators and Bruno Schaatsbergen. Bruno's public GitHub profile and LinkedIn provide direct routes to his work. The checklist below is an editorial synthesis of the discussion, not a rule every repository must follow.
Why PRs Stall, and a Better First Pass
At 04:18, Bruno describes a common mismatch: a contributor writes a patch before learning how maintainers evaluate changes. His counterintuitive advice is to study merged PRs from active contributors. Their scope, titles, descriptions, tests, and review conversations reveal the project's practical standard. This is not a trick to force a merge; it is a way to avoid making maintainers rediscover the rationale for your change.
Start with the repository's own CONTRIBUTING.md and issue templates. GitHub's contributor guide advises looking for project guidance and beginner-suitable issues, and checking whether a maintainer wants a change before opening a substantial PR. The Terraform contribution guide is one concrete example of project-specific requirements; never assume the same rules apply elsewhere.
- Find a real problem: reproduce a bug, clarify an accepted issue, or ask whether a proposed feature fits the roadmap.
- Read the room: review current contribution rules, recent merged PRs, tests, naming patterns, and unanswered maintainer questions.
- Keep the change bounded: separate unrelated refactors and explain why the chosen scope solves the problem.
- Make review cheap: describe the behavior before and after, add an appropriate test, and state exactly how you checked the change.
- Stay for the conversation: answer review comments, revise when the maintainer has a better constraint, and accept that a reasonable patch can still be outside the project's direction.
Bruno says he may spend hours on a PR description. That is his own level of investment, not a required quota. The useful standard is whether a reviewer can understand the problem, the proposed behavior, and the verification without reconstructing your entire investigation.
Start With a Need You Actually Have
Bruno's first Terraform contribution arose from work, not a contribution leaderboard. While helping build a machine-learning platform at Adidas, he needed AWS resources that the Terraform provider did not yet cover. He contributed support, got an early PR merged, and could bring that improvement back to the team (09:31). His experience illustrates how solving a specific user problem can align a contributor and a project. It does not mean first PRs usually merge quickly.
At 10:51, he explicitly rejects the idea that every good engineer needs a busy GitHub profile. If you already spend your day engineering, extra unpaid code is not a prerequisite for competence. Open source is most valuable when you want to understand the tools you depend on, practice a different kind of engineering, or participate in the people and decisions around a project. Reading code and issue history can be worthwhile even before a PR exists.
Use AI Without Turning Contributions Into Noise
From 12:46, the interview turns to AI-assisted contribution spam: lots of plausible-looking fixes, bulk README edits, or shallow patches that consume scarce maintainer attention. Bruno is not arguing that using an agent is inherently wrong. He uses coding tools for codebase research and implementation, then checks and edits the work himself. His test is whether the contributor can explain the change and stand behind it (18:02).
Policies differ. Ghostty's contribution guide uses a vouch process for first-time contributors, and its AI policy allows AI-assisted work only with disclosure and full contributor understanding. That is Ghostty's policy, not a universal GitHub policy. Before involving an agent, check the target repo's current rules, data boundaries, license, security expectations, and test requirements.
A practical AI-assisted PR still needs a human to reproduce the issue, inspect the diff, run relevant tests, explain trade-offs, and answer questions. Do not use generated explanations as a substitute for understanding; do not submit speculative issues or patches at scale. At 20:11, Bruno frames authorship as his own responsibility for the code he submits. That is his engineering ethic here, not legal advice about liability.
Public Work Is Proof, Not a Job Promise
The interview's title makes a bold career claim. Bruno's actual account is more careful. He says sustained Terraform contributions, roadmap discussions, community events, and relationships helped him become visible to HashiCorp, which later offered him a role (26:04). That is an individual story, not evidence that OSS beats a resume for every candidate or that a public profile guarantees hiring. His explicit warning at 27:12: do not contribute to a vendor's project solely because you expect a job.
He also explains why trust is cumulative. Maintainers may grant more responsibility after repeated useful work and real interaction, yet they retain the right to reject a popular request that conflicts with a project's direction (24:52). There is no obligation to maintain a daily streak. Bruno describes weeks away from contributions during personal commitments and cautions against letting rankings or agent output define your worth (30:42).
For an engineer seeking a credible public record, one well-explained issue, a reproducible fix, or thoughtful review can show more judgment than a stream of low-value PRs. Keep a record of the problem, trade-offs, tests, and your response to feedback. Those artifacts demonstrate how you work with other people; they do not need to become a performance of constant activity.
Video Chapters
| Time | Segment |
|---|---|
| 00:00 | Introduction |
| 01:04 | How OSS shaped Bruno's career |
| 02:14 | Pride in each PR |
| 03:16 | OSS vs personal projects |
| 04:18 | Why PRs get ignored |
| 05:41 | Know your reviewer |
| 06:35 | Imposter syndrome |
| 07:10 | Read code to learn |
| 09:31 | First contribution |
| 10:51 | Early-career contributors |
| 12:46 | When contributions become noise |
| 13:44 | AI slop and maintainer burden |
| 16:17 | Maintainer responses |
| 18:02 | Bruno's AI workflow |
| 19:11 | Keep your own judgment |
| 20:11 | Ownership of generated code |
| 21:16 | Trust and permissions |
| 22:52 | Meeting maintainers |
| 24:52 | Project ownership |
| 26:04 | OSS and the resume |
| 27:12 | Do not chase a job offer |
| 28:38 | Consistency and community |
| 29:30 | Bruno's path |
| 30:42 | Time away is okay |
| 32:07 | Contributor rankings |
| 34:32 | Work with people worldwide |
| 35:52 | Identity beyond AI output |
Business Idea Prompt: Reduce Contributor Friction
A potential service here is not an AI that files more PRs. It is a small, maintainer-approved improvement to the path from genuine user problem to reviewable change. Validate that need with a real project before building.
Help a maintainer, not a metric
One project. One measured pilot.
Sources and Limits
Primary account: Bruno's interview and the supplied transcript support his views and personal career history. Contributor practice: GitHub's guide and Terraform's contribution instructions. Project-specific AI example: Ghostty's contributor guide and AI policy. The interview offers an experienced contributor's perspective, not measured hiring outcomes or a controlled comparison of AI-assisted PR quality. Policies and maintainer capacity can change; check the target repository before acting. Evidence checked October 16, 2026.