Mentorship Plan + STAR Story Portfolio

Complete, filled portfolio (no placeholders): a concrete 30/60/90 onboarding plan and six fully-written STAR stories drawn from this curriculum's work — ready to tell in a behavioral round. Template: ../STAFF-MENTORSHIP.md.

Onboarding plan — new rack-management engineer (concrete)

Mentee: a strong generalist SWE, new to BMC/Redfish/firmware. Goal: productive in 30 days, independent in 90, and the team stronger (not bottlenecked on me).

  • Week 1: pair on the rack model + rackctl CLI (Phases 01–02) on the lab/emulator; read the AI-Tray-2U EBOM and ADR-001/002. First PR: add a rackctl inventory --output json flag — reviewed as teaching (link the ADRs, not just "change this").
  • Weeks 2–4: own the Redfish→Prometheus exporter's CDU metrics (Phase 07) end-to-end incl. tests against the Redfish emulator (the seam) and a Grafana panel; shadow one on-call shift; ship behind a flag.
  • Weeks 5–8: own a DeviceDriver method across the seam (Phase 03), add the conformance check for it (ADR-006), and write Runbook B updates from a real incident. Do a design review.
  • Weeks 9–12: own a feature spanning firmware + telemetry (Phase 08/07), take a supervised on-call shift, lead one blameless RCA (Phase 10), and write an ADR.
  • Mechanics: pairing on the ambiguous parts; review-as-teaching; stretch-with-safety-net; specific, kind, timely feedback; success = the mentee not needing me and team docs/runbooks growing.

STAR stories (six, fully written)

S1 — Hardest bug root-caused (debugging — the JD's #1 theme)

  • Situation: a close-to-hardware C component (a sensor-history list) crashed intermittently under load in integration; normal builds "worked," so it had slipped past tests.
  • Task: I owned the component and the incident.
  • Action: resisted guessing — built it under AddressSanitizer, which pinpointed a heap-use-after-free at the list traversal with both the allocation and use stack traces; confirmed in gdb. Root cause: a remove that free()d a node without unlinking it (dangling ->next). Fixed by unlinking-before-free with a sentinel; added -fsanitize=address,undefined to CI and a regression test covering middle/head/absent removal.
  • Result: the crash class is gone; the team adopted sanitizers in CI, catching two more latent bugs within a month. Learning: latent memory bugs need tooling, not luck — and a fix isn't done until it's a CI gate.

S2 — Production incident, prevented recurrence

  • Situation: a set of nodes rebooted intermittently under heavy load; on-call had been "RMA the node" with no clear cause.
  • Task: get a real root cause, remotely (couldn't take tenant-serving nodes offline).
  • Action: evidence-first via OOB — read SEL + BERT for the last-crash cause and ran the RAS parser on AER/MCE; correlated reboots with telemetry and saw correctable-ECC on one DIMM rising with temperature. Hypothesis: a marginal DIMM failing under thermal load. Reproduced on a canary under load; cordoned/drained, RMA'd the DIMM (not the node), re-validated; added an alert on correctable-ECC rate.
  • Result: turned an unplanned-outage class into planned, single-FRU maintenance; mean repair scope dropped from "whole node" to "one DIMM." Learning: rate-not-count, and remote diagnosis beats a truck roll.

S3 — Cross-team / ODM delivery under ambiguity

  • Situation: integration with the ODM (Pegatron) kept slipping — their BMC returned a 200 with an error body on bad input, and sensor naming differed from our assumptions.
  • Task: make the interface unambiguous and unblock integration.
  • Action: wrote a precise, testable interface spec (the AI-Tray-2U spec) and a conformance suite (ADR-006) the ODM ran in CI; filed the 200-on-error as a tracked finding (RM-2026-014) with a defensive client workaround; agreed null for unpopulated sensors.
  • Result: integration time dropped materially and defects became "a failing check," not a debate; the suite now gates every firmware drop. Learning: in a multi-party build, the spec + conformance suite is the engineering.

S4 — Mentoring

  • Situation: a new hire was strong in app code but new to hardware management and hesitant to touch the firmware path.
  • Task: grow them to independent ownership without becoming their bottleneck.
  • Action: a 30/60/90 plan (above); paired on the first firmware-orchestrator change; reviewed as teaching (linked ADR-003 on A/B/rollback); handed them the exporter, then the conformance work, with a safety net.
  • Result: independent in ~10 weeks; they now own telemetry and mentor the next hire. Learning: success is the mentee not needing me and the team's knowledge (runbooks/ADRs) rising.

S5 — Design-review disagreement handled well

  • Situation: a teammate's telemetry module hardcoded Redfish paths and queried the BMC synchronously on every Prometheus scrape.
  • Task: I owned review for the telemetry area.
  • Action: gave implementation-focused feedback on the four axes — maintainability (hardcoded paths break across vendors → follow links, ADR-002), reliability/performance (sync scrape-time BMC calls couple scrape latency to BMC health and hammer fragile BMCs → poll-on-own-schedule + cache), security (TLS verification was off → validate the cert). Brought a small prototype of the cached approach; separated must-fix from opinion.
  • Result: adopted cached polling + link-following + cert validation; codified two standards in the review checklist (ADR + "no synchronous device I/O on scrape"). Learning: critique the design not the person; bring alternatives and data.

S6 — Tradeoff under constraints

  • Situation: a rack arrived 10% over its derated power budget; the easy path was to silently run it at N (no redundancy).
  • Task: deploy safely without hiding the tradeoff.
  • Action: used the budget calculator to size it; chose per-node power capping to fit within the N+1 budget rather than dropping redundancy, and made the (small) performance cost explicit to stakeholders in writing.
  • Result: deployed within a safe, redundant power envelope; the capping policy became the default for density-constrained racks. Learning: surface tradeoffs explicitly — don't bury them in a config or quietly sacrifice redundancy.

Closing questions to ask the interviewer

  • How is work split with the architects/lead engineers across sites?
  • What does the day-to-day ODM (Pegatron) collaboration look like?
  • How mature is the hardware-adjacent test/CI infrastructure (emulators/HIL)?
  • What does follow-the-sun on-call look like, and how complete are the runbooks?
  • What would "above and beyond" look like in the first 6–12 months?