Performance and Code Optimization Questions

Covers techniques and decision making for improving application and code performance across levels from algorithm and memory access patterns to frontend bundling and runtime behavior. Candidates should be able to profile and identify bottlenecks, apply low level optimizations such as loop unrolling, function inlining, cache friendly access patterns, reducing branching, and smart memory layouts, and use compiler optimizations effectively. It also includes higher level application and frontend optimizations such as code splitting and lazy loading, tree shaking and dead code elimination, minification and compression, dynamic imports, service worker based caching, prefetching strategies, server side rendering versus client side rendering trade offs, static site generation considerations, and bundler optimization with tools like webpack Vite and Rollup. Emphasize measurement first and avoiding premature optimization, and explain the trade offs between performance gains and added complexity or maintenance burden. At senior levels expect ability to make intentional trade off decisions and justify which optimizations are worth their complexity for a given system and workload.

HardTechnical

17 practiced

You inherit a codebase with many low-priority performance issues scattered across services. Describe how you would triage, prioritize, and allocate engineering effort across immediate hot paths, architectural changes, and long-term improvements. Include measurable signals, ROI estimation, and stakeholder communication strategies.

Sample Answer

Situation: I joined a team owning several microservices with many low-priority performance problems—sporadic latency spikes, high p99s on some endpoints, and inefficient batch jobs. Business impact was unclear and teams were frustrated by firefighting.

Approach (triage & prioritization):1. Measure first — establish signals:- Customer-facing: p50/p95/p99 latency, error rate, throughput, SLAs breached, number of user complaints/tickets.- Backend: CPU/memory, GC pauses, DB query times, queue lengths, async backlog.- Cost: infra spend by service, egress, and wasted retries.2. Quick triage pass (1–2 weeks):- Classify issues into Hot Path (affects p99 or SLA), Recurring (frequent incidents or alerts), Cost Drivers, and Nice-to-have.- Use Pareto: identify the 20% of services/endpoints causing 80% of observed latency/errors.3. Prioritize by ROI:- Estimate ROI = (User impact score × frequency × severity) / engineering effort.- Quantify user impact: % of requests affected × business value per request (e.g., conversion rate, revenue, SLAs).- Estimate effort: days for quick fixes vs. weeks/months for architectural work.4. Allocate effort:- Immediate (0–2 weeks): dedicate 30–40% of sprint capacity to hot-path fixes (circuit-breaking, caching, index fixes, query tuning, connection pooling). These yield high ROI and measurable p99 improvements.- Mid-term (1–3 months): allocate 30% to recurring issues and infra/config improvements (autoscaling, better observability, retry/backoff logic).- Long-term (3–9 months): 30–40% for architectural changes (service decomposition, async pipelines, rewrite of hot modules). Break into incremental milestones with measurable checkpoints.

Execution & measurables:- For each ticket define target metric (e.g., reduce p99 from 1200ms → 300ms) and acceptance criteria.- Use A/B or canary deployments to validate improvements and avoid regressions.- Track ROI weekly: time-to-fix, metric delta, incident count reduced, and cost savings.

Stakeholder communication:- Create a concise dashboard and roadmap: top 5 pain points, planned fixes, expected impact, ETA, and owners.- Weekly status with PMs/ops: highlight wins (before/after metrics), trade-offs, and any risks requiring scope changes.- For long-term work, propose gated milestones and cost-benefit summaries to get buy-in; offer short-term mitigations during migration.- Keep documentation and playbooks updated so on-call can handle interim states.

Result/learning: This structured, metric-driven approach quickly resolves noticeable pain (measurable p99 drops and fewer incidents), defers low-ROI rewrites, and ensures architectural work is funded with clear business justification.

EasyTechnical

23 practiced

Explain the principle 'measure first' and the phrase 'avoid premature optimization' in the context of a backend codebase. Provide a concise checklist of steps engineers should take to decide whether to optimize an area of code, including how to estimate cost versus benefit.

MediumTechnical

22 practiced

A multi-threaded Java service shows heavy contention on a single synchronized block. Propose refactorings and alternative concurrency primitives to reduce contention, including sharding, concurrent collections, ReadWriteLock, and lock-free options. Discuss trade-offs in complexity and correctness.

Sample Answer

Start by measuring: identify the hot synchronized block with profilers (async-profiler, YourKit) and verify contention vs. CPU or I/O.

Refactor options (with trade-offs):

1) Sharding (partition the state)- Idea: split single lock into N independent locks/buckets keyed by hash to spread contention.- When to use: operations are per-key or independent.- Trade-offs: simpler, low risk; increases complexity for cross-shard operations (requires two-phase commit or global coordination).- Example:

java

// simple striped locks
private final Object[] locks = IntStream.range(0, 16).mapToObj(i->new Object()).toArray(Object[]::new);
void update(K key, V value){
  Object lock = locks[Math.abs(key.hashCode()) % locks.length];
  synchronized(lock){ /* mutate single shard */ }
}

2) Concurrent collections- Use ConcurrentHashMap, ConcurrentLinkedQueue, CopyOnWriteArrayList where appropriate.- Good for read-heavy maps/queues; ConcurrentHashMap uses internal striping and lock-free reads.- Trade-offs: semantics differ (e.g., computeIfAbsent has caveats), iteration weakly consistent.

3) ReadWriteLock / StampedLock- Use ReadWriteLock when reads dominate and can safely run concurrently.- StampedLock (optimistic read) can reduce overhead further.- Trade-offs: more complex (downgrade/upgrade, risk of writer starvation), StampedLock is non-reentrant so careful design needed.

4) Lock-free / atomic primitives- Use AtomicReference/LongAdder/AtomicInteger, VarHandles, or non-blocking algorithms for counters/accumulators.- LongAdder is superior for highly contended counters (reduced contention via cells).- Trade-offs: correctness complexity increases (ABA problem, memory visibility), harder to compose multiple atomic updates (no multi-variable atomicity).

Correctness & complexity considerations:- Maintain invariants across shards — use consistent hashing or global snapshot when needed.- Beware of deadlocks when acquiring multiple locks -> enforce ordering.- Prefer well-tested concurrent collections and primitives before rolling custom lock-free algorithms.- Add comprehensive tests (concurrency tests, stress tests, and fences) and monitor post-change.

Recommendation path:1. Replace coarse synchronized with ConcurrentHashMap/LongAdder where semantics match.2. If still contended, apply sharding (start with small N) and measure.3. If read-heavy, introduce ReadWriteLock or StampedLock with optimistic reads.4. Only consider custom lock-free algorithms if profiling and correctness requirements justify complexity.

HardTechnical

22 practiced

A large monorepo with frontend and backend teams has slow CI builds and slow developer feedback loops. Propose tooling and architectural changes such as remote caching, build system choice (e.g., Bazel), dependency graphs, and incremental builds to speed up developer iteration. Discuss trade-offs and migration plan.

Sample Answer

Requirements & constraints:- Fast local feedback (<30s for common edit-test cycle), scalable CI parallelism, reproducible hermetic builds, support JS/TS, Java, Python, Docker images, incremental/test-only runs, low maintenance overhead.

Proposal (high level):1. Adopt a hermetic, DAG-based build system (Bazel or Pants). Bazel recommended for large polyglot monorepos because of mature remote caching and wide language support.2. Enable remote build & action cache (GCS/S3 + cache service) to share artifacts between CI and dev machines.3. Enforce explicit dependency graph via BUILD files (or BUILD-like targets) so the system can compute incremental impact and run only affected targets.4. Invest in fast local developer tooling: “bazel test //...:fast” aliases, sandboxed local caching, and an incremental dev server for frontend hot-reload that integrates with build outputs.5. CI changes: replace full-tree builds with targeted pipelines that run changed-target detection, use remote cache to avoid redundant work, and run full verification only on release branches.6. Observability: record cache hit/miss, build/blocking time, and test selection metrics.

Key benefits:- Incremental builds become near-instant for small changes; CI wall time drops due to cache re-use; reproducibility increases.

Trade-offs:- Upfront cost: authors must add BUILD targets and possibly refactor modules.- Learning curve for Bazel; potential tool-specific quirks (3rd-party deps, JS ecosystem plumbing).- Some non-hermetic steps (native image builds, heavy Docker layering) may need wrappers.

Migration plan (phased):Phase 0 — Prep (2–4 weeks)- Form small working group, pick pilot team, baseline metrics (current CI time, dev iteration time).Phase 1 — Pilot (4–8 weeks)- Convert 1 backend and 1 frontend service to Bazel, enable local cache, set CI to read/write remote cache. Track performance.Phase 2 — Expand (2–3 months)- Add language/tooling rules, authorship training, CI integration for more services, introduce pre-submit incremental checks.Phase 3 — Rollout + Hardening (1–2 months)- Enforce BUILD files for new modules via repo policy, migrate remaining teams, tune cache TTLs, add monitoring dashboards.Phase 4 — Optimization- Add remote execution if CPU-bound CI is limiting, refine test selection policies (affected tests only), introduce developer-friendly wrappers and VSCode plugins.

Operational considerations:- Ensure secure access to remote cache (auth & encryption).- Keep a "fast path" for frontend local dev (hot reload using webpack/Vite) to avoid developer friction.- Provide training, runbooks, and migration incentives (e.g., merge windows for converted teams).

Success metrics:- Median local edit → green test time (target <30s for unit-level).- CI reduced median build time by 50% and cache hit rate >70%.- Developer satisfaction score improvement.

Alternatives:- Pants for simpler Python/Java/JS stacks; Nx for JS-heavy repos. Use if language mix or team familiarity suggests lower friction.

This approach balances technical payoff (remote caching + DAG incrementalism) against human and migration costs, delivering much faster iteration while preserving correctness and reproducibility.

EasyTechnical

23 practiced

Implement a thread-safe memoization decorator in Python that caches function results based on positional and keyword arguments. The decorator should accept a configurable max_size and use LRU eviction when capacity is reached. Provide code with type hints and explain thread-safety choices.

Sample Answer

To implement a thread-safe LRU memoization decorator, use an OrderedDict to maintain LRU order and a threading.Lock to serialize access to the cache. The decorator factory accepts max_size. Keys are constructed from args plus a sorted tuple of kwargs items to ensure determinism and hashability.

python

from collections import OrderedDict
from functools import wraps
from threading import Lock
from typing import Any, Callable, Dict, Tuple

def thread_safe_lru(max_size: int = 128):
    if max_size <= 0:
        raise ValueError("max_size must be > 0")

    def decorator(func: Callable):
        cache: "OrderedDict[Tuple[Any, ...], Any]" = OrderedDict()
        lock = Lock()

        @wraps(func)
        def wrapper(*args: Any, **kwargs: Any) -> Any:
            # Build a hashable key from args and kwargs (kwargs sorted to be deterministic)
            key = (args, tuple(sorted(kwargs.items())))

            with lock:
                if key in cache:
                    # Move to end to mark as recently used
                    cache.move_to_end(key)
                    return cache[key]

            # Compute without holding lock (so other threads can access concurrently)
            result = func(*args, **kwargs)

            with lock:
                cache[key] = result
                cache.move_to_end(key)
                # Evict least-recently-used if over capacity
                while len(cache) > max_size:
                    cache.popitem(last=False)
            return result

        # Optional: expose cache for inspection in tests
        wrapper._cache = cache  # type: ignore[attr-defined]
        return wrapper
    return decorator

Key points:- Thread-safety: a Lock protects reads/writes to the OrderedDict. The function call itself runs outside the lock to avoid blocking long computations (double compute possible if concurrent calls with same key race; acceptable or can be avoided with per-key locks).- Complexity: average O(1) for cache get/set/move operations; eviction O(1).- Edge cases: args/kwargs must be hashable; if not, convert to a stable representation or raise. To avoid duplicate work under contention, consider a per-key in-progress map or Futures.

Unlock Full Question Bank

Get access to hundreds of Performance and Code Optimization interview questions and detailed answers.

Join thousands of developers preparing for their dream job.