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.
878 drills fit a 10-minute session. Closest fits first.
Page 11 of 37
Treats @Async as an in-process executor boundary with proxy, failure, context, capacity, and durability consequences.
Uses an explicit discriminator to model genuine request variants with predictable validation and OpenAPI output.
Chooses between small in-process follow-up work and durable, independently operated background execution.
Explains lazy query construction, evaluation triggers, result caching, and repeated-query surprises.
Uses generics to preserve relationships among types and introduces bounds, constraints, and variance only where they clarify a real API.
Uses derived types for genuine relationships while preserving explicit boundaries for domain and transport models.
Chooses between blocking Servlet execution and end-to-end non-blocking reactive execution based on dependencies, concurrency, and team cost.
Chooses among explicit joins, reusable fetch graphs, and bounded secondary selects based on query shape and cardinality.
Places protocol-wide work in filters, handler-aware MVC work in interceptors, and controller exception or body concerns in advice.
Chooses a query representation from static versus dynamic shape, portability, database features, readability, and performance evidence.
Chooses version-based conflict detection or database locks from contention, transaction duration, and invariant needs.
Uses HTTP rules for route-level policy and method security for reusable service operations without creating contradictory enforcement.
Chooses synchronous, reactive, or declarative clients based on the application's execution model while keeping shared timeout and error policy explicit.
Chooses credential transport and server state from client shape, revocation, browser threats, scaling, and operational requirements.
Chooses hooks by application readiness phase and keeps migrations, warm-up, listeners, and background resources owned and observable.
Chooses visibility, mutual exclusion, or atomic read-modify-write based on the invariant instead of treating the tools as interchangeable.
Chooses the smallest execution model that satisfies the task while recognizing when explicit multi-step coordination adds real value.
Bases CSRF policy on whether browsers automatically attach credentials and keeps unsafe requests protected without disabling security globally.
Distinguishes small in-process post-response work from durable, retryable, independently operated jobs.
Uses generated examples to test stable invariants while preserving readable examples and reproducible failures.
Explains per-thread state, pooled-thread leakage, context cleanup, hidden dependencies, and virtual-thread scaling concerns.
Separates reactive synchronization inputs from non-reactive logic that still needs the latest props or state.
Chooses a Django user model early and preserves swappable references without turning it into a profile dumping ground.
Chooses request-response, streaming, or durable background execution based on duration, user interaction, reliability, and side effects.