Java Full Stack Developer Top 100 Interview Questions

The approaches differ in when and where initial page markup is produced. They can be combined, and interactive behavior may still require client-side code after the initial content appears.

When to use which:

• Use client-side rendering when rich interaction and navigation fit the application, while measuring the initial download, execution, and data-fetch cost.
• Use server-side rendering when request-specific initial content is valuable, and ensure client hydration starts from compatible data and markup.
• Use prerendering when content can be generated ahead of time and served efficiently, with a clear refresh policy for changed information.

No rendering mode guarantees fast interaction or discoverability by itself. Authentication, caching, script size, network waterfalls, and content correctness still determine the user experience.

I would measure the actual user journey and identify whether delay comes from loading, execution, rendering, or backend dependencies. Smaller bundles help only when download or script execution is a meaningful bottleneck.

1. Reproduce the issue on representative devices and networks, measuring usable content, interaction delay, layout movement, and the relevant request waterfall.
2. Inspect transferred assets, main-thread work, rendering and layout activity, image dimensions, and repeated or serial data requests.
3. Apply targeted changes such as route-level code splitting, appropriate images, reduced unnecessary renders, bounded lists, or consolidated independent requests.
4. Retest the complete interaction, including accessibility and failure states, and compare user-facing metrics rather than relying only on a local development impression.

flowchart TD
A["Measure representative user journey"]
B{"Dominant delay?"}
C["Inspect network and assets"]
D["Inspect script and render work"]
E["Inspect backend request chain"]
F["Apply targeted change"]
G["Retest user experience"]
A --> B
B -->|loading| C
B -->|execution| D
B -->|dependency| E
C --> F
D --> F
E --> F
F --> G

Trade-offs:

• Aggressive lazy loading reduces initial work but can introduce visible delays when newly needed code or content is requested later.
• Virtualizing large lists can reduce DOM work while requiring deliberate handling of keyboard navigation and accessibility.

Authentication establishes an identity or verifies credentials. Authorization decides whether that identity may perform a particular action on a particular resource under the current conditions.

When to use which:

• Authenticate requests through a trusted mechanism and validate the resulting identity context before treating client-supplied identity claims as authoritative.
• Authorize each protected operation using relevant resource and action context, rather than assuming that a logged-in user may access every record.
• Apply checks on the server even when the interface hides unavailable actions, because direct requests do not need to pass through the intended UI.

A role check can be one input to authorization but is not always sufficient. Account status, resource ownership, tenant boundaries, and changes in permission may also affect the decision.

A server-side session usually maps an opaque identifier to server-held state. A self-contained signed token carries claims that a verifier can validate, with important differences in revocation and freshness.

When to use which:

• Use a server-side session when centralized invalidation and a browser-oriented session lifecycle fit the application, securing the identifier and session store.
• Use signed access tokens when their verification and distribution properties fit the architecture, validating trusted algorithms, issuer, audience, expiry, and other required claims.
• Choose token transport and storage separately: either model can involve cookies, and script-readable storage exposes credentials to successful script injection.

A signed JWT is not automatically encrypted, and its claims are not trustworthy merely because they can be decoded. Logout and permission changes need an explicit policy for already-issued tokens.

CORS controls permitted cross-origin browser access to responses and gates some requests through preflight. CSRF protection prevents an attacker’s site from causing an unwanted authenticated action using credentials the browser sends automatically.

When to use which:

• Configure CORS with approved origins, methods, and headers when a legitimate frontend must call another origin, handling credentialed requests according to browser rules.
• Protect state-changing cookie-authenticated requests with an appropriate anti-CSRF mechanism, origin validation, and suitable cookie policy as complementary controls.
• Test both accepted and rejected origins and credential paths; a request may reach the server even when browser code cannot read its response.

CORS is not enforced by every non-browser client and does not prove who the caller is. Avoid reflecting arbitrary origins while allowing credentials, and do not treat a missing preflight as proof that a request is safe.

Cross-site scripting occurs when untrusted content is interpreted as executable browser code in a trusted application context. Prevention requires safe rendering and context-appropriate treatment of untrusted values.

• Output context: encode values appropriately for their destination, such as HTML text, attributes, or JavaScript, rather than applying one universal string replacement.
• Safe APIs: prefer text insertion and safe templating behavior over constructing executable markup from untrusted strings, and review escape hatches that bypass normal protections.
• Rich content: when users may supply HTML, use a maintained allowlist sanitizer appropriate for that content instead of attempting to block a few suspicious substrings.
• Defense in depth: configure a suitable content security policy and protect credentials, while recognizing that these controls do not replace correct input-to-output handling.

Stored, reflected, and DOM-based injection can enter through different paths. Test realistic rendering contexts and avoid embedding secrets in browser-accessible content.

I would verify passwords using a suitable adaptive password hash and issue a controlled authenticated session after successful verification. Password storage, abuse prevention, and recovery all belong to the same account lifecycle.

1. Store a unique salt and an approved password hash, using an appropriate memory-hard algorithm such as Argon2id with parameters chosen for the deployment and current guidance.
2. Verify through a trusted implementation, apply bounded abuse controls, and avoid responses that unnecessarily disclose whether an account exists.
3. After successful authentication, rotate or establish the session identifier, protect its transport and storage, and apply additional verification when the risk model requires it.
4. Design reset, logout, credential change, and session revocation behavior, while keeping passwords and reusable credentials out of logs and diagnostic output.

flowchart TD
A["Receive credentials over protected transport"]
B["Apply abuse controls"]
C["Verify stored password hash"]
D{"Authentication accepted?"}
E["Create or rotate protected session"]
F["Return controlled failure"]
G["Record safe security event"]
A --> B
B --> C
C --> D
D -->|yes| E
D -->|no| F
E --> G
F --> G

Trade-offs:

• A more expensive password hash increases offline attack cost but also affects login capacity, so measure and rate-limit appropriately.
• Account recovery can undermine strong login checks if its identity and session-revocation rules are weaker.

I would treat uploaded bytes, names, and declared content types as untrusted. A successful upload should mean the file passed the application’s required checks and was stored under controlled access.

1. Authenticate and authorize the operation, enforce request and file-size limits, and allow only the file categories the business actually needs.
2. Validate content using suitable inspection or decoding rather than trusting extension or supplied MIME type, with limits for compressed or expanded content.
3. Generate a safe storage identity, keep files outside executable application paths, and apply scanning or quarantine appropriate to the supported content.
4. Serve accepted files through access-controlled delivery with safe content headers, and define lifecycle, rejection cleanup, and audit behavior.

flowchart TD
A["Authenticate and limit upload"]
B["Validate allowed content"]
C{"Required checks pass?"}
D["Store under generated identity"]
E["Reject or quarantine"]
F["Deliver through controlled access"]
A --> B
B --> C
C -->|yes| D
C -->|no| E
D --> F

Trade-offs:

• Deep inspection improves assurance but consumes resources and may require asynchronous quarantine rather than immediate publication.
• Preserving the original filename as display metadata can be useful, but it should not determine a trusted filesystem path.

I would authorize each operation using trusted identity, tenant context, resource ownership, and the requested action. An identifier supplied in a URL or request body is not evidence of permission.

1. Establish the caller and applicable tenant from verified context, and resolve the requested action through a deny-by-default policy.
2. Load or query the resource within the allowed scope, checking object-level and field-level permissions where the operation requires them.
3. Validate related resource identifiers and state transitions as well, preventing an allowed object from being linked to an unauthorized object elsewhere.
4. Apply the same policy to reads, writes, exports, caches, and background work, and test cross-user and cross-tenant requests directly.

flowchart TD
A["Verify caller and tenant context"]
B["Resolve scoped resource and action"]
C{"Policy permits operation?"}
D["Check related fields and resources"]
E["Apply authorized operation"]
F["Return policy appropriate rejection"]
A --> B
B --> C
C -->|yes| D
C -->|no| F
D --> E

Trade-offs:

• Centralized policy logic improves consistency, but each entry point must supply accurate resource and action context.
• Caching authorization-sensitive results improves latency only when keys and invalidation preserve the relevant user and tenant boundaries.

A container image is a packaged filesystem and execution configuration. A running container is an instance created from an image, with runtime process state and configured isolation and resources.

• Image: build a reproducible artifact containing the application and required runtime components, minimizing unnecessary content and avoiding embedded secrets.
• Instance: supply environment-specific configuration and appropriate identity, resource limits, network access, and filesystem permissions when starting the container.
• Storage: treat the instance’s writable layer as disposable unless persistence is intentionally provided through a suitable mounted or external storage mechanism.
• Operations: define readiness, health, graceful shutdown, logging, and version identification so instances can be replaced predictably during deployment and recovery.

Containers commonly share the host kernel and are not simply small virtual machines. Packaging the application does not by itself solve orchestration, data persistence, credential management, or application-level security.

These tests examine behavior at different boundaries. A useful strategy combines focused feedback with enough real integration coverage to catch defects that isolated components cannot reveal.

When to use which:

• Use unit tests for business rules, transformations, and edge cases that can be checked clearly without relying on a full application environment.
• Use integration tests for persistence, transactions, serialization, authentication boundaries, and dependency contracts where mocked behavior can hide important differences.
• Use a focused set of end-to-end tests for critical journeys, including failures and permissions, while controlling data, timing, and environmental causes of flakiness.

Mocking every collaborator can make tests fast but disconnected from reality. Conversely, checking every small rule only through a browser makes failures slow and difficult to localize.

I would test the observable contract and business invariants across valid, invalid, unauthorized, and concurrent requests. A response status alone does not prove that stored state or side effects are correct.

1. Create representative fixtures and verify request validation, response structure, status codes, headers, and the exact authorized data returned.
2. Exercise missing authentication, insufficient permissions, cross-resource access, invalid fields, absent records, and conflicting state transitions.
3. Test repeated requests and simultaneous updates where duplicate effects or race conditions could violate the business invariant.
4. Inject relevant dependency failures and verify rollback, durable outcomes, safe error mapping, and recoverability rather than merely checking that an exception occurred.

flowchart TD
A["Define API contract and invariant"]
B["Test valid and invalid inputs"]
C["Test authorization boundaries"]
D["Test concurrency and retries"]
E["Inject dependency failures"]
F{"Stored outcome remains correct?"}
G["Accept tested behavior"]
H["Repair boundary or recovery logic"]
A --> B
B --> C
C --> D
D --> E
E --> F
F -->|yes| G
F -->|no| H

Trade-offs:

• Real dependency tests provide stronger integration evidence but require controlled data and dependable environment cleanup.
• Excessive implementation-specific assertions make refactoring expensive without necessarily protecting user-visible behavior.

I would build reproducible versioned artifacts, verify their contracts together, and promote a reviewed release through controlled environments. Deployment must account for active older clients as well as running backend instances.

1. Validate source changes with focused backend and frontend checks, dependency review, and tests for important API and persistence behavior.
2. Build immutable application artifacts once, recording their versions and supplying environment-specific configuration without embedding production credentials.
3. Apply compatible schema changes and deploy through a bounded rollout, verifying readiness before routing ordinary traffic to new instances.
4. Monitor user-facing errors, latency, and critical business outcomes, then complete the rollout or execute a defined code and data recovery plan.

Retain required older frontend assets and API compatibility during the transition. Reverting an executable artifact does not automatically reverse a destructive schema change or repair data already written incorrectly.

flowchart TD
A["Review source and contracts"]
B["Run focused checks"]
C["Build versioned artifacts"]
D["Apply compatible migration and rollout"]
E{"Readiness and service checks pass?"}
F["Complete promotion"]
G["Stop rollout and recover"]
A --> B
B --> C
C --> D
D --> E
E -->|yes| F
E -->|no| G

I would model checkout as a recoverable business workflow with authoritative server validation and clear states. A browser success message must correspond to a known durable outcome, not merely a completed click handler.

1. Define order and reservation states, authoritative pricing, inventory rules, authentication, acceptable payment delay, and the client’s retry and status-check behavior.
2. Validate the request and idempotency key, then atomically create appropriate local order and inventory state without trusting client-supplied totals.
3. Coordinate payment and other external effects through durable steps, verifying callbacks and deduplicating repeated messages before changing the order state.
4. Expose a stable order-status contract, reconcile uncertain external outcomes, release expired reservations, and monitor the entire path from request to final result.

flowchart TD
A["Frontend submits identified checkout"]
B["Validate access price and stock"]
C["Commit pending order and reservation"]
D["Request external payment safely"]
E{"Payment outcome known?"}
F["Finalize or cancel order"]
G["Reconcile pending outcome"]
H["Frontend displays authoritative status"]
A --> B
B --> C
C --> D
D --> E
E -->|yes| F
E -->|no| G
F --> H
G --> H

Trade-offs:

• Reservations support a multi-step workflow but require expiry and compensation policies to avoid indefinitely holding stock.
• Immediate user feedback can show a pending state honestly while recovery establishes whether the external action succeeded.

The choice depends on update direction, frequency, latency, and operational requirements. A persistent connection adds lifecycle concerns that an occasional status request may not need.

When to use which:

• Use polling when updates are infrequent enough that simple requests meet freshness requirements without excessive traffic or overlapping calls.
• Use server-sent events when the server mainly pushes text events and the application can define reconnection, event identity, and replay behavior.
• Use WebSockets when frequent bidirectional messages justify a persistent protocol, with explicit authentication, message validation, heartbeat, and backpressure policies.

Automatic reconnection does not guarantee that no updates are missed or duplicated. Preserve resumable event positions or provide a fresh-state reconciliation path when correctness requires it.

I would estimate steady-state connection occupancy from throughput and the average total time each request holds a connection. This is a starting measurement model, not a complete pool-sizing rule.

• Formula: average occupied connections = requests per second × average connection-hold seconds per request, assuming stable flow and consistently measured work.
• Scope: include the total connection time across all relevant database operations, and distinguish one application instance from the combined deployment.
• Variability: bursts, slow queries, long transactions, background jobs, and tail latency can require capacity beyond the average, but the database still sets a sustainable limit.
• Verification: load-test a bounded pool while measuring queueing, acquisition timeouts, database utilization, and end-to-end latency before choosing the operating configuration.

Increasing the pool can increase contention rather than improve throughput. Reduce unnecessary connection hold time when it is the source of demand.

Cache-Control defines how a representation may be stored and reused. An ETag identifies a version of a representation so a client can ask whether its stored copy is still valid.

• Freshness: directives such as max-age define permitted fresh reuse, while private and related rules affect which caches may store a response.
• Revalidation: no-cache allows storage but requires validation before reuse; it does not mean the same thing as no-store, which instructs caches not to store the response.
• Conditional requests: a client can send If-None-Match with an ETag, and a matching authorized retrieval can receive a 304 response instead of another complete representation.
• Correct variants: vary cache entries by the relevant representation inputs and avoid sharing personalized responses across users or tenants.

Caching does not replace authorization. Validate access and use appropriate policies for sensitive content even when the representation has not changed.

I would compare the actual browser request and response with the successful direct request. Browser security, credentials, routing, and response handling can differ even when the backend business logic is correct.

1. Inspect the network request, final target, method, headers, credentials, redirect chain, status, and response content rather than relying only on the UI error message.
2. Check browser enforcement such as cross-origin rules, mixed-content restrictions, cookie policy, and content security policy, including any failed preflight.
3. Compare proxy paths, environment configuration, authentication, payload shape, and content type with the working request, tracing the same correlation identifier on the server.
4. Fix the precise contract or configuration issue and test allowed and denied cases, preserving the intended security boundary instead of disabling it broadly.

flowchart TD
A["Capture browser network evidence"]
B{"Request reaches intended endpoint?"}
C["Inspect response and credentials"]
D["Inspect routing and browser restrictions"]
E["Compare with successful direct request"]
F["Correct specific mismatch"]
G["Test allowed and rejected behavior"]
A --> B
B -->|yes| C
B -->|no| D
C --> E
D --> E
E --> F
F --> G

Trade-offs:

• Permissive security settings can hide the symptom while exposing data or actions to unintended origins.
• A frontend parsing error may come from a proxy’s HTML login page rather than malformed JSON produced by the intended API.

Use a real feature or project to show how you connected user needs, backend behavior, data, and operational delivery. Clearly distinguish your contribution from the work of the wider team.

1. State the user problem, major requirements, constraints, and your responsibility, using measured scale or performance figures only when you can explain their source.
2. Trace one important user action through the frontend, API, business service, and database, identifying validation, permissions, and transaction boundaries.
3. Explain a meaningful design trade-off and the evidence that influenced it, such as responsiveness, consistency, maintainability, or deployment risk.
4. Describe how you tested the feature and resolved a real failure, including what happened at integration boundaries rather than only within one class.
5. Report the actual outcome and a specific improvement you would make next, acknowledging limitations honestly.

What the interviewer is listening for: ownership, cross-layer reasoning, practical judgment, clear communication, and credible evidence of delivered behavior.

Describe a real situation in terms of impact, evidence, decisions, and learning. The goal is to demonstrate accountable problem-solving rather than to assign blame or present every decision as perfect.

1. Explain the context, affected users, and initial uncertainty, separating confirmed observations from the hypotheses the team first considered.
2. State your responsibility and how you helped contain the impact, communicate progress, or frame the competing technical options fairly.
3. Describe the logs, tests, experiments, or measurements used to decide what was happening and which correction or design choice was justified.
4. Explain the outcome and its validation, including any rollback, data repair, unresolved limitation, or conclusion that changed your original view.
5. Describe the follow-up improvement and how the team assessed whether it reduced the chance or impact of a similar problem.

What the interviewer is listening for: calm investigation, collaboration, honest ownership, willingness to revise assumptions, and follow-through after the immediate issue is resolved.