Behavioral / STAR Stories — Staff-Level, OSS-Flavored

Staff+ behavioral rounds probe influence without authority, judgment under ambiguity, and ownership over years — exactly the muscles the committer track builds. Below are the recurring prompts with story frameworks; fill each with your own lab artifacts and real contributions. Never recite a template verbatim.

Table of Contents

• How to build a story bank
• The eight prompts that always come up
• OSS-specific behavioral questions
• Anti-patterns

How to build a story bank

Maintain 8–10 stories, each written as: Situation (2 sentences, quantified), Task (your specific responsibility), Action (5–6 concrete decisions you made, with the alternatives you rejected and why), Result (numbers + what changed durably), plus a one-line "what I'd do differently". Each story should be retellable at three lengths: 30 seconds, 2 minutes, 10 minutes with follow-ups.

The curriculum generates story raw material on purpose:

The eight prompts that always come up

1. Disagreement with a senior engineer / decision you opposed. Framework: technical disagreement → you gathered evidence (benchmark, prototype, compatibility analysis) → escalated through the idea, not the hierarchy → committed fully to the outcome either way. The committer-track version: a -1 you received, engaged on merits, and either overturned with data or accepted and improved the patch.

2. Influence without authority. OSS is this, structurally: you got code into a project where nobody reports to you, by making the reviewer's job easy, building trust in small increments, and doing the unglamorous work (reviews, doc fixes, triage) that bought credibility.

3. Most technically challenging problem. Pick depth over drama: the Phase 08-style performance investigation (symptom → profile → hypothesis → fix → regression guard) interviews better than "big migration" stories because every step shows method. Have the actual numbers.

4. A mistake / failure. Requirements: a real failure (not "I worked too hard"), fast detection, honest communication, durable prevention (a test, a checklist item, a process change), and what it changed about how you work. The release-engineering labs give the right shape: what gets caught by checklist exists because someone once didn't catch it.

5. Mentoring / raising the bar. The review-culture phases are the material: how you review to teach rather than gatekeep, codified norms (review checklist, style configs), and a measurable change (review turnaround, defect escape rate).

6. Ambiguity / underspecified problem. Use the design-doc capstone: how you turned a vague "make the scheduler better" into problem statement → constraints → alternatives considered with rejection reasons → smallest reversible first step.

7. Delivering under deadline pressure with quality risk. The honest staff answer is about scope triage with explicit risk communication: what you cut, what you refused to cut (tests on the irreversible parts, compatibility), and who you told. Release-vote discipline is the OSS version: you don't ship an RC with a known licensing problem no matter the date.

8. Why this company / why this role. For data-infra companies built on ASF projects, the genuine answer connects your contribution history to their product: you already work on the thing, upstream; you've been on the dependent side of their compatibility promises; cite the specific JIRAs/KIPs.

OSS-specific behavioral questions

• "Walk me through a contribution you're proud of" — pick one with review friction; the friction is the story. Structure: issue selection → reproduction → patch → review rounds (quote real feedback) → merge → maintenance afterward.
• "How do you handle a patch rejected after weeks of work?" — the mature answer separates sunk cost from learning: why the rejection was (or wasn't) right, what design conversation should have happened first, and the smaller patch that landed later.
• "How would you grow contributors into committers?" — show you understand trust as the unit: graduated responsibility, public encouragement, review shadowing, nominating when the record is undeniable.

Anti-patterns

• "We" throughout — the interviewer can't find you in the story. Say what you did.
• Outcome with no mechanism ("improved performance by 40%") — staff interviews live in the how and the rejected alternatives.
• Conflict stories where you were simply right and the other person dumb — shows you haven't been wrong recently enough to notice.
• Heroics as the resolution — staff-level resolutions are systems (tests, checklists, designs), not all-nighters.
• Memorized delivery — bring notes structure to mind, not sentences.