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

89 practiced

As a Solutions Architect, how would you advise a product manager and engineering lead to prioritize small technical-debt items in a sprint backlog when deadlines are tight? Provide a repeatable prioritization heuristic and an example of a small trade-off you might recommend.

EasyTechnical

87 practiced

Define "technical debt" in language suitable for non-technical stakeholders. List three measurable indicators you would use to quantify technical debt in a codebase, how you would collect those metrics (tools/process), and one way to convert those indicators into business impact.

EasyTechnical

71 practiced

Explain the SOLID principles (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion) and, as a Solutions Architect, describe concrete signs you would look for in a legacy codebase that indicate each principle is violated and practical steps to remediate those violations.

Sample Answer

Single Responsibility Principle (SRP)- Definition: A module/class should have one reason to change.- Signs in legacy code: Large classes (>500 LOC), many unrelated methods, mixed concerns (IO + business logic + formatting), frequent changes touching same file for different reasons.- Remediation: Extract responsibilities into smaller classes/services, create clear boundaries (e.g., separate persistence, validation, presentation). Apply strangler pattern: route new functionality into new classes, add tests, incrementally refactor.

Open/Closed Principle (OCP)- Definition: Modules should be open for extension, closed for modification.- Signs: Repeated edits to core classes to add new behavior, large switch/case or if-else chains keyed by type, feature flags hacked into core.- Remediation: Introduce abstractions (interfaces/strategy pattern), use dependency injection, add extension points (plugins), write regression tests before changing behavior.

Liskov Substitution Principle (LSP)- Definition: Subtypes must be usable wherever base types are expected without altering correctness.- Signs: Subclasses overriding behavior in incompatible ways, runtime type checks (instanceof), unexpected exceptions from subclasses, conditional logic checking concrete types.- Remediation: Redesign hierarchies to prefer composition over inheritance, extract common contracts into interfaces, add behavioral tests to capture expectations.

Interface Segregation Principle (ISP)- Definition: Clients should not be forced to depend on methods they don't use.- Signs: Fat interfaces with many methods, classes implementing no-op methods, broad service interfaces injected everywhere.- Remediation: Split interfaces into role-specific ones, use Adapter/Facade where necessary, refactor consumers to depend on minimal interfaces.

Dependency Inversion Principle (DIP)- Definition: High-level modules should not depend on low-level modules; both should depend on abstractions.- Signs: High-level modules importing concrete implementations, new features requiring touching many modules to change dependencies, poor testability (hard to mock).- Remediation: Introduce interfaces/abstract factories, wiring via IoC containers, invert dependencies gradually using the strangler pattern, add integration and unit tests to validate wiring.

As a Solutions Architect I prioritize: automated tests before refactor, incremental changes using the strangler pattern, defining clear module boundaries in architecture docs, and aligning refactors with business priorities (low-risk high-impact first).

HardTechnical

74 practiced

You must secure executive approval to allocate 20% of engineering capacity for a quarter to tackle technical debt across multiple product areas. Prepare the pitch: what metrics you would present (current state), expected outcomes, phasing of the work, KPIs to report, and contingency plans if feature delivery is impacted.

Sample Answer

Situation: I need executive approval to dedicate 20% of engineering capacity for one quarter to address technical debt that spans multiple product areas. Below is a concise, business-focused pitch I’d present.

Current-state metrics to show (baseline):- Defect escape rate: X defects/week (last 90 days) and trend (+% QoQ)- Mean Time to Recovery (MTTR): current median hours- Lead time for changes / cycle time: average days from PR to production- Sprint velocity variance: % of committed vs delivered- Customer-impact metrics: NPS drop, number of severity-1 incidents, churn rate attributable to reliability- Cost of rework: hours/month × fully-loaded $/hour = $/month- Tech-debt inventory: count and severity (estimated story points & risk score)

Expected outcomes (quarter):- Reduce defect escape rate by 30%- Improve MTTR by 40%- Reduce cycle time by 20% (faster sales enablement and demoability)- Recover ~X hours/week previously spent firefighting → frees up future feature capacity- Lower projected rework cost by Y% → payback within 2–3 quarters

Phasing (4-stage, with milestones):1. Discovery (Weeks 0–2): triage debt inventory, tag high-risk items, define quick wins and architectural risks.2. Prioritization & Sprint Planning (Weeks 2–3): map fixes to OKRs and revenue/risks; allocate backlog into 20% capacity slots.3. Execution (Weeks 4–12): run 20% capacity across teams in sprint cadence: 60% quick wins (tests, CI, critical refactors), 40% platform/architectural improvements.4. Validation & Handoff (Week 13): measure outcomes, update runbooks, bake fixes into definition-of-done.

KPIs to report (weekly + monthly):- Weekly: number of debt tickets closed (by severity), cycle time for PRs, open critical incidents, sprint velocity delta- Monthly: defect escape rate, MTTR, customer-impact incidents, estimated hours freed, rework cost delta- End-of-quarter: ROI estimate (hours saved × $) vs investment, trend graphs vs baseline

Contingency plans if feature delivery is impacted:- Triage and de-scope: freeze lower-priority non-revenue features; negotiate minimum viable scope with PMs- Parallelize: split teams—core teams continue feature delivery while a small specialist squad handles high-risk debt- Time-boxing: cap work per sprint; if remediation overruns, shift to quick-win safety fixes only- Feature toggles & phased rollouts to reduce risk and allow safe refactoring- Re-evaluate after 2 sprints; if feature SLAs breach, pause non-critical debt tasks and reallocate- Executive checkpoint: provide data-driven trade-offs for go/no-go on next quarter’s roadmap

Why this matters (ROI): Presenting reduced incidents, faster delivery, and lower rework translates directly to lower support cost, higher customer retention, and faster time-to-revenue for new features—typically paying back the 20% investment within 2–3 quarters.

I’d accompany this pitch with dashboards (Grafana/Jira/Datadog) showing baseline trends and a mapped backlog of prioritized debt with business risk and estimated effort.

EasyTechnical

76 practiced

What is a code smell? Identify five common code smells you would flag during a legacy-code review (e.g., god object, long method) and, for each, give a brief remediation strategy and the minimal safety nets (tests/controls) you'd require before changing the code.

Sample Answer

A code smell is a surface indicator in code that suggests deeper design problems — not necessarily a bug, but something that makes the code hard to understand, maintain, or extend. As a Solutions Architect reviewing legacy systems I flag smells that imply architectural risk and recommend safe, incremental remediation.

1) God Object (big class with many responsibilities)- Remediation: Identify cohesive responsibility clusters, apply Extract Class/Service, push responsibilities into well-defined modules or microservices where appropriate.- Safety nets: Characterization tests (black-box integration tests), API contract tests, and a migration plan with backward-compatible adapters.

2) Long Method- Remediation: Extract smaller private functions with descriptive names; if logic repeats, factor into helper/util classes.- Safety nets: Unit tests around method behavior (input/output), and regression tests ensuring side-effects unchanged.

3) Feature Envy (method uses another class’s data heavily)- Remediation: Move method to the class it envies or introduce a Facade/DTO to reduce coupling.- Safety nets: Unit tests for method behavior before/after move and integration tests for callers.

4) Shotgun Surgery (small change requires touching many files)- Remediation: Increase encapsulation — centralize cross-cutting concerns (use patterns like Observer, Strategy, or a service layer); introduce APIs to hide internals.- Safety nets: End-to-end tests for affected flows, contract tests between modules, and a phased rollout with feature flags.

5) Rigidity/Excessive Coupling- Remediation: Introduce clear boundaries, define interfaces/ports, apply Dependency Injection and layering; decouple with message-driven designs if needed.- Safety nets: Integration tests for each layer, CI checks enforcing module boundaries, and performance/latency monitoring post-change.

General precautions: start with characterization (readme, dependency graph), write tests that capture current behavior (golden-master tests) before refactor, make small iterative changes, and ensure deployment safety via feature flags/rollback plans and monitoring.

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.