Technical Interview Practice

The question is really about concurrency semantics: plain HashMap corrupts under concurrent puts; CHM gives lock-free reads, bin-level write locks, and CAS on absent keys.

Why it matters: The single most-asked Java concurrency opener. It separates “used a map” from “understands memory visibility.”

Common mistake: “CHM is just a synchronized HashMap” misses both the read path (volatile values, no locking) and the weakly-consistent iteration you are buying.

Trade-off: Sizing matters: CHM size() is a counter-sum, iteration is a snapshot-in-time. Fine for stats, wrong for “stop exactly when count hits N” logic.

Ideal structure: Structure: bucket array + chaining, load factor, vs segment/CAS, visibility/happens-before, and the choice under read-heavy vs write-heavy + iteration semantics.

Tip: Contrast iteration fail-fast vs weakly consistent and mention sizing.

Follow-up to expect: “How would you implement an atomic compute-if-absent without losing updates?” The answer is computeIfAbsent or merge, and knowing why put-if-absent races.

Graded on sequencing: clarify (per-user vs global, burst tolerance), estimate (memory, counters), then choose algorithm and placement. Local token buckets plus async roll-up versus one central store.

Why it matters: It tests whether you design from constraints or from vocabulary; the phrase “per user across regions” hides the actual trade-off: cross-region consistency latency.

Common mistake: Redis solves it. A synchronous global counter across regions adds cross-region latency to every request; acceptable precision must be discussed, not assumed.

Trade-off: Fail-open (users see 429s from an outage) vs fail-closed (limiters stop protecting) is a product decision. Name the owner and the default.

Ideal structure: Requirements (per-user, burst), estimate (QPS, memory), propose token bucket + centralized counter (Redis) vs local + sync, trade-offs, and failure handling.

Tip: State per-user vs global before picking algorithm.

Follow-up to expect: “What happens to accuracy during a counter-store partition?” Seconds of over-allowance should be your stated, accepted cost.

The grade lives in order and verification: correlate GC-time and heap-growth trends before acting, dump safely (jmap/heap dump with care under load), analyze dominators (MAT), name the holder, then prove the fix with metrics.

Why it matters: Real incidents separate tutorial memory from operational memory. Restart frequency, dump size vs RAM, and staging reproduction all surface in follow-ups.

Common mistake: Dumping and analyzing without first ruling out a growing legitimate cache. A heap full of entries is not automatically a leak.

Trade-off: The answer’s final sentence is always prevention: bounded caches, weak refs, try-with-resources, and an alert on old-gen trend so next time is detected at 10%, not 90%.

Ideal structure: Heap dump (jmap), MAT dominator tree, leak suspects, fix (unclosed cache/listener), verify via metrics/GC logs, and prevention (try-with-resources, weak refs).

Tip: Name a real tool you used and the metric that confirmed the fix.

Follow-up to expect: “How do you restart-avoid while you wait for the fix?” Heap-dump off-heap mitigations and rolling restarts are the expected answer.

Three routes: DENSE_RANK window, correlated subquery, self-join. But the grade is on semantics first: “second highest salary value” (DENSE_RANK) versus “second row” (ROW_NUMBER) are different questions most candidates answer without noticing.

Why it matters: SQL rounds use this to test whether you reason about correctness under duplicates before touching performance, and every loop asks it of data-adjacent roles.

Common mistake: MAX(salary) WHERE salary < MAX(salary) happens to be right for the value case, but it quietly breaks on empty groups and confuses people about NULL semantics.

Trade-off: On 10M rows the index on salary decides everything; the window function scans once, correlated subqueries can scan per row. EXPLAIN before opinion.

Ideal structure: Window (DENSE_RANK) vs subquery vs self-join; discuss index on salary, handling ties, and plan on 10M rows.

Tip: Mention index and `EXPLAIN`.

Follow-up to expect: “Now per department, and only the top two salaries.” PARTITION BY and a filter on rank; ties behavior stated aloud.

The question inverts the reflex: caches hurt when invalidation is a correctness bug, hit rates are too low to pay the complexity, memory pressure shifts elsewhere, or stale reads break money paths.

Why it matters: Saying “always cache reads” is the junior tell; naming the invalidation strategy and its failure modes is the senior tell.

Common mistake: A cache in front of slow-but-rare reads is latency theater. Measure the hit-rate economics before the pattern.

Trade-off: Every cache is a data-replication decision: TTL simplicity vs event-driven invalidation vs read-through complexity. Pick and defend with numbers.

Ideal structure: Start with access pattern and staleness budget; cache when read frequency x savings exceeds invalidation + memory + staleness cost; name the stampede and eviction policies that come next.

Tip: The strongest sentence: “for this data, a cache is a correctness risk. Here is why not.”

Follow-up to expect: “Cache expires mid-traffic spike: what does the DB see?” Stampede protection (lock-ahead, jittered TTLs) is the point of the story.

Define the four conditions briefly, then show the engineering move: impose a global lock order, or scope locks to avoid cycles entirely (single-owner queues, sharded locks), or accept and detect with timeouts.

Why it matters: Concurrency questions are asked as incidents, not definitions. “Our payments worker started stalling” is the real version.

Common mistake: “Use tryLock and retry” without backoff turns a deadlock into a livelock. Know the difference when they ask it.

Trade-off: Coarse locks are simple and slow; fine-grained locks are fast and subtle. The answer states which you chose at which traffic level.

Ideal structure: Mutual hold-and-wait cycle; prevention by ordering and scoping; detection by timeout + thread dumps; recovery with bounded retry and jitter.

Tip: Name a real lock-ordering fix (“we sorted account IDs before locking both”), not just textbook terms.

Follow-up to expect: “What does the thread dump actually show?” BLOCKED pairs with a wait-chain description.

Client-generated idempotency keys, stored with the response for a retention window; unique constraint on the key; concurrent replays handled by the storage layer, not by hoping requests serialize; TTL-scoped replay returns the same result code.

Why it matters: At-least-once delivery is everywhere (retries, timeout-guessing users, payment rails); panels use this to see if you have shipped anything that could not afford a double-execute.

Common mistake: Checking-then-inserting without a unique index. The race is exactly between the check and the insert.

Trade-off: Key retention is a product decision: keep it long enough to cover retries, short enough to bound storage. Say both numbers out loud.

Ideal structure: Idempotency-key header + unique constraint + stored response replay + concurrent-retry behavior + TTL + what happens if the first request failed midway.

Tip: The gold sentence: “replaying the same request returns the same result, not an error and not a second charge.”

Follow-up to expect: “Crash between order-write and response-persist: what does the retry see?” Transactional outbox or recoverable design is the answer they want.