Handling Feedback and Dealing with Setbacks Questions

Share examples of when you received critical feedback or faced a setback. Show you accepted feedback with a growth mindset. Explain what you learned and how you improved. Demonstrate resilience and the ability to bounce back from challenges.

EasyTechnical

29 practiced

Share a time you discovered a small but recurring reliability issue and were criticized for not fixing it earlier. How did you respond to the criticism, prioritize remediation, and ensure the issue did not escalate into a major outage?

HardTechnical

28 practiced

Your team experienced a multi-hour outage affecting enterprise customers and executives criticized the SRE team's preparedness. How would you prepare a remediation roadmap, defend prior SLO choices, accept responsibility, and rebuild executive trust while ensuring transparency?

Sample Answer

Situation: A multi-hour outage hit enterprise customers; executives criticized the SRE team’s preparedness and visibility.

Approach: I’d create a clear, accountable remediation roadmap, explain past SLO choices with data, accept responsibility for process gaps, and outline concrete steps to restore trust and transparency.

Remediation roadmap (30/60/90 day with owners and metrics):- 0–7 days (triage + containment): publish an incident timeline, customer impact matrix, and short-term mitigations (rate-limits, failovers). Owner: on-call lead. Metric: % impacted customers and MTTR baseline.- 7–30 days (root-cause & fixes): complete RCA, implement code/config fixes, run targeted chaos tests. Owners: release manager + platform eng. Metric: fix verification tests passing and rollback procedures validated.- 30–60 days (hardening): add missing runbooks, automate key playbook steps, improve alerting thresholds and dashboards for enterprise SLAs. Owner: SRE tooling lead. Metric: reduction in noisy alerts and time-to-detect.- 60–90 days (prevent recurrence & org): adopt post-deploy canary gates, capacity planning cadence, and SLO review cycle with product/finance. Metric: SLO burn rate reporting integrated into exec dashboard.

Defend prior SLO choices:- Present the data used when SLOs were set (usage, error budgets, customer tiers), trade-offs considered (feature velocity vs reliability), and where assumptions changed (traffic patterns, new integrations).- Where SLOs were insufficient, acknowledge and propose concrete new targets or tiered SLOs for enterprise customers.

Accept responsibility & communication:- Own the gaps publicly: state what we missed (e.g., insufficient alerting, lack of runbook for this failure mode), not excuses.- Commit to timelines, owners, and measurable success criteria.- Offer regular executive briefs (weekly until stable) with dashboards, actions completed, and remaining risks.

Rebuild trust & ensure transparency:- Publish the RCA and roadmap to executives and affected customers with a Q&A session.- Provide an executive dashboard showing SLOs, burn rates, incident frequency/severity, and planned mitigations.- Invite executive stakeholders into periodic reliability reviews and include their priorities in SLO trade-offs.- Deliver quick wins (improved monitoring, customer communication templates) within 30 days to demonstrate momentum.

Outcome expectation:- Rapid mitigation reduces immediate risk; measurable improvements in MTTR and SLO compliance within 90 days; restored executive confidence through consistent, data-driven updates and shared ownership across product and engineering.

EasyTechnical

30 practiced

When you receive critical feedback from a peer engineer or manager about a change you proposed, what is your immediate approach? Walk through your mental checklist from listening and clarifying to deciding whether to act, adapt, or defend your proposal as an SRE.

MediumBehavioral

32 practiced

You received feedback during a performance review that you need to improve cross-team influence. Describe specific steps you took to build stronger cross-functional relationships, the tactics you used, and measurable outcomes from those changes.

HardSystem Design

25 practiced

You discover a deep-rooted architectural issue causing intermittent failures and senior engineers criticize past decisions you made. Describe how you would present a remediation plan, prioritize technical debt versus feature work, and lead implementation while maintaining service reliability.

Sample Answer

Situation & context: On joining a service team I discovered a deep-rooted architectural issue — a shared synchronous dependency causing cascading, intermittent failures under load. Senior engineers questioned past design choices and brought up technical debt accrued over years.

Remediation plan (high level, with constraints):- Goal: Stop user-facing failures within one incident window; reduce recurrence risk; deliver a roadmap to fully remediate without jeopardizing availability or velocity.- Constraints: limited runway, existing SLOs/error budget, stakeholder timelines.

Immediate actions (0–2 weeks):- Implement rapid mitigations that reduce blast radius: add circuit breakers, bulkheads (thread/connection pools), and request queuing/priority. Use feature flags for quick toggles.- Harden monitoring: add granular latency/error metrics for the dependency, create dashboards and alerts tied to SLOs so we detect regressions early.- Run a risk assessment and rollback plan for each mitigation.

Short-term remediation (2–8 weeks):- Design an incremental decoupling plan: introduce async patterns (queues/events) for non-critical sync paths, add retries with backoff for critical calls, and introduce a façade service to encapsulate the problematic dependency.- Break work into small, testable increments (canary rollouts, dark launches) to validate stability.

Prioritization: technical debt vs feature work- Use SLO-driven prioritization: compute expected impact of debt work on error budget and business value of features.- For each item estimate (risk reduction, dev effort, customer impact). Prioritize work that yields the largest SLO improvement per engineering-week.- Negotiate a cadence: reserve a fixed slice of capacity (e.g., 30–40%) for reliability work until debt is reduced to acceptable levels; allow critical feature work if it pays down debt or is low-risk.

Leading implementation & maintaining reliability- Form a small cross-functional reliability squad (SRE + product engineer + QA) with clear ownership and SLAs for mitigation tasks.- Use a staged rollout process: automated tests -> canary -> monitor error budget -> full rollout. Automate rollbacks.- Keep communication transparent: daily standups during rollout, status pages for stakeholders, and an escalation path for incidents.- Run chaos exercises and load tests before major changes.- After each incremental change, run a post-deployment review and update runbooks/operational playbooks.

Trade-offs and rationale:- Favor incremental decoupling and mitigation to reduce user impact vs. one big-bang rewrite which is high-risk and time-consuming.- Preserve throughput and latency targets by isolating high-risk paths behind circuit breakers and queues.- Investment in observability and automation pays dividends: faster detection, safer rollouts, lower long-term ops cost.

Outcome metrics to track:- Error budget consumption, mean time to detect/restore (MTTD/MTTR), tail latency percentiles, deployment failure rate, and ticket volume related to the old dependency.

This approach balances immediate reliability, measured technical debt reduction, and continued feature delivery while providing clear, SLO-driven justification to senior engineers and stakeholders.

Unlock Full Question Bank

Get access to hundreds of Handling Feedback and Dealing with Setbacks interview questions and detailed answers.

Join thousands of developers preparing for their dream job.