Pick a focused question that fits your time, stack, and interview goal.
How much time do you have?
Show one-drill sessions you can finish now.
108 results across 1 active filter
Page 1 of 5
Separates hiding implementation complexity from controlling access to state, with practical examples where both ideas work together.
Uses public, internal, protected, private, and protected internal deliberately to control API surface and inheritance exposure.
Builds a story about protecting quality while still making practical delivery decisions.
Builds a small, immutable, non-root .NET runtime image with controlled inputs, external configuration, graceful lifecycle behavior, and a practical patching strategy.
Chooses contracts and shared implementation based on substitutability, state ownership, evolution, and inheritance constraints.
Builds a story about resisting unnecessary complexity and choosing maintainable design.
Chooses a sequential collection from size, mutation, access pattern, memory locality, and the behavior callers actually need.
Avoids hidden quadratic work by indexing repeated matches while preserving duplicate, missing, ordering, and memory semantics.
Compares test doubles by purpose and explains when a real dependency provides a more trustworthy test.
Chooses a type shape from identity, value semantics, mutation, copy cost, default values, and serialization boundaries.
Maps business invariants and stale-data tolerance to strong or eventual consistency, explicit failure behavior, reconciliation, and user-visible state.
Creates valid objects with clear intent while choosing construction patterns proportionally to optional data, validation, and lifecycle complexity.
Places state according to who owns it, how long it must live, and whether the URL or server is the source of truth.
Chooses a deployment strategy from capacity, compatibility, risk, observability, and rollback needs, then defines progressive promotion and abort signals.
Selects small structural and behavioral patterns from the problem being solved instead of pattern-name recognition.
Separates ordinal identity comparison from culture-aware display ordering and keeps hash-based collection semantics consistent.
Chooses database test infrastructure by the provider behavior a test must prove.
Builds a proportionate test plan from blast radius, failure probability, detectability, and reversibility.
Chooses counters, traces, stack snapshots, GC dumps, full dumps, or a profiler from the production symptom and investigation cost.
Explains how unit, integration, contract, component, and end-to-end tests cover different failure boundaries.
Explains inward dependency flow, stable business policy, adapters, and when a smaller project structure is enough.
Uses complexity as a first filter while accounting for constants, locality, allocations, data size, and the complete operation sequence.
Builds a story about explaining engineering risk in business terms without hiding uncertainty.
Combines focused collaborators for independent behavior while recognizing cases where a genuine stable hierarchy remains simpler.