Java Full Stack Developer Top 100 Interview Questions

Choose a status that matches the outcome and the request’s semantics, then provide a consistent response representation where allowed. Returning success for every failure prevents clients and infrastructure from reacting correctly.

• Contract: define which conditions produce each code, including resource creation, asynchronous work, validation, and concurrency conflicts.
• Security: distinguish authentication from authorization without revealing resource or account existence contrary to the application’s access policy.
• Body and headers: honor method and status rules, include required authentication or resource-location information where appropriate, and avoid bodies for statuses that prohibit them.
• Retries: indicate recoverability through a documented policy and relevant headers rather than making clients guess from a message string.

I would treat the API as a versioned consumer contract and change it according to compatibility rules. The server’s ability to compile does not prove that deployed clients still work.

• Compatible changes: evaluate additions, optional fields, default values, and new enum values against actual client parsing behavior rather than assuming all additions are harmless.
• Breaking changes: changes to required fields, types, meanings, error behavior, or resource relationships may need a new supported version or a staged migration.
• Version mechanism: choose a consistent URL, media-type, or header policy, and configure caches and routing to distinguish variants when required.
• Migration: publish a deprecation plan, monitor version usage, test representative clients, and keep a defined overlap period before removing an old contract.

Versioning should cover semantics as well as structure. A field that still contains a number can be incompatible if its units or interpretation silently change.

I would implement an idempotency contract backed by durable storage and database uniqueness. Disabling a button in the browser cannot prevent retries from networks, clients, or concurrent requests.

1. Require or derive a stable idempotency key scoped to the authenticated caller and operation, and record a canonical representation or hash of the request meaning.
2. Atomically reserve or check the key, rejecting reuse with a different request and defining how concurrent attempts observe in-progress work.
3. Commit the business result and the durable idempotency outcome through a consistent transaction or recoverable coordination mechanism.
4. Return the recorded outcome for a valid retry, with retention covering the supported retry horizon and tests for failures around commit and response delivery.

flowchart TD
A["Validate caller request and key"]
B{"Key already recorded?"}
C{"Request meaning matches?"}
D["Return or resolve recorded outcome"]
E["Reject conflicting key reuse"]
F["Create order and record outcome atomically"]
G["Return committed result"]
A --> B
B -->|yes| C
B -->|no| F
C -->|yes| D
C -->|no| E
F --> G

Trade-offs:

• Durable key tracking adds storage and lifecycle work but handles uncertainty after a committed operation loses its response.
• An overly short retention period can allow a delayed retry to create another order after the earlier key expires.

Offset pagination skips a specified number of rows. Cursor pagination resumes from an ordered position or server-issued token, which can avoid repeatedly scanning or skipping deep result prefixes.

When to use which:

• Use offsets for manageable, relatively stable lists when direct page navigation matters and the database can satisfy the expected access pattern efficiently.
• Use cursors for large or frequently changing feeds, with a deterministic ordering that includes a unique tie-breaker when the main sort key can repeat.
• Use a consistent snapshot or explicit result version when the user must traverse one fixed population instead of a changing feed.

Cap page size and validate cursor scope. A cursor is not an authorization token, and neither pagination style automatically prevents duplicates or omissions during concurrent updates without defined consistency semantics.

Cache-aside checks a cache before reading the authoritative store and fills the cache after a miss. Correctness depends on key design, expiry, and how writes interact with cached values.

1. Identify data that tolerates caching, define freshness expectations, and include relevant tenant, authorization, query, and representation dimensions in the key.
2. On a hit, serve an eligible cached value; on a miss, read the authoritative store and populate the cache with an appropriate lifetime.
3. After a successful write, invalidate or update affected entries through a strategy that accounts for concurrent reads and possible stale repopulation.
4. Monitor hit rate, staleness, memory, and failure behavior, and prevent hot-key misses from overwhelming the underlying database.

flowchart TD
A["Read cache by scoped key"]
B{"Usable value present?"}
C["Return cached value"]
D["Read authoritative store"]
E["Populate bounded cache entry"]
F["Return loaded value"]
G["Committed write invalidates affected keys"]
A --> B
B -->|yes| C
B -->|no| D
D --> E
E --> F
G --> A

Trade-offs:

• Longer lifetimes reduce database reads but increase the period during which an uncoordinated stale value may be served.
• Stricter consistency can require version checks or stronger coordination; cache deletion alone does not eliminate every race.

Synchronous processing returns the operation’s outcome within the request. Asynchronous processing accepts durable work and lets the client observe completion later through a documented mechanism.

When to use which:

• Use synchronous processing when the operation reliably fits the request deadline and the caller needs an immediate result to continue the interaction.
• Use a durable asynchronous job when processing is lengthy, bursty, or dependent on unreliable external services, with retry and progress behavior designed explicitly.
• Return a stable job identity and status contract for accepted work, including completion, failure, cancellation, and result retention where relevant.

Starting a background thread before returning success is not equivalent to durable job acceptance. The process can fail before the work is recorded or completed, leaving the client with no recoverable outcome.

A modular monolith keeps clear internal boundaries within one deployable application. Microservices separate deployment and runtime ownership, introducing network and distributed-data concerns between services.

When to use which:

• Use a modular monolith when one deployment meets current needs and clear modules can support team ownership without the overhead of many networked services.
• Use microservices when independently evolving business capabilities, scaling patterns, or ownership boundaries justify their operational and coordination costs.
• Define service boundaries around cohesive business responsibilities rather than splitting every database table or controller into a separate service.

Microservices do not remove coupling if releases or databases remain tightly coordinated. Evaluate observability, compatibility, transaction design, local development, and incident ownership alongside potential scaling benefits.

The outbox stores the business change and an event record in the same local database transaction. A separate publisher delivers committed events, avoiding an uncoordinated database-write and message-send pair.

1. Write the business update and a uniquely identified outbox record in the same transaction so either both commit or neither becomes visible.
2. Have a publisher read committed outbox entries and deliver them with retry, monitoring, and an appropriate ordering policy.
3. Record delivery progress safely, recognizing that a crash after publication but before acknowledgment can lead to repeated delivery.
4. Make consumers handle duplicate event identities and reconcile stuck entries, while managing outbox retention and failed delivery explicitly.

flowchart TD
A["Begin business transaction"]
B["Write business state"]
C["Write identified outbox event"]
D["Commit both records"]
E["Publish committed event"]
F["Consumer applies duplicate safe effect"]
G["Record delivery progress"]
A --> B
B --> C
C --> D
D --> E
E --> F
E --> G

Trade-offs:

• The pattern makes local state and event intent atomic, but it does not automatically provide exactly-once delivery to every external consumer.
• A separate publisher adds delay and operational work, so monitor event age as well as ordinary request success.

I would bound waiting, retry only suitable failures, and stop repeatedly calling a dependency that is clearly unhealthy. These mechanisms must fit one overall request deadline and duplicate-safety policy.

1. Define connection, response, and overall deadlines based on the user operation, preserving enough budget for cleanup and a meaningful response.
2. Retry selected transient failures with bounded backoff and jitter only when the operation is safe to repeat or has a reliable idempotency mechanism.
3. Use a circuit breaker to reject or reroute calls after a measured failure threshold, allowing controlled probes before returning to normal traffic.
4. Limit concurrent work, expose failure and recovery metrics, and provide a fallback only when it is valid for the business operation.

flowchart TD
A["Request dependency operation"]
B{"Circuit permits call?"}
C["Call within remaining deadline"]
D{"Recoverable failure and budget?"}
E["Back off and retry safely"]
F["Return failure or valid fallback"]
G["Return successful result"]
A --> B
B -->|no| F
B -->|yes| C
C -->|success| G
C -->|failure| D
D -->|yes| E
D -->|no| F
E --> B

Trade-offs:

• Retries can improve success during brief failures but can also multiply traffic and make an overloaded dependency recover more slowly.
• A fallback that invents success for a failed write is worse than a clear unavailable or pending outcome.

I would measure where end-to-end time is spent before optimizing code. A slow endpoint can be waiting for resources rather than consuming CPU in business logic.

1. Reproduce the affected route with representative input, concurrency, and response size, comparing typical and tail latency against earlier healthy behavior.
2. Trace request time across queuing, authentication, application code, database queries, dependency calls, serialization, and network transfer.
3. Inspect the dominant stage using suitable evidence such as query plans, thread state, allocation or CPU profiles, pool waits, and downstream timing.
4. Apply a targeted change and verify result correctness, throughput, tail latency, and resource use under realistic load before accepting it.

flowchart TD
A["Measure endpoint latency distribution"]
B["Trace time across stages"]
C{"Waiting dominates?"}
D["Inspect pools locks and dependencies"]
E["Profile computation and allocation"]
F["Apply targeted correction"]
G["Verify under representative load"]
A --> B
B --> C
C -->|yes| D
C -->|no| E
D --> F
E --> F
F --> G

Trade-offs:

• More threads can increase database contention instead of reducing delay when connections or query capacity are already saturated.
• Caching may reduce repeated work but adds freshness and authorization-key requirements that must remain correct.

Isolation determines which effects of concurrent work a transaction may observe. It is one part of ACID and must be chosen around the business invariant being protected.

When to use which:

• Use an isolation level that supports the actual operation, checking the database’s documented behavior rather than relying on a portable-sounding name alone.
• Use stronger isolation, conditional writes, or suitable locks when an invariant spans several reads and writes that another transaction could invalidate.
• Handle serialization failures and deadlock victims with a bounded safe retry of the whole logical transaction when the application can support it.

A transaction wrapper does not automatically prevent lost updates or write skew at every isolation level. External side effects also remain outside a local database transaction unless separately coordinated.

Normalization separates facts according to keys and dependencies to reduce redundant updates. Denormalization intentionally duplicates or precomputes selected information to serve a measured access need.

When to use which:

• Normalize operational data when several copies of the same fact would otherwise need coordinated updates, especially for independently changing entities.
• Denormalize selectively when profiling shows a useful read improvement and the team can define how derived copies are refreshed, reconciled, and corrected.
• Keep the authoritative source of each fact clear even when summaries, caches, or reporting tables contain convenient copies.

A table with fewer joins is not automatically a better design. Evaluate write complexity, consistency, index behavior, query patterns, and the cost of maintaining derived values under concurrent changes.

I would start from the customer table and use a left join to orders, then count a non-null order identifier. Counting all joined rows would incorrectly count the placeholder row for a customer without matches.

• Population: the left side must contain every customer that should appear in the output, even if the order table has no corresponding record.
• Counting: use COUNT(order_id) when that identifier is guaranteed non-null for real orders; COUNT(*) counts the unmatched outer-join row too.
• Filtering: place appropriate order conditions in the join or a prefiltered input when customers with zero qualifying orders must remain visible.
• Grain: group by the customer identity and avoid additional one-to-many joins that would multiply orders before aggregation.

Define whether canceled or incomplete orders belong in the business count rather than letting an implicit filter decide it.

I would begin with the query’s filtering, join, and ordering needs and inspect the execution plan. Creating an index on every mentioned column can increase cost without reducing the important work.

1. Identify the actual query parameters, returned columns, data distribution, expected selectivity, and relevant write workload.
2. Inspect scans, estimated versus actual rows, sorting, joins, and time or buffer use, distinguishing missing access paths from blocking or incorrect query logic.
3. Evaluate an index whose key order and optional covered columns fit the common access pattern, checking whether expressions or conversions prevent useful access.
4. Measure representative reads and writes after the change, retaining the index only when the overall benefit justifies its storage and maintenance cost.

flowchart TD
A["Inspect query and data distribution"]
B["Read execution plan"]
C{"Access path is the bottleneck?"}
D["Design suitable index"]
E["Investigate other query costs"]
F["Measure read and write effects"]
A --> B
B --> C
C -->|yes| D
C -->|no| E
D --> F

Trade-offs:

• A covering index may reduce table lookups but consumes more space and adds write work.
• A full scan may be correct for a query reading most rows, so index usage alone is not a success metric.

I would rank distinct salary levels rather than employee rows and select the second level. Tied employees must not cause the highest salary to be mistaken for the second highest distinct value.

• Missing data: exclude NULL salaries unless the question explicitly defines an alternate business treatment for unknown values.
• Ranking: use DENSE_RANK over salary descending so ties share a rank and each new distinct amount receives the next consecutive rank.
• Result shape: return a distinct salary when the question asks for the amount, or return all employee rows at that rank when it asks for the employees.
• Boundary: if the dataset contains fewer than two distinct salaries, define whether the application expects no row or an explicitly missing result.

Using a simple offset over ungrouped employees answers a different question whenever several employees share a salary.

I would rank employees separately within each department and filter the result in an outer query. A global row limit cannot return an independent top group for every department.

• Partition: use the department identity as the window partition so each department starts its own ranking sequence.
• Tie policy: use ROW_NUMBER with a stable employee identifier when the requirement is at most two employees; use a shared ranking when all ties must qualify.
• Ordering: make salary direction and treatment of unknown salaries explicit, and add the final presentation order separately from the window calculation.
• Validation: test departments with one employee, equal salaries, and missing values to ensure the selected behavior matches the question.

If the query starts from joined data, first ensure there is one input row per employee rather than ranking duplicated rows.

I would use a windowed SUM partitioned by account with an explicit ordering and row frame. This preserves transaction rows while calculating each account’s cumulative amount independently.

• Scope: use compatible units and currency, and determine whether the requested amount includes a separate opening balance before interpreting it as an account balance.
• Sequence: order by the authoritative transaction sequence or timestamp plus a unique tie-breaker so intermediate totals are deterministic.
• Frame: specify all preceding rows through the current row when the result should advance one transaction at a time.
• Presentation: apply a final ORDER BY for returned rows, because the ordering inside a window defines the calculation rather than a general result-order guarantee.

Be careful when filtering history: calculating after excluding older transactions changes the starting total unless that omission is intentional.

Prepared statements bind data values separately from SQL structure, so a supplied value is not interpreted as newly introduced SQL syntax. The protection depends on actually using parameter binding rather than concatenating untrusted text.

• Values: bind identifiers, search terms, dates, and other data through the supported parameter API, preserving their intended types where practical.
• Structure: table names, column names, sort directions, and other SQL syntax generally require controlled construction from an allowlist rather than ordinary value placeholders.
• Coverage: apply the same discipline to raw queries inside persistence layers; using an object-mapping abstraction does not make concatenated query fragments safe.
• Defense: validate business inputs, use least-privilege database access, and return safe errors as complementary controls rather than substitutes for binding.

Escaping strings manually is easy to get wrong across encodings and dialects. Prefer a supported binding mechanism and inspect any remaining dynamically assembled SQL structure.

A connection pool manages reusable database connections so requests do not repeatedly establish expensive physical sessions. It also limits the amount of concurrent database work the application can admit.

• Borrowing: a request acquires a connection, uses it within a bounded operation, and returns it promptly through the documented close or release mechanism.
• Leaks: omitted cleanup on exceptional paths, retained connection references, or unfinished transactions can prevent resources from returning to the pool.
• Contention: long connection hold times or excessive concurrency create wait queues even when individual queries are reasonably fast.
• Operations: monitor active and idle connections, acquisition latency, timeouts, transaction duration, and database capacity together rather than increasing the pool blindly.

Use structured resource ownership and avoid slow unrelated work while holding a connection. A pool’s configured maximum across all application instances must still fit the database’s sustainable capacity.

A persistence context tracks managed entity instances and coordinates their changes with database operations. Knowing an entity’s state explains why changing an object may or may not lead to a stored update.

• New or transient: the object has not become managed through the relevant persistence operation and is not automatically tracked for insertion merely because it exists in memory.
• Managed: the context tracks the entity, and eligible changes can be detected and synchronized according to flush and transaction rules.
• Detached: the object is no longer associated with that context, so changing it does not automatically update the database through the old context.
• Removed: the managed entity has been marked for deletion, with database effects synchronized according to the configured lifecycle and transaction semantics.

A merge-style operation generally returns a managed representation; callers should not assume the original detached object itself becomes the tracked instance.