Back to library
HashiCorpHashiCorp

PR Review Round + Paired TDD Session

Forward Deployed Engineering

What it tests

Real-world engineering judgment — how a candidate reviews code written by others, gives constructive feedback, and writes new code collaboratively with tests first.

Format

  1. 1Part 1 (30 min): Candidate reviews a real (or realistic) pull request from a community or internal codebase — finds issues, evaluates trade-offs, writes review comments as they would for a teammate
  2. 2Part 2 (45 min): Paired programming session — interviewer and candidate build a small feature together using TDD. Candidate writes the test first, then the implementation. Mistakes and iteration are expected and evaluated positively.
  3. 3Debrief (10 min): Candidate reflects on what they would have done differently in the PR review and what the test coverage they wrote actually proves

What to look for

  • PR review quality — do they find real issues, suggest meaningful improvements, and communicate clearly without being nitpicky?
  • TDD discipline — do they write tests that reflect actual requirements, not just tests that pass?
  • Collaborative instinct — do they treat the paired session as a conversation or as a solo exercise with an audience?
  • Self-reflection — do they recognize limitations in their own review and test coverage when asked?

Adaptation guide

Use a PR from your own codebase (anonymized) so the domain matches what they'll actually work on. The paired TDD session should build something that relates to your product's actual technical surface area. The goal is not to trick them but to see how they operate in a normal engineering workflow — reviewing, building, and reflecting.

Full description

Format:

  1. Part 1 (30 min): Candidate reviews a real or realistic pull request — writes comments as they would for a teammate, evaluating correctness, clarity, and trade-offs
  2. Part 2 (45 min): Paired TDD session — candidate writes tests first, then implementation, alongside the interviewer
  3. Debrief (10 min): Candidate reflects on their own review and what their test coverage actually proves

Time: 75 minutes

What to look for:

  • PR review quality — real issues found, clear feedback, not just style nits
  • TDD discipline — tests that reflect actual requirements, not just tests that pass
  • Collaborative instinct — paired session treated as a conversation, not a performance
  • Self-reflection — can they honestly evaluate limits in their own review and test coverage?

Adaptation: Use a PR from your own codebase (anonymized). The TDD session should target your product's actual technical surface. The goal is to observe a normal engineering workflow — reviewing, building, reflecting — not to catch someone out.