Hudson River Trading Software Engineer Interview Prep Guide

Technical Screen

Coding & Algorithms

What's being tested

These problems test stateful simulation and precise event ordering: you must model system state over time and produce correct outcomes as events (arrivals, completions, turns) interleave. Interviewers probe ability to convert rules into deterministic update steps, choose the right event structure, and reason about tie-breaking and time advancement.

Patterns & templates

• Event loop simulation — collect events, advance a simulation clock, process next event; common implementation: priority queue via heapq, O(m log m) for m events.

• Greedy single-server queue — track server availability time t_free; for each arrival, start = max(arrival, t_free); update t_free = start + duration.

• Sort-by-time then stable-tie-break — sort(events, key=(time, tie_key)) ensures deterministic handling of simultaneous events.

• Turn-based alternation — maintain an index or boolean flag to toggle collector/player; perform O(1) updates per turn until list exhausted.

• In-place state updates — mutate accumulators (e.g., queue length, collected count) rather than rebuilding structures; saves memory to O(1) beyond input.

• Use integers/64-bit for time — sum of durations can overflow 32-bit; prefer long/int64.

• Batch-processing vs per-event — when arrivals sorted, process contiguous arrivals before advancing completion to reduce heap operations, improving from O(m log m) to near O(m) in practice.

Common pitfalls

Pitfall: Treating simultaneous arrival and completion in arbitrary order — always define and implement a consistent tie-break (e.g., completions before arrivals or vice versa) and state it to the interviewer.

Pitfall: Forgetting server idle time — using only durations without max(arrival, t_free) yields negative waits and wrong completion times.

Pitfall: Using 32-bit integers for accumulated time — large sums cause overflow; use 64-bit types.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions

What's being tested

These problems test hash-based counting and canonicalization: converting items to a normalized key and aggregating counts efficiently to answer pair/prefix queries. Interviewers probe correctness (edge cases), time/space complexity, and careful key design to avoid collisions or double-counting.

Patterns & templates

• Frequency map using a hashmap — count canonical keys in O(n) time and O(u) extra space, where u is unique canonical forms.

• Canonical key by transform — apply a deterministic transform (sorted digits, reversal-normalized string, trimmed prefix) before hashing to group equivalents.

• Use combination formula for pairs: for count k, number of unordered pairs is k*(k-1)/2 — avoid nested loops.

• Represent numeric canonical keys as strings when leading zeros matter; otherwise use integer tuples for compactness and faster hashing.

• Streaming accumulation: update counts on the fly, emit pairs incrementally with current count to save memory when needed.

• For prefix problems, build a prefix-hash map or use a trie when many shared prefixes reduce key space; O(L*n) where L is average length.

Common pitfalls

Pitfall: Forgetting leading zeros — treating reversed digits as integers collapses distinct forms like "010" and "10".

Pitfall: Miscounting pairs by summing k instead of using k*(k-1)/2, producing linear instead of combinatorial results.

Pitfall: Creating heavy keys (e.g., full sorted strings) for very long items when a fixed-length hash or tuple would suffice, increasing memory and hash time.

Practice these

the practice cards below cover the canonical variants — solve all of them and time yourself

Practice questions

Software Engineering Fundamentals

What's being tested

Candidates must demonstrate designing mutable data-structure APIs that preserve clear invariants while meeting time/space guarantees (often amortized O(1)). Interviewers probe choices for backing representations, how mutation affects indices/state, correctness under concurrent-seeming operations (random sampling, buffered reads), and clear, testable API contracts.

Patterns & templates

• Array + hash map for constant-time membership and removal: store items in an array, map value→index, remove by swapping with last — O(1) amortized.

• Prefix-sum array or alias method for weighted sampling: prefix-sum + binary search O(log n) or alias O(1) for repeated samples; updates cost O(n) vs O(1) with Fenwick tree.

• Circular buffer (ring buffer) for deque semantics with pop_front/push_back in O(1), extend with doubling for amortized O(1) growth.

• Block-deque / unrolled linked list to get O(1) indexable access with segmented arrays, avoiding full-copy shifts.

• Fenwick (BIT) / segment tree to support dynamic weight updates + prefix queries in O(log n) for weighted sampling with updates.

• Internal buffer + cursor for stream-wrapping: persist leftover bytes between calls, return exact requested lengths until EOF; handle mid-call state cleanly.

• Explicit invariants docstring: state what indices mean after each op, exception behavior, and complexity guarantees.

• Test harness templates: randomized ops + oracle (naïve model) to validate correctness under many interleavings.

Common pitfalls

Pitfall: Assuming swapping removal preserves order — it breaks positional semantics; document whether your API preserves order or not.

Pitfall: Using prefix-sum array for weighted sampling without supporting efficient updates — forgets that updates can be O(n) and will timeout at scale.

Pitfall: For stream wrappers, not persisting leftover buffer across calls leads to lost bytes at EOF or incorrect lengths.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions

What's being tested

You must design a dynamic data structure that supports insert, delete, and getRandom where getRandom returns items proportional to their weight. Interviewers probe your knowledge of hybrid array+map layouts, prefix-sum indexing, update/search complexity tradeoffs, and numeric robustness under updates.

Patterns & templates

• hashmap+array hybrid — store items in an array for indexable operations and a hashmap for index lookup; swap-with-last for O(1) delete.
• prefix-sum array with binary search — maintain cumulative weights; sample by generating r in [0,total) and binary-search O(log n) per sample.
• Fenwick tree (Binary Indexed Tree) — supports point updates and prefix-sum queries in O(log n); use for frequent weight changes.
• Alias method — preprocess in O(n) to enable O(1) sampling; good when samples >> updates but costly for frequent inserts/deletes.
• For mostly-read, infrequent-write workloads: rebuild prefix/alias lazily (batch updates) to amortize costs.
• Track total weight explicitly; for sampling use uniform rand() scaled to total to avoid bias.
• Use int64 or double carefully; avoid cumulative rounding by using integer weights when possible, or renormalize periodically.
• Complexity shorthand: insert/delete amortized O(1) with array+map, sampling O(log n) with Fenwick/prefix, O(1) with alias after rebuild.

Common pitfalls

Pitfall: Treating floating cumulative sums as exact — leads to off-by-one or bias; prefer integer weights or careful eps handling.

Pitfall: Forgetting to update both array and tree/map on swap-delete — leaves stale indices and corrupts sampling.

Pitfall: Choosing alias method without asking update frequency — great for static weights but expensive for dynamic workloads.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions

What's being tested

These problems check grid traversal with correct neighbor indexing and boundary handling, plus prefix/suffix reasoning to combine left/right or above/below summaries efficiently. Interviewers probe whether you convert a local condition into a global O(m*n) or O(n) plan and handle edge cases cleanly.

Patterns & templates

• Neighbor iteration for grids — iterate dx/dy = {(0,1),(0,-1),(1,0),(-1,0)} and check 0<=r<m, 0<=c<n; overall O(m*n) time.

• Sentinel padding (add one-cell border) to simplify boundary logic and avoid repeated index checks when comparing neighbors.

• Prefix / suffix arrays: precompute prefix_max/prefix_min and suffix_max/suffix_min to evaluate removing any contiguous block in O(1) per candidate.

• Sliding window / two-pointer for contiguous subarray constraints — maintain window invariants and update aggregates in amortized O(1) per move.

• Prefix sums for range sums and constant-time queries: build pref[i] = sum(a[0..i-1]) so range sum is pref[r]-pref[l].

• Deques / monotonic queue for maintaining running min/max over windows in O(n) time when removal affects order.

• Space-time tradeoffs: O(n) auxiliary arrays are acceptable up to millions; beyond memory limits, stream and compress summaries.

Common pitfalls

Pitfall: Off-by-one errors when computing suffix indices — always define whether prefix/suffix is inclusive/exclusive and test on length-1 arrays.

Pitfall: Forgetting to recompute global min/max after removing a block — combine prefix and suffix extremes, don't just use local neighbors.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions

What's being tested

Demonstrates the ability to find a local minimum using algorithmic tradeoffs between local search (greedy/hill-climbing) and divide-and-conquer (binary-search-like) approaches. Interviewers probe correctness proofs (termination, invariants), complexity reasoning, and handling edge cases like boundaries and equal neighbors.

Patterns & templates

• Binary search on 1D arrays — check A[mid] vs A[mid-1]/A[mid+1], recurse left/right; guarantees O(log n) comparisons when strict inequality holds.

• Mid-column divide-and-conquer for 2D — find global minimum in a column (O(n)), compare to adjacent column, recurse to the half with smaller neighbor.

• Recurrence analysis — for an n×n matrix: $T(n)=T(n/2)+O(n)$ ⇒ overall O(n) time using mid-column strategy.

• Greedy local search (hill-climbing) — repeatedly move to a strictly smaller neighbor until none; simple, O(n*m) worst-case on n×m grid.

• Boundary invariants — treat edges as having “missing” neighbors; endpoints can be local minima by definition.

• Plateau handling — break ties deterministically (e.g., prefer left/up), or treat <= carefully to avoid infinite loops.

• Implementation tips — use A[i][j] indexing checks, guard mid computation (mid = lo + (hi-lo)/2) to avoid overflow in large domains.

Common pitfalls

Pitfall: Assuming hill-climbing is always fast — adversarial inputs can force scanning most elements; argue worst-case complexity.

Pitfall: Using <= vs < incorrectly on ties; this can cause nontermination on plateaus or miss valid local minima.

Pitfall: Off-by-one at boundaries — forgetting to check A[0]/A[n-1] (1D) or edge neighbors (2D) breaks correctness proofs.

Practice these

The practice cards below cover the canonical variants — solve all of them and time yourself.

Practice questions

What's being tested

Interviewers expect the candidate to demonstrate precise, systems-aware reasoning about how C++ language choices interact with operating-system virtual memory and runtime behavior. They want you to explain root causes of crashes like segmentation faults, the semantics and trade-offs of inline functions, and the real internals and performance implications of `std::string` (SSO vs heap). Hudson River Trading cares because low-latency, correct code requires knowing when behavior is just a language abstraction and when it maps to costly OS events (page faults, swap, allocator syscalls).

Core knowledge

• Virtual memory (VM): the OS maps virtual pages (commonly 4 KiB) to physical frames; an access to an unmapped page triggers a page fault that the kernel services (a few µs–ms depending on whether disk swap is involved).

• Anonymous mappings vs heap: large allocations often use `mmap` (anonymous) while small ones use `brk`/`sbrk` via the allocator; glibc malloc usually switches to `mmap` above a threshold (~128 KiB, implementation-dependent).

• Lazy allocation / overcommit: Linux commonly performs lazy commit — `malloc`/`mmap` can succeed without physical memory until pages are touched; touching can then cause page faults and possibly invoke the OOM killer if memory is exhausted.

• Swap cost: reading/writing swapped pages is orders of magnitude slower than DRAM; expect I/O latencies (ms) vs memory access (ns). Heavy swapping destroys latency-sensitive workloads.

• Segmentation fault root causes: null-dereference, use-after-free, stack overflow (deep recursion or large stack allocs), out-of-bounds writes, accessing unmapped region after `munmap`.

• std::string internals: most modern standard libraries implement short string optimization (SSO): small strings stored inline (typ. 15 bytes on 64-bit `libstdc++`), otherwise the string holds a pointer/size/capacity to heap storage; C++11+ guarantees contiguous storage for `std::string`.

• Copy semantics: modern `std::string` is non-copy-on-write; copying performs allocation/copy for heap-backed strings, so `reserve`, `move` and `emplace` matter for performance.

• inline keyword semantics: `inline` affects linkage/ODR (allows identical definitions in multiple TUs) and is only a hint for inlining; compilers decide actual inlining based on optimization heuristics and flags like `-O2`, LTO.

• Performance trade-offs of inlining: inlining eliminates call overhead and enables optimization (constant propagation, dead code elimination) but increases code size, which can raise I-cache pressure and negatively affect p99 latency.

• Allocator fragmentation & rounding: `malloc` rounds up sizes and maintains arenas; many small allocations cause fragmentation and cross-thread contention unless you use tunable allocators (`jemalloc`, `tcmalloc`) or per-thread arenas.

• Touch vs map semantics: use `madvise(MADV_WILLNEED/MADV_DONTNEED)`, `mlock` to influence paging behavior; `MAP_HUGETLB` or transparent hugepages reduce TLB pressure for very large contiguous allocations but have trade-offs.

• Diagnostics: use `pmap`/`smem`/`/proc/<pid>/smaps` for RSS/VM, `valgrind`/`asan` for memory errors, and `perf record/top` or `perf mem` for page-fault hotspots.

Worked example — Explain C++ Inline, Segfaults, Virtual Memory, and std::string Internals

Start by clarifying the scope: ask whether the system is Linux, what compiler and optimization flags (`-O0` vs `-O3`/LTO) are in use, and whether the code is single-threaded or production-critical (latency vs throughput). Organize your answer around three pillars: (1) inline semantics and performance (linkage vs compiler hint, when LTO matters), (2) VM and segfault causes (lazy allocation, page fault cost, typical causes like use-after-free and stack overflow), and (3) std::string internals (SSO size, heap path, allocation/copying implications). For `inline`, explicitly note that claiming “inline always eliminates call overhead” is wrong — show that the compiler's optimizer and inlining heuristics plus code size effects determine real-world benefit. For segfaults, enumerate debugging steps (core dump, `addr2line`, `asan`) and explain how lazy commit can make a large `malloc` appear successful until a later page touch triggers failure. Close by proposing short experiments: run a microbenchmark toggling `inline`, measure binary size and `perf stat` cycles vs mispredictions, and if more time mention checking `std::string` SSO threshold on the target lib by inspecting the type layout or printing `sizeof(std::string)`.

A second angle — Explain Large Memory Allocation, Swap, and C++ Inline Trade-offs

Here the emphasis shifts toward OS-level behavior for huge allocations and how language choices interact with system configuration. Start by describing allocation path (`malloc` → `mmap`), the kernel's lazy commit and `vm.overcommit_memory` modes, and how touching pages produces page faults that may be satisfied from RAM or swap (or trigger the OOM killer). Discuss mitigation: pre-touch pages, use `mlock` for real-time requirements, or use huge pages to reduce TLB misses. For `inline`, stress code-size accumulation across large codebases: aggressive inlining in hot templates can blow up binary size, increasing cache misses and hurting tail latency — so prefer targeted `inline` or profile-guided decisions (PGO/LTO) in latency-sensitive systems.

Common pitfalls

Pitfall: Confusing allocation success with memory availability — claiming `malloc` succeeds means memory is committed. In reality, lazy allocation can defer failures to the first page touch; always consider commit semantics for reliability.

Pitfall: Saying `inline` forces inlining. Interviewers expect you to distinguish linkage/ODR behavior from compiler inlining heuristics and to mention optimizer flags and LTO.

Pitfall: Overfocusing on average-case speed. A subtle bug is ignoring tail-latency amplification from page faults or instruction-cache pressure caused by inlining; always discuss worst-case latency in addition to throughput.

Tip: When debugging segmentation faults, reproduce with `ASAN`/`UBSAN` and examine `/proc/<pid>/maps` and a core to see whether the faulting address is within a freed heap, unmapped, or near the stack.

Connections

Interviewers may pivot to allocator choice and tuning (compare glibc malloc vs `jemalloc`), profiling and tracing tools (`perf`, `eBPF`) to measure actual page fault and I-cache behavior, or to concurrency: how per-thread arenas and false sharing interact with memory allocation and performance.

Further reading

• What Every Programmer Should Know About Memory (Ulrich Drepper) — practical OS/VM behavior and latency implications.

• glibc malloc internals (documentation/blogs) — explains `brk` vs `mmap` thresholds and arena behavior.

• CppReference: std::string — standard guarantees (contiguity, complexity) and useful member-function semantics.

Practice questions

What's being tested

Interviewers probe your ability to build correct, performant, and maintainable concurrent code: safe access to shared state under contention, choice of synchronization primitives, and reasoning about liveness (deadlock/starvation) and memory visibility. At Hudson River Trading, low-latency and high-throughput constraints make tradeoffs between simple correctness (coarse locks) and scalable designs (sharding, lock-free) particularly important. Expect to justify complexity vs. latency, show familiarity with the memory model, and describe measurable mitigations for contention and cache effects.

Core knowledge

• Mutual exclusion (mutex): a blocking primitive that serializes critical sections. Use std::mutex/pthread_mutex_t; cost per lock is low for uncontended cases but grows with context switches and system calls.

• Read-write locks (RWLock): allow concurrent readers, exclusive writers; useful for read-heavy workloads but can starve writers or increase writer latency under high read concurrency.

• Atomic operations and CAS: compare-and-swap (CAS) via std::atomic or __sync_bool_compare_and_swap is the building block for lock-free algorithms; it offers O(1) semantics but may require retry loops under contention.

• Lock-free vs wait-free: lock-free guarantees system progress; wait-free guarantees per-thread progress. Lock-free designs often use CAS loops; wait-free implementations are more complex and rare in production.

• Memory model & happens-before: languages expose ordering (e.g., volatile in Java, memory_order in C++). Correctness depends on establishing happens-before for visibility; otherwise you get data races and undefined behavior.

• Linearizability and correctness criteria: aim for linearizable operations when designing concurrent data structures so each operation appears atomic at some point between invocation and response.

• Liveness hazards: deadlock often stems from inconsistent lock ordering; priority inversion and starvation appear with locks/condition variables and must be mitigated (timeouts, priority inheritance if available).

• Condition variables and spurious wakeups: always use while loops to re-check predicates after wait(); treat wakeups as spurious and re-evaluate state.

• Memory reclamation (ABA problem): lock-free structures need safe reclamation strategies: hazard pointers, epoch-based reclamation, or garbage collection to avoid ABA and use-after-free.

• Contention mitigation patterns: sharding (partition data across locks/cores), per-thread counters with periodic aggregation, exponential backoff in CAS loops, and avoiding false sharing with padding to cache-line boundaries.

Tip: Benchmark with realistic contention patterns (perf, latency p99) and profile cache-misses and lock statistics before over-optimizing.

• False sharing & cache effects: place frequently-updated fields on separate cache lines (align/pad) to prevent ping-ponging and degraded throughput on multi-core systems.

• High-level strategies: prefer simpler locks when contention is low; switch to sharding or lock-free only if profiling shows lock-induced latency or blocking stalls throughput.

Worked example — "Implement a thread-safe LRU cache"

First 30s: clarify capacity, expected read/write ratio, eviction policy ties, required atomicity (single-key atomic vs. global), and persistence/serialization needs. Skeleton answer pillars: (1) data structures: unordered_map for lookup plus doubly-linked list for recency; (2) synchronization: naive global std::mutex for correctness first; (3) performance: sharded cache (N shards each with own map/list and mutex) to reduce contention; (4) eviction: per-shard LRU or global approximate LRU with periodic balancing. Flag tradeoff: a single global lock simplifies correctness and exact LRU but serializes all ops; sharding improves throughput but yields only per-shard LRU (approximate globally). Also mention memory reclamation for nodes if doing lock-free lists. Close by stating further work: measure p99 latency, add metrics (hit-rate, eviction-rate), tune shard count to number of cores, and consider read-mostly optimization with shared_mutex or hazard pointers if lock-free lookup is attempted.

A second angle — "Design a low-contention concurrent counter"

Frame: clarify accuracy (strictly consistent vs. eventual), update rate, and read frequency. Same core concepts apply: atomic increments vs. sharded counters. A basic solution uses std::atomic<uint64_t> for correctness but suffers on multicore under heavy writes. Better: use per-thread or per-core counters (an array indexed by thread-id) and aggregate reads occasionally; this reduces cache bouncing and increases throughput at the cost of slightly stale reads. You'd discuss padding to avoid false sharing and use relaxed memory ordering for increments, while using stronger ordering on aggregation. If exactness is required, combine per-shard counters plus a rare global CAS to reconcile. Emphasize measurement: quantify throughput improvement and staleness tradeoff.

Common pitfalls

Pitfall: assuming atomic++ scales — under high write contention, a single atomic variable becomes a hotspot and kills throughput; prefer sharding or per-thread accumulation.

Pitfall: forgetting spurious wakeups or relying on if around condition_variable::wait() — this yields missed signals and correctness bugs; always re-check the predicate in a loop.

Pitfall: over-promising lock-free correctness without addressing memory reclamation/ABA — a lock-free queue implementation that neglects safe node reclamation will have subtle, crash-prone bugs in production.

Connections

Concurrency interviewers may pivot to adjacent topics like distributed systems consistency (locks → distributed locks, leader election) or performance engineering (profiling, cache behavior, NUMA effects). They might also ask about language-specific models (Java Memory Model, C++ memory_order) or testing strategies for concurrent code (stress tests, fuzzing).

Further reading

• The Art of Multiprocessor Programming — Herlihy & Shavit — canonical book on lock-free/wait-free algorithms and memory models.

• Java Concurrency in Practice — Brian Goetz et al. — practical patterns and pitfalls for concurrency, useful even if not coding in Java.

What's being tested

Interviewers are probing your practical fluency with building robust, low-latency networked services: how you pick transports, manage concurrency, reason about latency vs throughput, and design protocols that handle partial failures (retries, timeouts, idempotency). They expect concrete tradeoffs (e.g., blocking threads vs non-blocking I/O) and the right low-level knobs (TCP_NODELAY, buffer sizes, framing) a Software Engineer must use to meet performance and correctness targets.

Core knowledge

• TCP vs UDP semantics: TCP = reliable, ordered, congestion-controlled; UDP = unreliable, unordered, lower latency. Use UDP for multicast/real‑time with application-level recovery.

• Socket API essentials: socket, bind, listen, accept, connect, send, recv, nonblocking EAGAIN behavior; handle partial send/recv and SIGPIPE.

• Non-blocking I/O and readiness APIs: select/poll (O(n) with limits), epoll/kqueue (scales to 10k+ fds), use edge-triggered vs level-triggered semantics deliberately.

• Bandwidth-Delay Product (BDP): BDP = bandwidth * RTT; set send/recv buffers to ~BDP to avoid sender/receiver starvation for high-throughput, high-RTT links.

• Framing strategies: length-prefixed framing versus delimiter-based; use length-prefix + size cap to avoid message-splitting and injection attacks.

• Nagle and delayed ACKs: Nagle's algorithm can increase latency; disable with TCP_NODELAY for small latency-sensitive messages, but consider increased packet count and bandwidth.

• Head-of-line blocking: TCP enforces ordering; multiplexing protocols (e.g., HTTP/2 streams) or UDP-based designs avoid HOL blocking; trade reliability vs complexity.

• Timeouts, retries, idempotency: choose client-side timeouts << overall SLA; implement exponential backoff with jitter; design idempotent RPCs (idempotency keys) so retries are safe.

• TLS cost and session resumption: TLS handshake adds CPU + latency; reuse sessions, enable session tickets, or terminate TLS at trusted endpoints if acceptable.

• Serialization cost: binary formats (protobuf) are more compact and faster to parse than JSON; measure (CPU vs wire savings) before choosing.

• MTU & fragmentation: typical MTU=1500 bytes; avoid UDP fragmentation; enable Path MTU Discovery or send smaller datagrams to avoid reassembly penalties.

• Monitoring & SLOs: track p50, p99, and tail-latency; instrument connect/handshake/send/recv latencies and queue lengths to detect queuing-induced tail spikes.

Worked example

Design a non-blocking TCP server to handle 10k concurrent client connections. First 30 seconds: ask clarifying questions—expected request rate per connection, message size distribution, latency SLOs (p99 target), and whether messages are request/response or streaming. Skeleton answer pillars: (1) use non-blocking I/O with epoll (edge-triggered) and a fixed-size thread pool for processing; (2) implement a small per-connection state machine with length-prefixed framing and a bounded write buffer to handle EAGAIN; (3) apply backpressure so overload drops or rejects new requests early; (4) operational controls: SO_SNDBUF/SO_RCVBUF tuned to BDP, TCP_NODELAY depending on small-message latency need. Tradeoff flagged: edge-triggered epoll requires careful loop to drain sockets or you'll miss events—simpler level-triggered is safer but slightly less efficient. Close: mention metrics to expose (active_connections, send_queue_len, handler_latency), and "if I had more time" you'd add connection pooling, adaptive thread sizing, and stress tests with synthetic traffic to tune buffer sizes.

A second angle

Consider designing a retry and idempotency scheme for RPCs over TLS with strict correctness requirements. The same core concepts apply, but constraints change: TLS increases handshake cost so keep connections pooled and long-lived; retries must consider whether the server processed the request before the connection dropped—use idempotency keys or explicit at-most-once semantics with server-side deduplication. Framing stays length-prefixed, but you must authenticate and authorize each message; add per-RPC unique IDs and persistent logs for dedup checks. Here, latency SLOs push you to choose smaller timeouts and conservative retry counts; additionally, prefer application-level ACKs to know when it’s safe to retry versus assuming retransmission.

Common pitfalls

Pitfall: conflating packet loss with application-level failure.
Many engineers treat a timeout as a permanent failure without distinguishing transient packet loss, server crash, or slow processing; always design retries with increasing backoff and idempotency.

Pitfall: assuming blocking calls are okay at any scale.
Proposing a thread-per-connection model for 10k connections is tempting, but it fails on memory and context-switch costs; explain why event-driven or async I/O scales better.

Pitfall: neglecting framing and partial reads/writes.
Returning a naive recv() loop that assumes one recv() == one message is wrong; always implement buffering and handle partial messages, oversized lengths, and malicious inputs.

Connections

Interviewers may pivot to performance profiling (where to measure CPU vs network stalls) or security (threat model for TLS, certificate rotation, MITM mitigations). They may also ask about distributed-systems reliability patterns like circuit breakers, leader election, or consensus if the protocol needs stronger guarantees.

Further reading

• [TCP/IP Illustrated, Volume 1 — W. Richard Stevens] — classic, deep grounding in TCP/IP behavior and edge cases.

• [High Performance Browser Networking — Ilya Grigorik] — excellent practical coverage of latency, BDP, MTU, and TLS effects on performance.

Practice questions