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.

HardSystem Design

65 practiced

Explain how to introduce consumer-driven contract testing between frontend and backend teams to reduce regressions during incremental refactors. Describe tooling choices, test ownership (who writes/maintains contracts), how to store and version contracts, how to run them in CI, and strategies for handling backward-compatible changes.

Sample Answer

**Clarify goal & scope**Introduce consumer-driven contract testing so frontend (consumer) specifies expected API shapes and backend (provider) verifies them — reducing regressions during incremental refactors.

**High-level approach**- Frontend team writes contract tests describing requests, responses, status codes, and error shapes for UI-critical flows.- Backend runs provider tests against its implementation to ensure it meets consumer expectations.

**Tooling**- Pact (JS) or Pactflow for hosted broker — strong consumer-driven flow.- Alternative: Stoplight / Prism + OpenAPI contracts if teams prefer spec-first.- Local: pact-js for frontend unit/integration; pact-jvm/pact-go for backend verification.

**Test ownership**- Frontend (consumer) authors and maintains consumer contracts (unit or integration tests in Jest/RTL).- Backend maintains provider verifications and failure handling.- Cross-team SLA: consumers update contracts when UI requires changes; providers review PRs and respond.

**Store & version**- Publish contracts to a contract broker (Pact Broker) with semantic versions + consumer tags (branch/name).- Tag contracts per environment (dev, staging) and use CI to promote.

**CI flow**- Frontend CI: run consumer contract tests; on success publish contract to broker (tag by branch/PR).- Backend CI: fetch relevant contracts from broker and run provider verification against service (including deployed staging instance); fail build on mismatch.- Use gating: deploy to staging only if provider verification passes.

**Backward-compatible changes**- Use semantic versioning and consumer version tags.- For additive, non-breaking changes (new optional fields): allow by default; document in contract.- For breaking changes: create feature flag or versioned endpoint; update contract and coordinate release window. Use canary/staged rollout and acceptance tests on real UI flows.

**Operational tips**- Keep contracts focused on UI-critical fields (avoid over-specifying).- Automate contract publication on PR merge; require provider verification before release.- Run contract checks in PRs: frontend PR posts contract; backend PR verifies against it to catch integration issues early.

EasyTechnical

77 practiced

Explain how adopting TypeScript (gradually) improves maintainability of a legacy JavaScript frontend. Include examples of type-safety preventing common refactor bugs, how types assist IDE refactors, and pitfalls to watch for during an incremental migration.

Sample Answer

**Approach summary**Adopting TypeScript gradually improves maintainability by adding static types that catch errors earlier, make intent explicit, and enable safer automated refactors while letting a legacy JS codebase keep running.

**Type-safety prevents refactor bugs**- Example: renaming a prop used across components; TS surfaces mismatches at compile time.

// Before refactor
type User = { id: string; name: string };
function greet(u: User) { return `Hi ${u.fullName}` } // error: fullName doesn't exist

- Without types, a rename from `name`→`fullName` could cause runtime undefineds; with TS the compiler forces fixes.

**Types assist IDE refactors**- IDEs use type info for accurate rename/Find-References, auto-imports, and safe signature changes. Changing a function signature shows all call sites to update, reducing manual search.

**Incremental migration pitfalls**- Any types left as `any` reduce benefit—avoid overusing `// @ts-ignore` or `any`.- Mixed code can create false confidence; add strictness progressively (noImplicitAny, strictNullChecks).- Build complexity: configure tsconfig paths, transpilation and sourcemaps; ensure tests run both JS/TS.- Runtime mismatches (untyped third-party libs): add minimal declaration files or use community typings.

**Best practices**- Start with types for public module boundaries, props, and API responses.- Use `ts-migrate` or codemods, add tests, and incrementally tighten compiler options.

MediumSystem Design

69 practiced

Design a plugin architecture for extensible UI widgets so new behaviors can be added without modifying existing widget core. Explain extension points, how plugins should register, how to validate/secure plugins, how to manage lifecycle and performance costs, and how to avoid breaking backward compatibility as plugins evolve.

Sample Answer

**Clarify scope**I’d design a frontend plugin system so widget cores (React/Vue components) expose sealed extension points where plugins add behavior without changing core code.

**Extension points**- Props/hooks: core exposes lifecycle hooks (onInit, beforeRender, afterRender, onDestroy).- Slots/events: named slots or custom events for UI injection.- Middlewares: pipeline for input/data transformation.- Capabilities API: read-only and controlled-write APIs (setState, dispatchAction).

**Plugin registration**- Declarative manifest + factory function:

javascript

// plugin manifest
registerPlugin({
  id: "tooltipEnhancer",
  version: "1.2.0",
  capabilities: ["ui-inject","hook-afterRender"],
  factory: (api, opts) => ({ init(){api.hooks.afterRender(...)} })
});

- Host validates manifest, resolves deps, and instantiates plugin with a constrained API.

**Validation & security**- Static validation: schema-check manifest (JSON Schema), version compatibility.- Runtime sandboxing: pass only limited API surface; avoid eval/remote code.- CSP + SRI for plugin bundles; code signing and allowlist for production.- Permission model: plugins request capabilities; user/admin approves.

**Lifecycle & performance**- Lifecycle: init -> mount -> update -> teardown. Core calls hooks deterministically.- Lazy load plugins on demand; use code-splitting and dynamic import().- Throttle expensive hooks, batch DOM updates, memoize, and provide cancellation tokens for async ops.- Monitor plugin cost (CPU, network) and expose telemetry; enforce resource quotas or disable offending plugins.

**Backward compatibility**- Semantic versioning for plugin API. Core provides stable facades; new APIs added opt-in.- Deprecation policy: log warnings, feature flags, adapters that map old calls to new APIs.- Strict interface contracts with runtime checks to fail fast and guide migration.

This design keeps the widget core minimal, secure, observable, and stable while enabling third-party extensions.

EasyTechnical

61 practiced

Identify duplication in the CSS below and propose a maintainable refactor using variables, utility classes, or component-scoped styles. Explain why your approach reduces cognitive load and prevents visual regressions.

css

.card-title { font-size: 16px; color: #333; margin-bottom: 8px; }
.product-title { font-size: 16px; color: #333; margin-bottom: 8px; }
.notification-title { font-size: 16px; color: #333; margin-bottom: 8px; }

Sample Answer

**Identify duplication**All three selectors repeat the same declarations:font-size: 16px; color: #333; margin-bottom: 8px;

**Refactor option 1 — design tokens + utility**Declare tokens and a reusable utility class so any component can opt in.

css

:root {
  --type-title-size: 16px;
  --type-title-color: #333;
  --type-title-gap: 8px;
}

/* utility */
.u-title {
  font-size: var(--type-title-size);
  color: var(--type-title-color);
  margin-bottom: var(--type-title-gap);
}

Usage in HTML:

html

<h3 class="card-title u-title">…</h3>
<h2 class="product-title u-title">…</h2>

**Refactor option 2 — component-scoped (BEM)**If titles are conceptually different components, scope styles but share a single token:

css

.card__title,
.product__title,
.notification__title {
  font-size: var(--type-title-size);
  color: var(--type-title-color);
  margin-bottom: var(--type-title-gap);
}

Or define a shared component class:

css

.title { /* shared component class */ }

**Why this reduces cognitive load & prevents regressions**- Single source of truth (CSS variables) means changing size/color/gap updates everywhere, avoiding inconsistent fixes.- Utility/shared class makes intent explicit: any element with .u-title will match design spec.- Component-scoped classes keep semantics clear, while still referencing tokens, so local overrides are deliberate.- Fewer duplicated declarations reduces reviewer overhead and lowers chance of visual regressions during updates.

HardTechnical

60 practiced

Your legacy SSR web application has grown a large client bundle. Propose a plan to reduce client bundle size using code-splitting, dynamic imports, tree-shaking, and dependency analysis while preserving SSR and hydration stability. Explain pitfalls (e.g., mismatched markup, loading race conditions) and how to test that hydration remains correct across split points.

Sample Answer

**Approach overview**- Goal: shrink initial client bundle while keeping server-side render (SSR) stable and hydration deterministic.- Use: route- and component-level code-splitting, dynamic imports with SSR-aware loaders, aggressive tree-shaking, and dependency analysis to remove/replace heavy libs.

**Plan**1. Audit - Bundle analyzer (webpack-bundle-analyzer, source-map-explorer) to identify hotspots. - Static dependency scan (depcheck) + runtime profiling to find unused/large deps.2. Split strategy - Route-level splits for non-critical pages. - Component-level splits for heavy widgets (charts, maps). - Vendor splitting for large third-party libs; load less-critical vendors async.3. Implementation details - Use framework SSR-compatible dynamic import helpers (e.g., React.lazy + loadable/component or Next.js dynamic with ssr:true/false) so server can render necessary chunks and emit the right module IDs. - Ensure server renders the same React tree shape (render same components or placeholders) so markup matches. - Tree-shake: enable production mode, sideEffects:false in package.json, and prefer ESM packages; replace heavy libs with lighter alternatives.4. Dependency moves - Move large assets to CDN, lazy-load non-essential CSS/JS. - Replace client-only utilities with server-safe alternatives or guard them behind typeof window checks.

**Pitfalls & mitigations**- Mismatched markup/hydration errors: - Ensure server and client render same markup for each split point. If lazy components render placeholders on server, client must hydrate to same placeholder then replace—avoid rendering entirely different DOM shapes. - Use loadable/component SSR API to preload chunks on server and include chunk manifest so client can fetch identical modules.- Loading race conditions: - Race between hydration and chunk fetch -> freeze or error. Preload critical chunks (link rel=preload/prefetch) and server-include module list. - Use streaming SSR or suspense boundaries carefully; ensure fallback UI is deterministic.- Third-party scripts with side effects: - Defer or lazy-init after hydration; isolate in web workers when possible.

**Testing hydration correctness**- Automated tests: - End-to-end tests (Playwright/Cypress) that load fresh page, wait for hydration, and assert no console hydration errors and interactive behaviors work. - Snapshot tests comparing server HTML to client DOM after hydration (server-render HTML === document.documentElement.innerHTML before/after hydration of non-dynamic parts). - Unit tests for split points: prefetch chunks in test harness and assert component identity/state preserved.- Metrics and monitoring: - Runtime logs for hydration errors, breakage rates, and time-to-hydration. - Canary releases and feature flags to roll back problematic splits.

**Trade-offs**- More splitting reduces initial JS but increases requests and complexity; mitigate with HTTP/2, preloading, and bundler optimization.- Conservative server-side preloading improves stability but raises initial payload slightly.

This plan balances aggressive size reduction with SSR/hydration stability via careful split boundaries, SSR-aware dynamic imports, preloading critical chunks, and automated tests to catch mismatches early.

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.