Quick Technical Screening — Senior Full Stack Developer

These questions are designed to quickly distinguish senior-level engineers from mid-level candidates.

The expected response should not be just “Yes”. A strong senior candidate should briefly explain:

1. Where they used the technology or technique.
2. Why they chose it.
3. How they implemented it.
4. What trade-offs they considered.
5. What measurable result or improvement was achieved.

Senior Interview Response Pattern

flowchart LR
    A[Question] --> B{Have you used it?}
    B -->|No| C[Be honest]
    B -->|Yes| D[Give concrete example]
    D --> E[Explain implementation]
    E --> F[Discuss trade-offs]
    F --> G[Explain outcome / metrics]

A good screening pattern is:

Yes. I’ve used it in [specific situation]. The approach was [technical implementation], which helped achieve [result].

---

1. React

1. Have you used React.memo?

Strong answer:

Yes. I use React.memo when a component receives the same props frequently and unnecessary re-renders affect performance. I typically combine it with useMemo and useCallback where appropriate.

Follow-up questions:

• When can React.memo actually hurt performance?
• How does shallow comparison work?
• When would you avoid using it?

---

2. Have you implemented code splitting?

Strong answer:

Yes. I use route-level and component-level code splitting to reduce the initial JavaScript bundle. This allows users to download only the code required for the current page.

Follow-up questions:

• How do you identify what should be split?
• What is the difference between code splitting and lazy loading?
• How does code splitting affect initial page load?

---

3. Have you used lazy loading?

Strong answer:

Yes. In React, I use React.lazy() with Suspense for routes and heavy components that aren’t required immediately.

const Reports = React.lazy(() => import("./Reports"));

This helps reduce the initial bundle size.

---

4. Have you implemented server-side rendering?

Strong answer:

Yes, I’ve worked with SSR concepts where the initial HTML is generated on the server and hydrated on the client. SSR can improve initial rendering and SEO, although it introduces additional server-side complexity.

Follow-up questions:

• SSR vs CSR?
• SSR vs SSG?
• What happens during hydration?
• What are common hydration issues?

---

5. Have you used Redux Toolkit?

Strong answer:

Yes. I use Redux Toolkit for centralized client-side state when the application has complex shared state requirements. I use slices, reducers, selectors, and async thunks where appropriate.

I avoid Redux for simple local component state.

---

6. Have you used React Query?

Strong answer:

Yes. I use React Query for server-state management, including:

• API caching
• Background refetching
• Request deduplication
• Retry handling
• Cache invalidation
• Loading and error states

It avoids unnecessarily putting server state into Redux.

---

7. Have you implemented virtualized lists?

Strong answer:

Yes. For very large datasets, I use list virtualization so that only the visible rows are rendered instead of creating thousands of DOM elements.

This significantly reduces DOM size and improves scrolling performance.

---

2. Performance

8. Have you used Promise.all() for parallel API calls?

Strong answer:

Yes. When API calls are independent, I use Promise.all() to execute them concurrently instead of waiting for each request sequentially.

const [users, orders, products] = await Promise.all([
  fetchUsers(),
  fetchOrders(),
  fetchProducts()
]);

This can significantly reduce overall response time.

Follow-up questions:

• What happens if one promise fails?
• When would you use Promise.allSettled() instead?

---

9. Have you used Web Workers?

Strong answer:

Yes. Web Workers are useful for CPU-intensive operations that could block the browser’s main thread.

Examples include:

• Large data processing
• Complex calculations
• Parsing large files
• Image/data processing

The goal is to keep the UI responsive.

---

10. Have you performed bundle analysis?

Strong answer:

Yes. I analyze the production bundle to identify:

• Large dependencies
• Duplicate dependencies
• Unused code
• Poor tree shaking
• Opportunities for code splitting

For Vite or Webpack applications, bundle analyzer tools can help identify the biggest contributors to bundle size.

---

11. Have you implemented caching strategies?

Strong answer:

Yes. I use caching at different layers depending on the requirement:

• Browser caching
• HTTP caching
• CDN caching
• React Query caching
• Redis caching
• Database caching where appropriate

The important part is defining TTL, invalidation, consistency, and cache eviction rather than simply adding a cache.

flowchart TD
    A[User Request] --> B[Browser Cache]
    B -->|Miss| C[CDN / HTTP Cache]
    C -->|Miss| D[Application]
    D --> E[React Query / Client Cache]
    D --> F[Redis]
    F -->|Miss| G[Database]

---

3. Security

12. Have you mitigated an XSS vulnerability?

Strong answer:

Yes. I prevent XSS by avoiding unsafe HTML rendering, validating and sanitizing untrusted input where required, encoding output, and carefully controlling APIs such as dangerouslySetInnerHTML.

I also use appropriate security headers such as CSP.

Follow-up questions:

• Stored XSS vs reflected XSS?
• DOM-based XSS?
• How does CSP help?

---

13. Have you implemented CSP headers?

Strong answer:

Yes. Content Security Policy restricts where scripts, styles, images, and other resources can be loaded from.

A properly configured CSP can significantly reduce the impact of XSS attacks.

---

14. Have you implemented OAuth2?

Strong answer:

Yes. I’ve worked with OAuth2/OIDC concepts including:

• Authorization flows
• Access tokens
• Refresh tokens
• Scopes
• Resource servers
• Role-based authorization

For enterprise applications, I also consider token expiry, secure storage, logout, and refresh-token handling.

sequenceDiagram
    participant U as User
    participant C as Client
    participant A as Authorization Server
    participant R as Resource API

    U->>C: Login
    C->>A: Authorization request
    A->>C: Authorization code
    C->>A: Exchange code for tokens
    A->>C: Access + refresh token
    C->>R: API request + access token
    R->>C: Protected resource

---

15. Have you handled PCI-sensitive data?

Strong answer:

Yes, where applicable. Sensitive payment information should not be unnecessarily stored or logged. I prefer using payment-provider tokenization so that the application handles tokens rather than raw card information.

The goal is also to minimize the application’s PCI compliance scope.

---

16. Have you conducted security reviews?

Strong answer:

Yes. During security reviews, I typically check:

• Authentication
• Authorization
• Input validation
• API security
• Secrets management
• Dependency vulnerabilities
• Sensitive-data exposure
• Logging
• OWASP vulnerabilities
• Security headers

---

4. Java

17. Have you optimized JVM memory settings?

Strong answer:

Yes. I first analyze heap usage, garbage-collection behavior, allocation rates, and pause times before changing JVM parameters.

I avoid blindly increasing -Xmx; the correct tuning depends on workload, container limits, heap requirements, and GC behavior.

Follow-up questions:

• Heap vs stack?
• Young generation vs old generation?
• How would you investigate OutOfMemoryError?
• How would you identify a memory leak?

flowchart TD
    A[High Memory Usage] --> B[Check JVM Metrics]
    B --> C[Heap Usage]
    B --> D[GC Activity]
    B --> E[Thread / Native Memory]
    C --> F[Heap Dump]
    D --> G[GC Logs]
    E --> H[Thread Dump / Native Analysis]
    F --> I[Identify Retained Objects]
    G --> J[Identify GC Pressure]
    H --> K[Identify Resource Issues]
    I --> L[Root Cause]
    J --> L
    K --> L

---

18. Have you implemented caching using Redis?

Strong answer:

Yes. I’ve used Redis for frequently accessed data using patterns such as cache-aside.

Important considerations include:

• TTL
• Cache invalidation
• Cache consistency
• Serialization
• Eviction policies
• Cache stampede prevention

---

19. Have you used Kafka?

Strong answer:

Yes. I’ve worked with Kafka producers and consumers, partitions, consumer groups, offsets, retries, idempotency, and dead-letter handling.

At senior level, I also consider:

• Partition strategy
• Ordering guarantees
• Consumer lag
• Delivery semantics
• Failure recovery
• Message duplication

flowchart LR
    P1[Producer] --> T[Kafka Topic]
    T --> P[Partition 0]
    T --> Q[Partition 1]
    T --> R[Partition 2]

    P --> C1[Consumer Group A]
    Q --> C2[Consumer Group A]
    R --> C3[Consumer Group A]

    T --> D1[Consumer Group B]
    D1 --> D2[Independent Processing]

---

20. Have you built microservices?

Strong answer:

Yes. I’ve worked with Spring Boot-based microservices using REST APIs, API Gateway, service discovery, centralized configuration, resilience patterns, Docker/Kubernetes, and observability.

I also consider distributed-system concerns such as:

• Service failures
• Distributed transactions
• Event-driven communication
• Idempotency
• Retry strategies
• Circuit breakers
• Distributed tracing

flowchart LR
    U[Client] --> G[API Gateway]

    G --> A[User Service]
    G --> O[Order Service]
    G --> P[Payment Service]

    O --> K[Kafka]
    K --> N[Notification Service]

    A --> DB1[(User DB)]
    O --> DB2[(Order DB)]
    P --> DB3[(Payment DB)]

    A --> R[(Redis)]
    O --> R

    A --> M[Monitoring]
    O --> M
    P --> M

---

21. Have you performed thread dump analysis?

Strong answer:

Yes. I use thread dumps to identify:

• Blocked threads
• Deadlocks
• Thread contention
• CPU-intensive threads
• Thread-pool exhaustion
• Long-running operations

I correlate thread dumps with application metrics and JVM monitoring to identify the actual bottleneck.

flowchart TD
    A[Production Performance Issue] --> B[Capture Thread Dump]
    B --> C{Thread State}
    C -->|RUNNABLE| D[Check CPU / Hot Methods]
    C -->|BLOCKED| E[Check Lock Contention]
    C -->|WAITING| F[Check Dependencies / Pools]
    C -->|TIMED_WAITING| G[Check Timeouts / Sleeps]
    E --> H[Deadlock Analysis]
    F --> I[Thread Pool / External Dependency]
    D --> J[Root Cause]
    G --> J
    H --> J
    I --> J

---

5. Database

22. Have you optimized slow SQL queries?

Strong answer:

Yes. I first identify the slow query and analyze its execution characteristics.

I then investigate:

• Index usage
• Joins
• Filtering
• Cardinality
• Full table scans
• Sorting
• Pagination
• Locking
• Query design

I don’t immediately add an index without understanding the execution plan.

---

23. Have you analyzed execution plans?

Strong answer:

Yes. I use EXPLAIN or EXPLAIN ANALYZE to identify:

• Full table scans
• Incorrect index usage
• Expensive joins
• High row counts
• Sorting operations
• Poor cardinality estimates

The execution plan helps determine whether the issue is with the query, indexes, schema design, or data distribution.

flowchart TD
    A[Slow SQL Query] --> B[EXPLAIN / EXPLAIN ANALYZE]
    B --> C{Problem Identified}
    C --> D[Full Table Scan]
    C --> E[Poor Index]
    C --> F[Expensive Join]
    C --> G[Large Sort]
    C --> H[High Cardinality / Bad Estimate]

    D --> I[Review Indexes / Query]
    E --> I
    F --> J[Rewrite Join / Add Index]
    G --> K[Review ORDER BY / Index]
    H --> L[Review Statistics / Data Model]

    I --> M[Retest]
    J --> M
    K --> M
    L --> M

---

24. Have you resolved database deadlocks?

Strong answer:

Yes. I analyze the database deadlock information to identify which transactions are competing for locks.

Typical solutions include:

• Reducing transaction scope
• Keeping transactions short
• Consistent lock ordering
• Avoiding unnecessary database locks
• Optimizing queries
• Retrying transient failures where appropriate

sequenceDiagram
    participant T1 as Transaction A
    participant DB as Database
    participant T2 as Transaction B

    T1->>DB: Lock Row A
    T2->>DB: Lock Row B
    T1->>DB: Request Row B
    T2->>DB: Request Row A
    DB-->>T1: Waiting
    DB-->>T2: Waiting
    DB->>T1: Deadlock detected
    T1->>DB: Rollback
    T2->>DB: Continue

---

25. Have you optimized Hibernate performance?

Strong answer:

Yes. Common Hibernate performance problems I’ve handled include:

• N+1 queries
• Incorrect fetch strategies
• Excessive eager loading
• Large result sets
• Missing indexes
• Unnecessary entity loading
• Inefficient pagination

I use techniques such as fetch joins, entity graphs, batch fetching, projections, pagination, and proper transaction boundaries.

flowchart TD
    A[Hibernate Performance Issue] --> B{Problem Type}
    B --> C[N+1 Query]
    B --> D[Large Result Set]
    B --> E[Incorrect Fetch Strategy]
    B --> F[Slow SQL]
    B --> G[Excessive Entity Loading]

    C --> H[Fetch Join / Entity Graph]
    D --> I[Pagination / Projection]
    E --> J[Review Lazy / Eager Loading]
    F --> K[SQL + Execution Plan]
    G --> L[DTO Projection / Selective Fetch]

    H --> M[Measure Again]
    I --> M
    J --> M
    K --> M
    L --> M

---

6. Senior-Level Evaluation Guide

The purpose of these questions is not to count the number of “Yes” answers.

A senior engineer should demonstrate depth of experience and problem-solving ability.

Mid-Level Response

“Yes, I’ve used Redis.”

This confirms familiarity but doesn’t demonstrate much depth.

Senior Response

“Yes. We used Redis as a cache-aside layer for frequently accessed reference data. We configured TTLs and explicit invalidation after updates. We also had to handle cache stampedes and stale data, so we added appropriate locking/retry behavior.”

This demonstrates implementation knowledge and awareness of production problems.

Strong Lead-Level Response

“Yes. We used Redis for high-read reference data. Initially we saw inconsistent data because invalidation wasn’t synchronized with database updates. I changed the design to invalidate after successful persistence and added TTL as a safety mechanism. We also monitored hit ratio and latency to verify the improvement.”

This demonstrates:

• Problem identification
• Root-cause analysis
• Design decision
• Implementation
• Trade-off awareness
• Observability
• Measurable outcome

---

7. What Interviewers Should Look For

A strong senior candidate should naturally discuss:

• Trade-offs
• Failure scenarios
• Performance impact
• Security implications
• Scalability
• Observability
• Maintainability
• Production experience
• Root-cause analysis
• Metrics and measurable outcomes

The strongest signal is when the candidate can explain:

flowchart LR
    A[Production Problem] --> B[Investigation]
    B --> C[Root Cause]
    C --> D[Technical Decision]
    D --> E[Implementation]
    E --> F[Trade-offs]
    F --> G[Measurement]
    G --> H[Result]

Recommended Answer Structure

Use this structure for almost every senior-level screening question:

1. Situation

Explain the production or project context.

2. Problem

Explain what needed to be solved.

3. Investigation

Explain how you diagnosed the problem.

4. Decision

Explain why you selected a particular solution.

5. Implementation

Explain the important technical details.

6. Trade-offs

Explain what you gained and what complexity you introduced.

7. Result

Give measurable outcomes wherever possible.

---

8. Quick Screening Matrix

Area	Screening Topics	Senior-Level Signal
React	React.memo, lazy loading, code splitting	Rendering and bundle optimization
React State	Redux Toolkit, React Query	Client state vs server state
Large Data	Virtualized lists	DOM and rendering optimization
Performance	Promise.all, Web Workers	Parallelism and main-thread management
Frontend Performance	Bundle analysis, caching	Measurement-driven optimization
Security	XSS, CSP	Defense-in-depth
Authentication	OAuth2/OIDC	Secure authentication and authorization
Payments	PCI	Data minimization and tokenization
JVM	Memory tuning	Metrics-driven JVM optimization
Caching	Redis	TTL, invalidation, consistency
Messaging	Kafka	Partitions, ordering, delivery semantics
Architecture	Microservices	Distributed-system trade-offs
JVM Diagnostics	Thread dumps	Concurrency and production troubleshooting
SQL	Slow queries	Query and index optimization
Database	Execution plans	Evidence-based tuning
Transactions	Deadlocks	Lock analysis and transaction design
ORM	Hibernate	N+1, fetch strategies, batching

---

9. Final Senior-Level Checklist

Before considering a candidate senior-level, verify that they can explain not only what technology they used, but also why, how, and what happened in production.

• Can explain technical decisions clearly
• Can discuss trade-offs
• Can diagnose production issues
• Can explain performance bottlenecks
• Understands security implications
• Understands distributed-system failure modes
• Can explain database optimization
• Understands JVM behavior
• Can distinguish client state from server state
• Can discuss observability and metrics
• Can provide concrete production examples
• Can quantify improvements where possible
• Can explain what they would do differently today

---

10. Key Interview Principle

Don’t evaluate seniority by the number of technologies a candidate knows. Evaluate it by the depth of reasoning behind the technologies they have used.

A senior engineer should be able to move from:

“I’ve used it”

to:

“Here’s the problem, here’s how I investigated it, here’s why I selected this approach, here are the trade-offs, and here’s the measurable production result.”