Part 11 · Senior Prep · Intermediate

Mentorship & Debug Coaching Interview Q&A

Model answers on mentoring juniors through hangs, teaching triage method, code review style, and growing team capability without becoming a bottleneck.

Mentoring debug skills

Q: How do you mentor a junior stuck on a hang?

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: Mentor on hang debug?

A:
  APPROACH:   Teach bucket classification before tools — not 'let me fix it'.
  STEPS:      1) Ask what symptom (hang vs error). 2) Guide to display_objections.
              3) Pair on driver handshake probe. 4) Have them write reproducer.
  SENIOR SIGNAL: grow repeatable skill, not dependency on you.
  PITFALL:    Taking keyboard — junior learns nothing, you become bottleneck.

Q: Junior's scoreboard always mismatches — coaching approach?

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: Coach scoreboard debug?

A:
  APPROACH:   Teach compare granularity — txn vs beat vs byte.
  STEPS:      1) Print first mismatching field only. 2) Trace expected path.
              3) Confirm monitor samples response not request. 4) Write 1-txn directed.
  QUESTION:   'What does the scoreboard think should happen on this beat?'
  PITFALL:    Rewriting their scoreboard — they repeat same bug next block.
systemverilog
// mentoring artifact — teach objection trace first
task run_phase(uvm_phase phase);
  super.run_phase(phase);
  phase.phase_done.display_objections();  // junior adds this line first
endtask

// then handshake probe template you have them paste
`uvm_info("MENTOR", "before get_next_item", UVM_MEDIUM)
seq_item_port.get_next_item(req);
`uvm_info("MENTOR", $sformatf("item=%0p", req), UVM_MEDIUM)

Q: How do you run effective TB code review?

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: TB code review style?

A:
  CHECKLIST:  phase correctness, config_db paths, factory create, coverage sampling
              point, objection raise/drop pairing, no driver field pokes from test.
  TONE:       Ask questions ('what happens if get fails?') not directives only.
  OUTPUT:     Junior updates checklist doc from review finding — team learning.
  PITFALL:    Nitpicking style — focus on correctness and reuse boundaries.

Key takeaways

  • Mentor with guided questions — keyboard takeover teaches nothing.

  • Hang coaching: objections → handshake → reproducer — in that order.

  • Code review teaches method via checklist — not one-off fixes.

Common pitfalls

  • Senior who fixes every bug — team never levels up.

  • Review without explaining why — junior repeats mistake.


Growing team capability

Q: New hire first week — what do you assign?

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: New hire ramp?

A:
  WEEK 1:     Run smoke test, read arch doc, add one assertion or coverpoint with mentor.
  WEEK 2:     Fix documented P2 bug with paired review.
  WEEK 4:     Own one directed test end-to-end.
  MOTIVATION:  Early win + visible contribution — not 'read UVM manual for a month'.
  PITFALL:    Sink-or-swim on hang debug day 2 — demoralizing, slow.

Q: Junior wants to rewrite the VIP — you redirect how?

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: Redirect VIP rewrite urge?

A:
  SITUATION:  Junior proposed new agent from scratch — existing VIP works.
  ACTION:     Ask what gap existing VIP cannot fill; assign extension via cfg or
              callback instead of rewrite; pair on one integration bug in current VIP.
  RESULT:     Junior added config knob and sequence — shipped in 3 days vs 3 weeks.
  SENIOR SIGNAL: channel energy to incremental improvement with reuse.

Q: How do you document tribal debug knowledge?

diagram
[INT][SENIOR][UVM] MODEL ANSWER

Q: Tribal knowledge capture?

A:
  MECHANISM:  Team debug playbook — symptom  first tool  owner — updated each escape.
  MOTIVATION:  Seniors leave projects — playbook survives turnover.
  FORMAT:     One-page buckets in repo; link from triage .meta template.
  EXAMPLE:    'objection leak' page: display_objections, fork join, vseq anti-patterns.
  PITFALL:    Confluence doc nobody updates — stale within one milestone.
diagram
[INT][SENIOR][UVM] mentor session structure (30 min)

  0–5 min:   junior narrates symptom + what they tried
  5–15 min:  senior asks questions only — no typing
  15–25 min: junior drives tools with senior pointing at log lines
  25–30 min: junior writes reproducer ticket before session ends

Key takeaways

  • Ramp plan: smoke → small fix → owned test — visible wins early.

  • Redirect VIP rewrites to cfg/seq extensions unless gap is proven.

  • Debug playbook in repo — living doc updated on escapes.

Common pitfalls

  • Mentoring only juniors who ask — proactively pair on first hang.

  • Playbook in wiki no one owns — becomes archaeology.