Code Quality and Defensive Programming Questions

Covers writing clean, maintainable, and readable code together with proactive techniques to prevent failures and handle unexpected inputs. Topics include naming and structure, modular design, consistent style, comments and documentation, and making code testable and observable. Defensive practices include explicit input validation, boundary checks, null and error handling, assertions, graceful degradation, resource management, and clear error reporting. Candidates should demonstrate thinking through edge cases such as empty inputs, single element cases, duplicates, very large inputs, integer overflow and underflow, null pointers, timeouts, race conditions, buffer overflows in system or embedded contexts, and other hardware specific failures. Also evaluate use of static analysis, linters, unit tests, fuzzing, property based tests, code reviews, logging and monitoring to detect and prevent defects, and tradeoffs between robustness and performance.

HardTechnical

30 practiced

Explain common causes of buffer overflows in systems and embedded programming. For a C network parser, propose a defensive design that prevents buffer overflows at compile-time and runtime (bounded copies, sentinel checks, safe APIs, static analysis), and include a short safe-read example showing length checks before allocation.

Sample Answer

Common causes- Unbounded copies (strcpy, sprintf) writing past destination.- Missing/incorrect length checks on network input or headers.- Integer overflow when computing allocation size.- Off-by-one errors and missing space for NUL terminator.- Heap/stack corruption from use-after-free or double-free enabling overwrites.- Implicit trust of protocol fields (length fields forged by attacker).

Defensive design (compile-time + runtime)- Use safe APIs: strlcpy/strlcat, snprintf, memcpy with explicit lengths, getline/readn wrappers.- Bounded copies: always pass destination capacity and enforce NUL termination.- Sentinel checks: validate protocol length fields against maximums and remaining buffer before use.- Integer-safety: use size_t, check for overflow before malloc: if (len > SIZE_MAX / count) error.- Static analysis and compiler hardening: enable -Wall -Wextra -Woverflow, -fsanitize=address, UBSAN, and run tools (clang-tidy, Coverity, cppcheck).- Memory layout and ASLR/DEP: compile with -fstack-protector-strong, -D_FORTIFY_SOURCE=2, PIE.- Defensive parsing: two-phase parsing — validate headers/lengths before allocation or copying. Prefer parsing into fixed-size structs then dynamic allocation when safe.- Fail-safe defaults: on any malformed input, drop connection rather than attempting risky recovery.

Short safe-read example (validate length before allocation)

#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>
#include <unistd.h>
#include <errno.h>

ssize_t read_n(int fd, void *buf, size_t n) {
    size_t left = n;
    char *p = buf;
    while (left) {
        ssize_t r = read(fd, p, left);
        if (r <= 0) return r; // 0 => EOF, -1 => error
        left -= r; p += r;
    }
    return n;
}

int handle_connection(int fd) {
    uint32_t net_len;
    // Read 4-byte length prefix
    if (read_n(fd, &net_len, sizeof(net_len)) != sizeof(net_len)) return -1;
    uint32_t len = ntohl(net_len);

    const uint32_t MAX_PAYLOAD = 16*1024; // application limit
    if (len == 0 || len > MAX_PAYLOAD) return -1; // sentinel check

    // prevent integer overflow and allocate
    if (len > SIZE_MAX - 1) return -1;
    char *buf = malloc(len + 1);
    if (!buf) return -1;

    if (read_n(fd, buf, len) != (ssize_t)len) { free(buf); return -1; }
    buf[len] = '\0'; // NUL-terminate safely

    // process buf safely, using bounded APIs
    // e.g., snprintf(dst, dst_sz, "%s", buf);

    free(buf);
    return 0;
}

Key points: validate all lengths before allocation, bound payloads with sensible maxima, check for integer overflow, use safe copy/format functions, enable compile-time and runtime sanitizers, and use static analysis as part of CI.

HardSystem Design

41 practiced

Design a resilient client library for a critical internal HTTP API that must degrade gracefully under network failures and rate limits. Requirements: retries with jitter, circuit breaker, per-call timeouts, backpressure, optional local caching with TTL, and good observability. Describe the public API, default policies, metrics to expose, testing strategies, and trade-offs.

Sample Answer

Requirements clarified:- Sync + async HTTP calls to internal critical API- Must support retries with jitter, circuit breaker, per-call timeouts, backpressure, optional local TTL cache, and strong observability- Library should be language-idiomatic (example API below in pseud-Java/TypeScript style)

Public API (concise):- Client client = Client.builder(baseUrl) .withTimeout(Duration.ofMillis(500)) .withRetryPolicy(RetryPolicy.default()) .withCircuitBreaker(CircuitBreaker.default()) .withBackpressure(Backpressure.boundedQueue(100)) .withCache(CacheConfig.enabled(90s)) .build();- Response<T> resp = client.call(Request.get("/orders/123"), Response.class);- CompletableFuture<Response<T>> callAsync(...)- client.invalidateCache(key), client.metrics(), client.shutdown()

Default policies (sensible safe defaults):- Per-call timeout: 500ms- Retries: up to 3 attempts with exponential backoff base 100ms and full jitter (sleep = random(0, base * 2^attempt))- Circuit breaker: sliding window 60s, minRequests=20, failureThreshold=50%, openDuration=30s, halfOpenProbe=5- Backpressure: bounded queue 100; when full apply configurable policy: block with timeout (default 100ms) or immediate reject with 429-like exception- Cache: disabled by default; when enabled TTL=90s, size-limited with LRU eviction

Observability / Metrics to expose:- Counters: total_calls, succeeded, failed_by_status_{5xx,4xx}, timed_out, retries_attempted, cache_hits, cache_misses- Gauges: active_requests, queue_length, circuit_state (0=closed,1=open,2=half)- Histograms: latency_ms (per-route), retry_delay_ms- Traces: span per call with tags: route, attempt, cb_state, cache_used- Expose via Prometheus client, OpenTelemetry traces and events for state transitions (circuit open/close, backpressure rejections)

Testing strategies:- Unit: deterministic tests for retry/backoff, mock clock for timing and jitter by controlling RNG seed; inject mock HTTP server- Integration: local test server that simulates latencies, intermittent 5xx, 429 rate-limits- Chaos tests: fault injection in staging to simulate network partitions, packet loss, and high latency; verify graceful degradation and recovery- Load tests: hammer service to trigger circuit breaker and backpressure; assert no resource leaks and bounded memory- Property tests: invariants like "no unbounded concurrency" and "requests either return, error, or be rejected within timeout"

Key design choices & trade-offs:- Client-side retries risk duplicate side-effects; require idempotency keys or only retry safe methods (GET, idempotent POST with idempotency token).- Aggressive retries vs. cascading failure: favor conservative defaults and full jitter to avoid synchronized retries.- Circuit breaker configuration tuned for service SLAs; too-sensitive CB leads to false opens, too-lenient delays recovery.- Backpressure at client prevents local resource exhaustion but can raise latency or rejection rates; policy must be coordinated with callers (blocking vs. fail-fast).- Optional cache improves availability but can serve stale data—clear guidelines for cache TTL per endpoint required.- Observability cost: detailed metrics and traces increase overhead; sample traces or adaptive metric levels can reduce impact in high-throughput scenarios.

Why this works:- Combines proven resilience patterns (retry+jitter, CB, timeouts, backpressure) with observability and test coverage to enable safe defaults while letting teams tune per-endpoint policies.

MediumTechnical

25 practiced

Implement a robust function in Python named `safe_divide(a, b)` that returns a float result and defensively handles division by zero, non-numeric inputs, and float infinities. Provide unit tests covering normal, zero, non-numeric and extreme-value cases and explain your error-handling choices.

Sample Answer

Approach: validate inputs, convert to float safely, guard against ±inf and division-by-zero, and raise clear, typed exceptions. Return a float result for valid inputs.

python

import math

def safe_divide(a, b):
    """
    Safely divide a by b and return float.
    Raises:
      TypeError: if inputs are not numeric (cannot convert to float)
      ValueError: if inputs are infinite or result is undefined (0/0)
      ZeroDivisionError: if denominator is zero (after validation)
    """
    try:
        fa = float(a)
        fb = float(b)
    except (TypeError, ValueError) as e:
        raise TypeError(f"Non-numeric input: {e}")

    if math.isinf(fa) or math.isinf(fb):
        raise ValueError("Inputs must be finite numbers")

    # explicit 0/0 check: undefined
    if fa == 0.0 and fb == 0.0:
        raise ValueError("0/0 is undefined")

    if fb == 0.0:
        raise ZeroDivisionError("Division by zero")

    return fa / fb

Unit tests (pytest):

python

import pytest
import math

def test_normal():
    assert safe_divide(6, 3) == 2.0
    assert safe_divide(1.5, 0.5) == 3.0

def test_zero_numerator():
    assert safe_divide(0, 5) == 0.0

def test_div_by_zero():
    with pytest.raises(ZeroDivisionError):
        safe_divide(5, 0)

def test_zero_over_zero():
    with pytest.raises(ValueError):
        safe_divide(0, 0)

def test_non_numeric():
    with pytest.raises(TypeError):
        safe_divide("a", 2)

def test_infinite_inputs():
    with pytest.raises(ValueError):
        safe_divide(math.inf, 1)
    with pytest.raises(ValueError):
        safe_divide(1, -math.inf)

Error-handling choices:- Convert to float to accept numeric strings but reject truly non-convertible types.- Reject infinities early to avoid returning inf/NaN to callers.- Distinguish 0/0 (undefined) from x/0 (raise ZeroDivisionError) for clearer semantics.Complexity: O(1) time and O(1) space.

EasyTechnical

21 practiced

Explain patterns for handling missing or null values in strongly-typed (Java) and dynamically-typed (Python/JS) languages. Include examples of Option/Maybe types, exceptions, sentinel values, and when to use assertions compared to throwing recoverable errors.

Sample Answer

Strongly-typed and dynamically-typed languages require different idioms to make absence explicit, avoid NPEs, and communicate intent. Common patterns: Option/Maybe, exceptions, sentinel values, and assertions vs recoverable errors.

Option/Maybe (preferred when absence is expected)- Java (java.util.Optional):

java

Optional<User> findUser(String id) { return Optional.ofNullable(repo.get(id)); }

Optional<User> u = findUser(id);
u.ifPresent(user -> sendEmail(user));
User orElse = u.orElseThrow(() -> new NotFoundException("user"));

- Python (use typing.Optional + explicit checks or libraries like returns):

python

from typing import Optional
def find_user(id) -> Optional[User]:
    return repo.get(id)  # may be None

user = find_user(id)
if user is None:
    handle_missing()
else:
    send_email(user)

- JS/TS: use union types or libraries like fp-ts Maybe.

Exceptions (use for truly exceptional, unrecoverable or flow-breaking conditions)- Throw when caller cannot reasonably continue (I/O failure, corrupt data).- Avoid using exceptions for normal control flow (not-found) unless API convention expects it.

Sentinel values (use sparingly)- Return empty list, empty string, or a special enum value when that meaning is clear and documented.- Risk: conflates "no value" vs valid value; prefer Option when possible.

Assertions vs Recoverable errors- Assertions: internal invariants — use assert to catch programmer mistakes during development (e.g., private helper assumptions). Not for user input.- Recoverable errors: validate inputs and throw checked/recoverable exceptions or return Option/Result so caller can handle.

Practical rules- Prefer Option/Optional/Maybe to make absence explicit.- Use exceptions for unexpected failures; keep error messages actionable.- Use sentinel values only when domain semantics make them unambiguous.- Use assertions for developer-only invariants, not for runtime input validation.

This approach improves readability, makes error handling explicit, and reduces runtime surprises.

EasyTechnical

27 practiced

What constitutes a good unit test? Describe Arrange-Act-Assert structure, naming, isolation, determinism, and how to pick edge-case tests. Provide a six-item checklist you review when adding unit tests to a pull request.

Unlock Full Question Bank

Get access to hundreds of Code Quality and Defensive Programming interview questions and detailed answers.

Join thousands of developers preparing for their dream job.