# How to structure a strong answer (2–3 minutes) This is a behavioral question. The interviewer wants to see engineering depth **and** the collaboration habits that make a healthy open-source contributor: small well-scoped changes, evidence-backed impact claims, and respectful async communication. Prefer 1–2 substantial repositories over a long list of minor PRs, and attach at least one quantified metric and one concrete link per repo. Use a project-by-project mini-STAR (Situation/Task/Action/Result) format. For each notable project cover: - **Project / scope:** Repo name, what it does, your role, timeframe. - **Task:** The problem you addressed (bug, feature, performance, docs, CI, security). - **Action:** What you did (design proposal/RFC, code, tests, docs, triage, release). - **Result / impact:** Quantify it (PRs merged, users affected, performance delta, stability, CI time, adoption). Include collaboration and learning. Tip: Cite evidence (PR/issue numbers, RFC links, release notes) when allowed. Keep PRs small, separate refactors from behavior changes, and emphasize tests and backward compatibility. ## Example structured answer (adaptable — replace placeholders with your real links, metrics, and dates) **Project A — OpenTelemetry (observability SDK)** - *Role and scope:* Community contributor for ~6 months focused on the Python SDK exporters and docs. 8 PRs merged, 2 reviewed. - *Impactful contributions:* - Implemented a batched/async exporter with backpressure for OTLP traces. Reduced export CPU overhead ~20% and cut p95 exporter latency ~35% under a 10k-spans/sec load test, dropping span loss from ~2.4% to <0.5% (PR #[link], bench #[link]). - Added requests.Session instrumentation with context propagation and sampling controls; adopted by 3 downstream services and featured in the 1.2 release notes (PR #[link]). - Wrote troubleshooting docs, a 1.x→1.2 migration guide, and async-instrumentation examples (Docs #[link]). - *Collaboration:* Proposed the design in a short RFC/gist, discussed it in a maintainer/SIG meeting and Slack, and aligned on backward compatibility via feature flags. Split the work into small PRs each with tests and benchmarks; responded to review comments within ~24h. - *Learnings from reviews and triage:* Maintain semantic versioning and stability; prove changes with minimal reproducible benchmarks; use minimal-repro issues, apply labels (area/exporter, type/perf), close duplicates with references, and communicate next steps and timelines. **Project B — pytest plugin / test utilities (co-maintainer)** - *Role and scope:* Co-maintainer of a small plugin for parametrized retries for ~1 year; owned CI/releases and issue triage. - *Impactful contributions:* - Eliminated flakiness by isolating fixtures; improved CI pass rate from ~92% to 99% (PR #[link]). - Set up a GitHub Actions matrix with caching and parallel shards, cutting CI time from ~12 min to ~6 min; automated tagged PyPI releases. - *Collaboration:* Created a CONTRIBUTING guide, issue templates, and good-first-issue labels; onboarded 3 new contributors. Ran design discussions in issues before coding and enforced style via pre-commit. - *Learnings from reviews and triage:* Keep PRs <300 LOC and separate refactors from features; add property-based tests for edge cases (timezones, retries, async/deterministic clocks); request reproducible steps, prioritize by severity/frequency, and close stale issues kindly with a reopen policy. **Close with a synthesis:** Across projects I learned to propose design upfront, keep changes incremental, write thorough tests and docs, handle compatibility explicitly (feature flags, deprecation notes, changelog), and communicate empathetically and async. My default is to link issues to PRs, include benchmarks for performance changes, and document migration notes for any breaking risk. ## What maintainers value (use these as talking points) - Small, well-scoped PRs with tests and docs. - Backward compatibility, semantic versioning, and clear migration/deprecation notes. - Reproducible bug reports and performance benchmarks. - Respectful, async-friendly communication and quick responses. - Automation: CI, linting, release pipelines. - Supply-chain/security hygiene: Dependabot/dependency updates, CVE handling, CLA/DCO, SBOM or release signing where applicable. ## If your open-source experience is limited - Start with small, high-signal contributions: docs fixes, test additions, issue reproduction, labeling, triage. - Contribute to your own stack (frameworks, SDKs, tooling) or build and maintain a small plugin/template. - Demonstrate open-source-style practices directly in this take-home: open an issue for the design, write tests first, keep commits atomic, and add a CONTRIBUTING.md plus CI. ## Pitfalls to avoid - Vague, unquantified claims — replace "improved performance" with "p95 latency −35% under 10k spans/sec (bench #[link])." - Large PRs that mix refactors and features, or that skip tests. - Drive-by-only contributions — balance one-off PRs with sustained work (docs, triage, reviews, releases) to show depth. - Ignoring project coding standards / CONTRIBUTING guidelines, or breaking changes without compatibility handling. - Arguing style over maintainability, or a dismissive tone in reviews. ## Quick checklist for your answer - Name 1–2 repositories, what they do, and your role. - State the problem, your action, and a measurable result per repo. - Describe how you worked with maintainers (issues, RFCs, reviews, CI). - Note one security/supply-chain practice you followed. - Share concrete lessons from code reviews and issue triage. - Provide evidence (PR/issue/release numbers) when appropriate.

Rubric: this behavioral/take-home prompt is scored on (1) specificity — concrete repos, roles, and PR/issue references rather than generalities; (2) measurable impact — quantified performance, reliability, adoption, or CI metrics; (3) collaboration maturity — issues, code reviews, RFCs, backward-compatibility and versioning discipline; (4) supply-chain/security awareness; and (5) reflective learnings the candidate would carry into a team. Strong answers go deep on 1–2 projects with evidence; weak answers list many minor PRs with vague, unverifiable impact.