More in Backend Dev — page 15
When to intentionally denormalize a schema
WHAT IT TESTS: trading read speed for write complexity deliberately. OUTLINE: identify read-heavy join cost, duplicate or precompute data, and own the consistency burden. RED FLAG: denormalizing prematurely or ignoring how duplicates drift.
Diagnosing and fixing the N+1 query problem
WHAT IT TESTS: spotting hidden per-row queries from lazy loading. OUTLINE: define the 1 parent plus N child queries, fix via JOIN or batched IN, and ORM eager loading. RED FLAG: solving it only with caching while ignoring round-trip count.
Read Committed versus Serializable isolation levels
WHAT IT TESTS: grasp of concurrency anomalies versus consistency cost. OUTLINE: name the four levels, map each anomaly (dirty read, non-repeatable read, phantom) to the level that blocks it. RED FLAG: claiming Serializable blocks only phantoms.
Materialization and Pipelining
Two query-execution strategies: materialization writes each operator's full output to disk before the next reads it, while pipelining streams tuples operator-to-operator without intermediate storage.
Design a graceful worker pool in Go
WHAT IT TESTS: concurrency coordination with goroutines, channels, and context. OUTLINE: buffered job channel, fixed worker goroutines, WaitGroup to await in-flight work, context cancellation to stop intake.
cgo threading challenges with multi-threaded C libraries
WHAT IT TESTS: understanding of the Go-to-C boundary and threading. OUTLINE: cgo calls run on a dedicated OS thread and detach the P; thread-local state and callbacks into Go are fragile; solutions include LockOSThread, minimizing crossings, and a dedicated…
Cancellation and cleanup: Go context/errgroup vs Tokio
WHAT IT TESTS: structured-concurrency cancellation knowledge. OUTLINE: Go propagates cancellation via context.Context that goroutines must poll, with errgroup canceling siblings on first error; Tokio cancels by dropping futures, which stops them at await…
Go scheduler work-stealing and blocking syscalls
WHAT IT TESTS: knowledge of the Go runtime scheduler internals. OUTLINE: the GMP model runs goroutines (G) on OS threads (M) attached to logical processors (P); idle P's steal half of another P's run queue; on a blocking syscall the M detaches with its G.
Implicit Go interfaces versus explicit Rust trait impls
WHAT IT TESTS: understanding of conformance models and maintainability. OUTLINE: Go's implicit satisfaction enables decoupling and retrofitting but hides who implements what and risks accidental conformance; Rust's explicit impls aid discovery, refactoring…
anyhow versus thiserror in Rust error handling
WHAT IT TESTS: idiomatic error-design judgment. OUTLINE: anyhow gives one opaque dynamic error type for applications where you mostly propagate and report; thiserror derives concrete typed enums for libraries so callers can match on variants.
Go if err != nil versus Rust's ? operator
WHAT IT TESTS: judgment on error-handling ergonomics. OUTLINE: Go's explicit checks are verbose but make every error site visible; Rust's ? propagates concisely while still forcing the error into the type, reducing boilerplate.
Designing a logging abstraction: Go interfaces vs Rust traits
WHAT IT TESTS: ability to design polymorphic abstractions and explain dispatch. OUTLINE: define a Logger interface/trait with a write method; Go interfaces are always dynamically dispatched; Rust lets you choose static dispatch (impl Trait/generics) or…
Go slices versus Rust Vec growth and reallocation
WHAT IT TESTS: understanding of dynamic-array internals. OUTLINE: both are a (pointer, length, capacity) triple over a heap buffer that reallocates and copies on growth, roughly doubling; key difference is Go slices share backing arrays and have no ownership…
Go interfaces versus Rust traits and macros at scale
WHAT IT TESTS: connecting language philosophy to ecosystem patterns. OUTLINE: Go uses reflection over interface{} (e.g. encoding/json) for runtime flexibility; Rust uses traits plus derive/proc macros (e.g. serde) for compile-time, zero-cost code generation.
Go's mandatory runtime versus Rust's minimal runtime
WHAT IT TESTS: understanding of runtime cost and its limits. OUTLINE: Go ships a GC and goroutine scheduler in every binary, ideal for services; Rust has only a tiny runtime and no GC, enabling embedded, kernels, and WASM.
Go interface-constraint generics versus Rust trait bounds
WHAT IT TESTS: understanding of generics design and monomorphization. OUTLINE: Go constrains type parameters with interfaces and may use dictionaries/shape stenciling; Rust uses trait bounds with full monomorphization for zero-cost specialization.
Go (T, error) versus Rust Result for error handling
WHAT IT TESTS: understanding of explicit error models. OUTLINE: Go returns a separate error value you may ignore; Rust wraps success or error in one Result enum the compiler forces you to handle. Go favors simplicity, Rust favors compile-enforced safety.
Goroutines and channels versus ownership-based concurrency
WHAT IT TESTS: understanding of two concurrency philosophies. OUTLINE: Go uses cheap goroutines and CSP-style channels to coordinate by communication; Rust uses ownership plus Send/Sync to make data races a compile error.
Structural Go interfaces versus nominal Rust traits
WHAT IT TESTS: grasp of typing models and their design impact. OUTLINE: Go interfaces are satisfied implicitly by method shape (structural); Rust traits must be explicitly implemented (nominal).
Criterion: the standard Rust benchmarking library
WHAT IT TESTS: ecosystem awareness and rigor about measurement. OUTLINE: Criterion runs on stable Rust, collects many samples, applies statistical analysis with confidence intervals, and compares against saved baselines to detect regressions.