Maintainability and Legacy Code Questions

Covers strategies and principles for evolving codebases safely and keeping them easy to understand and change over time. Topics include design principles such as Single Responsibility, Open Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion, removing duplication, establishing appropriate abstraction boundaries, separation of concerns, identifying and remediating code smells, incremental refactoring approaches, regression risk mitigation via tests and feature toggles, backward compatibility and migration strategies, and prioritizing technical debt reduction. Interviewers assess the candidate ability to plan pragmatic refactors, minimize risk during change, and improve long term health of a codebase.

EasyTechnical

84 practiced

You manage a backlog of technical debt across multiple low-priority SRE services and have limited engineering time. Describe a framework to prioritize which technical debt to address first, including measurable criteria and how to present the trade-offs to product and platform stakeholders.

Sample Answer

Situation: I inherited a backlog of technical debt across several low-priority SRE services with limited engineering bandwidth and ongoing feature work.

Task: I needed a repeatable way to pick the highest-value debt to fix, justify decisions quantitatively, and communicate trade-offs to product and platform stakeholders.

Action:- I defined a simple prioritization framework with measurable criteria and weights: - User/Business Impact (SLO violations, customer tickets): 30% - Operational Risk (likelihood of incident, blast radius): 25% - Cost to Run (observability/maintenance time, PagerDuty churn): 20% - Effort (person-weeks to remediate): 15% — scored inversely - Strategic Alignment (roadmap, compliance): 10%- For each debt item I scored 1–5 on each criterion, multiplied by weights, yielding a priority score.- I instrumented supporting metrics: recent SLO breaches, MTTR contribution, # of incidents in 90 days, on-call hours spent, and estimated engineering effort from similar past tasks.- I grouped items into buckets: Quick Wins (score high, low effort), High-Risk (high impact, may be medium effort), and Backlog (low score).- I proposed a cadence: reserve 20% of sprint capacity for debt, review prioritization monthly, and re-score after incidents.

Result / How I present trade-offs:- I present a one-page dashboard showing: prioritized list, score breakdown, key metrics (SLO impact, incidents avoided), and cost vs. benefit (effort vs. estimated reduction in incidents/on-call hours).- For stakeholders I translate technical terms into business outcomes: e.g., “Fixing A reduces incident rate by ~40%, likely saving 30 on-call hours/month and protecting our 99.9% SLO — estimated 2 sprint effort.”- I highlight opportunity cost: what feature work we defer and expected business impact.- I recommend experiments: implement 1–2 Quick Wins first, measure improvement, then re-evaluate.

This approach makes prioritization transparent, measurable, and aligned to business risk so stakeholders can make informed trade-offs.

EasyTechnical

89 practiced

Describe the Open/Closed Principle (OCP) and provide an SRE-focused example: you need to add new remediation strategies to an existing incident-response engine without modifying core evaluation logic. How would you design extensibility while keeping the system stable?

EasyTechnical

131 practiced

Explain the Single Responsibility Principle (SRP) and describe how you would apply it when refactoring a monolithic SRE automation script that currently handles alert parsing, remediation actions, log aggregation, and metrics emission. Identify concrete responsibilities you would separate, the benefits for reliability and testing, and one potential trade-off.

HardTechnical

135 practiced

A configuration key used by many services must be removed. Design a phased removal plan that incorporates code-level shims (fallbacks), automated detection of remaining usages, migration scripts, and a communication plan. Explain how to coordinate teams and enforce removal safely.

Sample Answer

Overview: I’d run a staged, low-risk deprecation over 6–12 weeks that combines in-code shims, automated discovery, migration tooling, strong observability, and an explicit communication/enforcement cadence so teams can migrate safely.

Phase 0 — Prep (week 0)- Inventory: Query config store, code search, telemetry logs to list services using the key.- Risk scoring: Rank by traffic, owner, and blast radius.- Define success metrics and SLOs (e.g., <1% errors introduced, rollout time).

Phase 1 — Shim + Telemetry (week 1–2)- Ship a code-level shim: when new_key present use it; when absent, read old_key and emit structured telemetry (counter, trace span, log with service+version+callsite).- Shim behavior: read-only fallback; emit deprecation header/tracing for request flows.- Tests: unit tests for shim, integration tests in staging.

Phase 2 — Automated Detection & Reporting (week 2–4)- Deploy log-parsing jobs and a lightweight agent to detect usages at runtime (grep, static analysis, CI hooks).- Build a dashboard: per-service remaining usages, trend, owner contact.- Alerts: Slack/email to owners when usage >0 after grace period.

Phase 3 — Migration Tooling (week 3–6)- Provide migration scripts/CLI that: 1) copy config values to new key in vault/kv, 2) update infra-as-code templates, 3) create PR templates.- Offer playbook for common frameworks (Kubernetes, Nomad, serverless).- Run a squad-offered “migration clinic” to help owners.

Phase 4 — Controlled Enforcement (week 6–10)- Soft lock: CI lint/PR check warns and blocks merges that add old_key usage.- Hard lock (after warning window): CI failure and runtime guard that throws in non-backcompat mode.- Gradual rollout: enable hard guard in canary namespaces → staging → prod groups.

Phase 5 — Removal & Validation (week 10–12)- Once dashboard shows zero usage and no alerts for N days, remove shim from codebase in a coordinated release window.- Post-removal smoke tests, SLO verification, and 72-hour monitoring window.

Coordination & Communication- Kickoff doc + timeline in central channel and org-wide announcement.- Weekly status report and migration leaderboard; mandatory owners’ list with escalation path.- Office hours and migration playbook repo.- Enforce via CI gates + automation; final approval required from SRE for shim removal.

Safety & Rollback- Feature flags for shim removal to toggle quickly.- Automated rollback playbooks and runbooks for common failure modes (auth errors, missing secrets).- Postmortem + lessons captured after incidents.

Why this works- Shims minimize immediate risk while telemetry makes invisible usage visible.- Automation reduces manual work and enforces consistency.- Gradual enforcement plus clear communication lets teams plan, migrate, and recover safely.

EasyTechnical

65 practiced

Explain Liskov Substitution Principle (LSP) in the context of monitoring collectors: suppose you replace an existing collector class with a subclass that adds a new optional metric but changes return semantics for some methods. What problems can violate LSP and how would you avoid them when evolving collectors?

Sample Answer

Liskov Substitution Principle (LSP) says a subclass should be usable anywhere its base class is expected without changing correct program behavior. For monitoring collectors this means replacing a collector with a subclass that “adds” metrics must not change existing method semantics (return types, error behavior, side effects, performance) relied on by consumers (alerting, dashboards, exporters).

Problems that violate LSP in collectors- Changed return semantics: returning None, different types, or changing meaning of numeric values breaks downstream parsers/alerts.- Different error/exception behavior: throwing exceptions where base returned empty results causes crashes.- Side-effect changes: new network calls, blocking I/O, or higher resource use affecting collection timing and SLOs.- Metric signature changes: renaming metrics, changing label sets, or units breaks dashboards and aggregation queries.- Changed sampling or aggregation semantics: different cardinality or distribution breaks SLIs.

How to avoid violations (practical SRE guidance)- Preserve method contracts: keep return types, error behavior, and semantics identical. New metrics should be additive only.- Add optional metrics via new methods or clearly documented optional fields; never overload existing fields with new meanings.- Maintain backward-compatible metric names/labels; if you must change, emit both old and new names for a deprecation window.- Use non-blocking collection and respect time budgets; avoid added heavy work in hot paths.- Version and feature-flag changes: release a new minor/major version per semantic-version rules and gate risky changes behind flags.- Contract and integration tests: unit tests, collector contract tests, and end-to-end checks against dashboards and alert rules.- Document deprecations and run a deprecation policy (announce, dual-write, remove after grace period).

Example: if Collector.collect() previously returned dict[str, float], a subclass must still return that shape. To add histogram data, add collect_histogram() or include an optional "histograms" key that callers can ignore, and ensure existing consumers still see the same keys and values.

Unlock Full Question Bank

Get access to hundreds of Maintainability and Legacy Code interview questions and detailed answers.

Join thousands of developers preparing for their dream job.