Clean Code and Best Practices Questions

Covers the principles and hands on practices that produce readable, maintainable, and reliable code. Core elements include intent revealing and consistent naming, small focused functions and classes that follow single responsibility, avoiding duplication through refactoring and appropriate abstractions, clear structure and separation of concerns, following language specific idioms and style guides, consistent formatting, concise comments that explain nonobvious intent, defensive programming and robust error handling, edge case handling and input validation, use of linters and static analysis, incremental refactoring techniques, and pragmatic trade offs between ideal design and delivery constraints. Interviewers will also probe involvement in code reviews, version control hygiene, code metrics, and how candidates advocate for and teach coding standards to peers.

MediumTechnical

135 practiced

You need to introduce a new coding standard (for example: formatters and linters with strict rules) across several teams with varying codebases. Outline a step-by-step rollout plan that minimizes disruption, gains buy-in, and enforces the standard reliably. Include short-term and long-term actions, tooling choices (pre-commit, CI), and how to handle legacy code.

MediumTechnical

89 practiced

You have a legacy codebase where a single large monolithic function is used by dozens of components and changing it often introduces regressions. Propose an incremental refactor plan: describe how you'd add tests, create safe extraction seams, introduce abstractions, rollout changes, and ensure backward compatibility. Include how you'd measure progress and decide when to stop refactoring.

Sample Answer

**Situation & Goals**Incrementally replace a brittle monolithic function used across frontend and backend with minimal risk, improved testability, and no user-visible regressions.

**1. Add tests (safety net)**- Start with characterization tests: capture current behavior across inputs/outputs (unit tests and API/integration tests).- Add end-to-end tests for critical user flows that depend on the function (UI routes, API endpoints).- Use test doubles where side effects exist (DB, external APIs).

**2. Create safe extraction seams**- Wrap the monolith behind a stable interface (adapter) on both client and server: a thin facade that forwards to the legacy implementation.- Introduce feature flags or dependency injection so callers can be switched to new code per-call/tenant.

**3. Introduce abstractions**- Identify orthogonal responsibilities inside the function and extract them into small pure functions or services (validation, transformation, persistence).- Keep interfaces small and well-typed (TypeScript interfaces or backend DTOs).

**4. Rollout plan**- Extract one responsibility at a time, replace adapter internals with new implementation while tests ensure parity.- Use canary releases / feature flags to route a small % of traffic to new path, monitor errors and metrics, then increase rollout.

**5. Ensure backward compatibility**- Maintain adapter contract; keep legacy path available to quickly rollback.- Log and compare outputs between old and new implementations for a probation period.

**6. Measure progress**- Track: - Number of lines/methods extracted - % of callers migrated - Test coverage for extracted units - Production error rates and user-facing metrics- Define success gates for each extraction (passing tests, <X% error delta, observability validated).

**7. When to stop**- Stop when remaining code is trivial/low-risk, extraction cost > risk benefit, or when business priorities shift.- Ensure final removal only after no callers use legacy adapter and monitoring shows stability.

Why this works: small, reversible steps, automated validation, and observability minimize regression risk while improving code quality and maintainability.

MediumTechnical

91 practiced

How would you choose and set thresholds for code metrics in your team (for example: cyclomatic complexity limits, maximum function length, minimum test coverage)? Propose reasonable default values, explain when to allow exceptions, and describe how to prevent teams from gaming these metrics.

EasyTechnical

87 practiced

The function below is intentionally poorly named and mixes responsibilities:

function d(u,p){
  // check auth, fetch data, format response, send
  if(!validate(u)) return {error:true}
  const r = DB.find(p)
  return format(r)
}

Rename the function and variables to reveal intent, describe the responsibility of each extracted helper, propose module/file names for placement, and list linter rules you'd use to enforce consistent naming in the repository.

Sample Answer

**Renamed function & variables**

javascript

// controller handling an authenticated "get profile" request
async function getUserProfile(request, params) {
  if (!isAuthenticated(request.user)) return { error: true }
  const profile = await userRepository.findById(params.userId)
  return profileFormatter.toPublic(profile)
}

**Extracted helpers & responsibilities**- isAuthenticated(user) — verify JWT/session, return boolean. (auth layer)- userRepository.findById(id) — single responsibility: DB access, returns raw model. (data access layer)- profileFormatter.toPublic(profile) — map/remove sensitive fields, shape API response. (presentation layer / serializer)

**Suggested module/file layout**- services/auth.js -> isAuthenticated- repositories/userRepository.js -> DB queries- serializers/profileFormatter.js -> formatting- controllers/userController.js -> getUserProfile orchestration

**Linter rules to enforce naming**- eslint: "camelcase": ["error","properties": "never"] (consistent identifiers)- "id-length": ["warn", {"min":2}] (avoid single-letter names)- "no-underscore-dangle": "error" (prevent private-ish names)- "max-len": ["warn", 100] (readability)- "consistent-function-scoping"/naming conventions via eslint-plugin-filenames (e.g., kebab-case filenames)

These conventions separate concerns, make intent explicit, and improve testability and reuse.

MediumTechnical

93 practiced

Write a small React component `UserProfile` (either JS or TypeScript) that displays user name and status and fetches data from an API. Then refactor the logic so data fetching and state management live in a custom hook `useUser(userId)`, while `UserProfile` remains a presentational component. Provide short code snippets and explain why this improves testability and clean code.

Sample Answer

**Approach**- Start with a simple component that fetches data and manages state.- Refactor fetching/state into a custom hook `useUser(userId)` so `UserProfile` becomes purely presentational.- Advantages: separation of concerns, easier unit testing of hook and UI separately, reuse.

Initial (combined) version (TypeScript):

tsx

import React, { useEffect, useState } from "react";

type User = { id: string; name: string; status: string };

function UserProfile({ userId }: { userId: string }) {
  const [user, setUser] = useState<User | null>(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    let cancelled = false;
    setLoading(true);
    fetch(`/api/users/${userId}`)
      .then(res => {
        if (!res.ok) throw new Error("Fetch failed");
        return res.json();
      })
      .then((data: User) => !cancelled && setUser(data))
      .catch(err => !cancelled && setError(err.message))
      .finally(() => !cancelled && setLoading(false));
    return () => { cancelled = true; };
  }, [userId]);

  if (loading) return <div>Loading...</div>;
  if (error) return <div>Error: {error}</div>;
  if (!user) return <div>No user</div>;
  return (
    <div>
      <h2>{user.name}</h2>
      <p>{user.status}</p>
    </div>
  );
}

Refactored: custom hook + presentational component

tsx

import React from "react";

type User = { id: string; name: string; status: string };

export function useUser(userId: string) {
  const [user, setUser] = React.useState<User | null>(null);
  const [loading, setLoading] = React.useState(true);
  const [error, setError] = React.useState<string | null>(null);

  React.useEffect(() => {
    let cancelled = false;
    setLoading(true);
    fetch(`/api/users/${userId}`)
      .then(res => { if (!res.ok) throw new Error("Fetch failed"); return res.json(); })
      .then((data: User) => !cancelled && setUser(data))
      .catch(err => !cancelled && setError(err.message))
      .finally(() => !cancelled && setLoading(false));
    return () => { cancelled = true; };
  }, [userId]);

  return { user, loading, error };
}

export function UserProfile({ userId }: { userId: string }) {
  const { user, loading, error } = useUser(userId);

  if (loading) return <div>Loading...</div>;
  if (error) return <div>Error: {error}</div>;
  if (!user) return <div>No user</div>;
  return (
    <section>
      <h2 data-testid="name">{user.name}</h2>
      <p data-testid="status">{user.status}</p>
    </section>
  );
}

Why this is better- Testability: I can unit-test useUser by mocking fetch (or using msw) to assert state transitions, and separately snapshot/test UserProfile by supplying mocked props or by mocking the hook return. No need to mount network logic in UI tests.- Separation of concerns: Hook handles side effects and state; component focuses on rendering. This improves readability, reuse (other components can call useUser), and maintainability.- Predictability: Hook returns explicit loading/error/user states making error handling consistent across consumers.

Edge cases & best practices- Abort fetch with AbortController for modern cancellation.- Retry/backoff or caching (SWR/React Query) for production.- Add PropTypes/strict TypeScript types and tests for loading, success, and error states.

Unlock Full Question Bank

Get access to hundreds of Clean Code and Best Practices interview questions and detailed answers.

Join thousands of developers preparing for their dream job.