Project retrospective interview types

General rounds test whether you can navigate the full project. Problem-solving rounds spend more time on a hard obstacle, the options you generated, and why your resolution worked.

• Project arc and role
• Root-cause reasoning
• Alternatives and trade-offs
• Lessons after the outcome

Expect request-level traces, data models, algorithms, scaling boundaries, failure behavior, and technology alternatives. Diagrams should expose the subsystem you personally understood.

• Five to eight meaningful boxes
• Named state and ownership
• One representative data flow
• Failure and migration path

Technical output is still relevant, but the decisive evidence is how you created alignment, handled disagreement, delegated, mentored, or translated between engineering and product.

• Stakeholder map
• Decision process
• Conflict and resolution
• How others were enabled

Impact-focused rounds ask how success was defined and verified. Failure retrospectives test accountability, containment, repair, and whether the organization learned.

• Baseline and target metric
• Rollout and measurement
• What failed and why
• Durable corrective action

A hypothetical retrospective tests whether you can diagnose a project with incomplete context. State assumptions, separate symptoms from causes, and propose a prioritized repair plan.

• Clarifying questions
• Evidence you would request
• Risk-ranked intervention
• Validation and rollback