Setting and Modeling Excellence Questions

Assessing how a candidate defines, establishes, and sustains high standards of quality and performance across work, teams, and deliverables. Topics include personal philosophy on excellence, concrete practices for setting expectations, modeling the behaviors you expect from others, giving and receiving feedback to raise quality, holding teams accountable, and pushing back on mediocrity. Candidates should be prepared to describe specific examples of raising the bar, saying no to acceptable but not excellent options, and balancing excellence with pragmatism and resource constraints. At senior levels this also covers influencing culture, embedding standards into processes, measuring quality and impact, coaching and developing others to meet elevated expectations, and making trade off decisions between speed, scope, and rigor.

EasyTechnical

70 practiced

You're joining a new SRE team. What 30/60/90-day checklist do you follow to set and communicate personal quality standards (code review, runbooks, observability) and model excellence while learning the codebase and team norms? Include at least five concrete actions per period.

Sample Answer

30-day (Learn & Observe — establish baseline)- Meet stakeholders: product, dev, ops, and on-call rotations to understand expectations and pain points.- Read/run the codebase and deployment pipelines; get dev environment and run one deploy in sandbox.- Attend and shadow on-call shifts and recent incident postmortems to learn runbook usage.- Review current code review checklist and submit 1–2 small PRs following it to model standards.- Audit observable coverage for two critical services (dashboards, alerts, dashboards gaps) and document findings.- Share a 1-page “personal quality standards” note (code review rules, runbook expectations, observable SLIs) with manager for feedback.

60-day (Contribute & Improve — set standards)- Propose and implement one improvement to the code review process (template, checklist enforcement, CI gate).- Update or create runbooks for the top 2 services based on learnings; include clear playbook steps and postmortem links.- Add or tune 3 alerts to align with SLOs/error budget targets; add dashboards for missing SLIs.- Lead a brown-bag on “good runbooks and alerting” and solicit team adoption.- Pair-review 5 PRs with teammates, giving constructive, standard-aligned feedback; document recurring code hygiene items.

90-day (Lead & Scale — model excellence)- Drive adoption: convert personal standards into a team checklist (code review rubric, runbook template, observability playbook) and get team sign-off.- Automate one repetitive reliability task (CI linting rule, alert smoke test) and add it to pipeline.- Run a mock incident war game using updated runbooks and improve gaps found.- Mentor a new joiner or onboard partner pair through the codebase and runbook creation.- Measure impact: show metrics (reduced mean time to mitig., fewer alert floods, PR review time) and present results to the team; iterate standards based on feedback.

Throughout: communicate progress weekly, solicit feedback, be pragmatic about trade-offs, and lead by example—small, repeatable improvements that raise team quality over time.

MediumTechnical

59 practiced

Describe how you'd coach an engineer who consistently delivers technically correct work but ignores reliability best practices (skipping tests, not updating runbooks). Provide the structure of a coaching conversation, specific measurable goals, a timeline for improvement, and how you'd escalate if progress stalls.

Sample Answer

Situation: I have an SRE on my team who consistently delivers correct code but regularly skips unit/integration tests and doesn't update runbooks or playbooks, increasing incident risk.

Coaching conversation structure (45–60 min):1. Open (5 min) — state purpose: align on reliability expectations and their strengths.2. Data (10 min) — show concrete examples: PRs missing tests, incidents where runbooks were absent, metrics (MTTR, post-incident notes).3. Impact (10 min) — explain how missing tests/runbooks affects on-call load, SLOs, team velocity and customer experience.4. Exploration (10 min) — ask for their perspective: blockers, time pressure, skill gaps, tooling friction.5. Agreement (10–15 min) — co-create an improvement plan with clear, measurable goals and support offered.6. Close — recap, next steps, schedule follow-ups.

Specific measurable goals:- Tests: 90% of new changes include unit tests + 80% integration coverage for critical services; enforce via PR checklist and CI gate.- Runbooks: For any change that affects runbook scope, update or add a runbook within 48 hours of merge; reduce runbook-missing incidents to 0 for owned services.- On-call readiness: Participate in 2 runbook review sessions and one war-room drill in 30 days.

Timeline and checkpoints:- Week 1: Agree plan; add PR checklist; pair on writing tests/runbooks for current ticket.- Week 2–4: Weekly 30-min check-ins to review sample PRs, CI pass rates, and runbook updates. Manager audits 5 recent merges.- End of Month 1: Expect 60–70% compliance. If met, continue with same support and raise targets.- Month 2: Target full compliance (as above); demonstrate reduced MTTR or fewer on-call escalations.Metrics tracked: % of PRs with tests, CI failure rate, runbook coverage %, MTTR, number of incidents lacking runbooks.

Support offered:- Pair-programming and test/write-runbook sessions.- Templates for runbooks and test examples.- Adjust workload for first two sprints if time pressure is a blocker.- Training resources or a short workshop on testing strategies and runbook best practices.

Escalation if progress stalls:1. Formalize expectations in a documented performance improvement plan (30–60 days) with the same measurable goals and weekly reviews.2. If no improvement: restrict on-call responsibilities until compliance improves; remove ownership of critical services.3. Final step: HR-managed performance follow-up which may include role change or termination if repeated non-compliance endangers reliability and customers.

This approach balances empathy and coaching with clear metrics, hands-on support, and progressive escalation tied to business risk.

EasyTechnical

76 practiced

How do you define 'high-quality automation' for a recurring operational task such as canary deployments or database schema migrations? List the acceptance criteria you require before automating and one metric you'd track to ensure the automation actually reduced operational risk.

MediumTechnical

60 practiced

Create a practical post-incident review (postmortem) template that emphasizes learning, clear accountability for actions, and prevention. List all required fields, how you assign and track action owners, and how you ensure corrective items are validated and closed in future reviews.

Sample Answer

Postmortem Template (practical, learning-focused)

1) Summary- Incident ID, service(s) affected, severity, timeline (start/end), customer impact (users, % requests, revenue), detection method.

2) Scope & Context- Systems/components involved, recent related changes (deploys, config), SLOs/error budget status.

3)Timeline (chronological)- Timestamped events: detection, mitigation steps, communications, rollback, recovery.

4)Root cause analysis- Contributing factors (technical + process + people), root cause statement (one-sentence), evidence (logs, traces, metrics).

5)Immediate remediation taken- Actions performed in incident to restore service.

6)Long-term corrective actions (Action Items)For each action:- ID- Title- Description- Owner (individual, not team)- Priority (P0/P1/P2), ETA- Success criteria / acceptance test (measurable)- Dependencies- Status (Open / In Progress / Blocked / Validated / Closed)

7) Communication & stakeholder notes- Who was notified, public postmortem link, customer messaging.

8) Lessons learned- What worked well; what to change in runbooks/process/alerts.

9) Follow-up reviews- Required checkpoints (30/60/90 days), metrics to track (error rate, MTTR, alert fatigue).

Assigning & tracking action owners- Owners assigned during postmortem meeting; must be a named person with capacity confirmed.- Record in a single tracking system (ticket in Jira/GitHub Issues) using templated issue body matching the action fields above.- Add SLAs: owner updates ticket weekly; automated reminders via workflow (e.g., Jira automation, Slack reminders).

Validation & closure process- Each action requires an acceptance test defined up front. Owner implements change, opens PR/changes, and links evidence (dashboards, logs, test results) in ticket.- Independent reviewer (rotating SRE on-call or incident commander) verifies acceptance criteria and changes in staging/production, then marks status "Validated."- Closure only after validation and after the next scheduled follow-up review confirms the metric(s) remain improved.- Quarterly audit: random sample of closed postmortem actions reviewed to ensure quality; repeat offenders trigger process improvement.

Governance- Postmortems posted within 72 hours draft; final within 7 days.- Non-blameless for learning; focus on systemic fixes and measurable outcomes.

HardTechnical

74 practiced

Design an organizational rubric that ties SRE hiring, promotions, and performance reviews to measurable behaviors that model excellence. Propose six criteria (with examples of evidence for each), how to weigh them across junior to principal levels, and how to operationalize the rubric in reviews and calibration meetings.

Sample Answer

Design a rubric with six measurable SRE competencies, example evidence, level-weighting, and operationalization steps.

Criteria & evidence examples:1) Reliability Engineering (SLOs, error budgets) - Evidence: defined SLOs, tracked error budget, automated enforcement, reduction in SLA breaches2) Incident Response & Postmortem Quality - Evidence: on-call mean time to acknowledge/restore improvements, blameless postmortems with root cause + action items implemented3) Automation & Tooling - Evidence: production automation (runbooks codified, deploy pipelines, infra-as-code), reduction in manual toil hours4) Observability & Metrics - Evidence: meaningful dashboards/alerts, signal-to-noise ratio improvements, actionable alerts with documented thresholds5) Scalability & Performance Engineering - Evidence: capacity plans, load-test results, cost/throughput optimizations with measurable gains6) Collaboration & Leadership - Evidence: cross-team projects led, mentorship, knowledge sharing, influence on product design for reliability

Weighting by level (percent emphasis):- Junior: Reliability 25 / Incident 20 / Automation 20 / Observability 15 / Scalability 10 / Collaboration 10- Mid: Reliability 20 / Incident 20 / Automation 20 / Observability 15 / Scalability 15 / Collaboration 10- Senior: Reliability 18 / Incident 18 / Automation 18 / Observability 14 / Scalability 16 / Collaboration 16- Staff/Principal: Reliability 15 / Incident 15 / Automation 15 / Observability 13 / Scalability 18 / Collaboration 24

Operationalization:- Rating scale (1–5) per criterion with explicit behavioral anchors (e.g., 3 = meets expectations: owns playbooks; 5 = far exceeds: drives org-wide SLO adoption).- Hire: use rubric to score candidates on structured interviews; require minimums in core criteria for role level.- Reviews/Promotions: employees self-rate with evidence; manager rates and provides examples mapped to rubric anchors; calibration panel normalizes scores + reviews supporting artifacts (postmortems, PRs, dashboards).- Promotion gate: require ≥4 average and high marks in at least two leadership/scaling criteria for senior→principal.- Continuous feedback: quarterly mini-checks against rubric, track objective metrics (MTTR, toil hours saved, SLO attainment) in a dashboard for review meetings.This creates transparent, evidence-based hiring, review, and promotion decisions tied to measurable SRE behaviors.

Unlock Full Question Bank

Get access to hundreds of Setting and Modeling Excellence interview questions and detailed answers.

Join thousands of developers preparing for their dream job.