Welcome to your interview.
The question is on your right: Detect Engineering Team Burnout Signals. Take a moment with it first.
Talk your thinking through with me if you like - when you're confident, submit your answer and I'll grade it like a real screen (7/10 or better passes). Discussion and graded submissions share your five interviewer interactions, so spend them well.
Fabrikam runs a B2B SaaS platform with 9 engineering squads and 74 engineers. Over the last 2 months, leadership has heard concerns about workload sustainability after a major roadmap push. The VP of Engineering wants a metric framework to detect whether a team is becoming overloaded before attrition or delivery failures occur.
For one 6-person backend team, the last 8-week snapshot shows: average weekly after-hours commits rose from 6 to 21, mean PR review turnaround increased from 9 hours to 26 hours, open Sev-2/Sev-3 bugs increased from 14 to 31, sprint carryover rose from 12% to 29%, and PTO usage fell from 2.1 days per engineer per month to 0.8. Team eNPS dropped from +24 to +5, while regretted attrition remains flat at 0 in the period. Leadership is asking which signals are leading indicators of overload vs lagging confirmation of burnout, how to combine them into a practical KPI, and what thresholds should trigger intervention.
git_activity: engineer_id, commit_timestamp, local_hour, repo, lines_changed, weekend_flagjira_issues: issue_id, team_id, priority, status, created_at, resolved_at, sprint_id, carryover_flagpull_requests: pr_id, author_id, created_at, first_review_at, merged_at, review_roundshris_attendance: employee_id, PTO_days, sick_days, tenure, manager_idengagement_survey: employee_id, survey_date, eNPS, workload_score, stress_score, intent_to_leave