Infosys Java DeveloperInterview Questions 2026

Expert answer: In Java, `==` checks whether two references point to the same object in memory, while `.equals()` checks logical equality of content when overridden correctly. For strings and value objects, `.equals()` is usually the right choice. I always connect this with hashCode contract: equal objects must have equal hash codes, especially for HashMap/HashSet correctness. In interviews, I show one example with string literals versus `new String()` to prove I understand both reference and value comparisons.

What interviewers evaluate: Whether you understand reference vs value equality — a daily Java trap in collections and String comparisons.

Answer strategy: Define `==` first, then `.equals()` and the equals/hashCode contract; give String pool vs `new String` example.

Common mistakes: Using `==` on wrapper objects expecting value match, or overriding equals without hashCode.

Expert answer: Java 8 introduced lambda expressions, Stream API, functional interfaces, Optional, default/static interface methods, modern date-time API (`java.time`), and CompletableFuture. In interviews, I lead with business value: Streams improve readable data transformations, lambdas reduce boilerplate, and `java.time` fixes old Date/Calendar pain points. I also mention practical caution: streams are expressive but not always faster for every case, so clarity and profiling should guide usage in production systems.

What interviewers evaluate: Modern Java fluency — panels expect Stream/lambda awareness even for fresher Infosys Java roles.

Answer strategy: List 4–5 features with one-line purpose each; demonstrate a simple Stream filter/map example.

Common mistakes: Naming Java 7 features as Java 8, or unable to write a basic lambda.

Expert answer: ArrayList stores elements in a dynamic array, so random access is O(1) and usually cache-friendly. LinkedList stores nodes with pointers, making indexed access O(n) but insertions at known node positions efficient. In most production code, ArrayList is the default because reads dominate and memory locality helps performance. I choose LinkedList only for specific queue/deque patterns with frequent head/tail operations. Interviewers expect this practical bias, not theoretical claims that LinkedList is generally faster.

What interviewers evaluate: Collection selection judgment and Big-O reasoning — not memorized definitions alone.

Answer strategy: Compare access, insert, delete complexity; state default choice (ArrayList) and one valid LinkedList use case.

Common mistakes: Claiming LinkedList is faster for everything, or using LinkedList as a general-purpose list.

Expert answer: Checked exceptions are enforced by compiler and represent recoverable scenarios, such as I/O or SQL failures. Unchecked exceptions are RuntimeException subclasses and often represent programming bugs or invalid assumptions. I use checked exceptions where callers can reasonably recover; otherwise I propagate meaningful unchecked exceptions for invalid states. I avoid catch-all blocks and always log with context. A strong answer also mentions try-with-resources and preserving original stack traces when wrapping exceptions across service boundaries.

What interviewers evaluate: Exception hierarchy literacy and practical error-handling judgment in service code.

Answer strategy: Draw Throwable → Error | Exception → RuntimeException; give one checked and one unchecked example with handling approach.

Common mistakes: Catching Exception broadly, swallowing stack traces, or confusing Error with recoverable Exception.

Expert answer: SOLID improves maintainability in growing Java systems. SRP: split `UserService` and `EmailService` responsibilities. OCP: add new pricing strategy via interface implementation, not modifying old logic. LSP: `Square` should not break `Rectangle` expectations. ISP: separate bulky `Worker` into focused interfaces. DIP: controllers depend on repository interfaces, not concrete classes. In interviews, I tie each principle to testability and change safety because that is what matters in real enterprise delivery.

What interviewers evaluate: OOP design maturity — Infosys panels probe whether you apply principles in real projects.

Answer strategy: One sentence per principle plus a micro Java example showing violation vs fix.

Common mistakes: Mixing up Liskov and Interface Segregation, or textbook recitation with no code example.

Expert answer: Multithreading lets multiple execution paths run concurrently in one process. `synchronized` provides mutual exclusion and memory visibility for critical sections, useful when compound operations must be atomic. `volatile` guarantees visibility of latest value across threads but does not make multi-step updates atomic. I use volatile for status flags and synchronized/locks for shared mutable state updates. In interviews, I also mention higher-level tools like ExecutorService and concurrent collections for safer production concurrency patterns.

What interviewers evaluate: Concurrency fundamentals and whether you know limits of volatile vs synchronized.

Answer strategy: Define thread, then synchronized block/method, then volatile visibility — state when each is insufficient alone.

Common mistakes: Claiming volatile makes i++ atomic, or deadlocks from nested synchronized locks without mentioning ordering.

Expert answer: Spring Boot auto-configuration uses classpath and environment conditions to create sensible default beans automatically. `@SpringBootApplication` includes `@EnableAutoConfiguration`, which loads configuration classes from starter metadata and applies them when conditions like `@ConditionalOnClass` match. This reduces manual wiring while staying override-friendly through custom beans and properties. In interviews, I explain both convenience and control: defaults speed setup, but understanding conditional loading helps debug unexpected bean behavior in larger applications.

What interviewers evaluate: Spring Boot depth beyond annotations — whether you understand convention-over-configuration mechanics.

Answer strategy: Trace @SpringBootApplication → @EnableAutoConfiguration → conditional @Configuration beans via starters.

Common mistakes: Saying “Spring Boot configures everything automatically” with no mention of conditions or starters.

Expert answer: I built a placement-prep backend with layered architecture: controllers, services, repositories, and DTO boundaries. The key decision I am proud of was introducing centralized exception handling and validation so API responses stayed consistent across modules. I also separated persistence entities from response DTOs to avoid tight coupling and accidental data leaks. This reduced bug leakage and made onboarding easier for teammates. In interviews, I present design choices with the specific problem each decision solved and measurable maintenance impact.

What interviewers evaluate: Project ownership and architectural reasoning — Infosys HM/tech panels probe resume claims deeply.

Answer strategy: STAR format: problem → options considered → decision (layer/DTO/validation) → measurable outcome.

Common mistakes: Vague “we used Spring Boot best practices” with no specific trade-off or personal contribution.

Expert answer: I first stabilize service impact with traffic controls, safe restart strategy, and immediate visibility into memory metrics. Then I capture heap dump and GC logs, analyze retained objects in tools like MAT, and identify leak patterns such as unbounded caches or oversized in-memory collections. I avoid only increasing heap without root-cause fix. After patching, I run load tests and add alerts on heap usage and GC pause behavior. This incident flow demonstrates both operational safety and debugging discipline.

What interviewers evaluate: Production debugging maturity — structured triage vs panic tuning.

Answer strategy: Stabilize (heap dump, restart) → analyze retained objects → identify leak pattern → fix and validate under load.

Common mistakes: Only increasing -Xmx without root-cause analysis, or ignoring GC logs and heap dump evidence.

Expert answer: Garbage collection automatically reclaims heap memory of unreachable objects. Generational GC is based on the observation that most objects die young, so JVM separates Young and Old generations. Minor GCs clean young space frequently and quickly, while major/old collection is heavier. Modern collectors like G1 partition heap for predictable pauses. In interviews, I connect this to practical outcomes: latency spikes, allocation patterns, and why reducing object churn often improves performance without touching GC flags first.

What interviewers evaluate: JVM memory model awareness — connects to performance and OOM troubleshooting questions.

Answer strategy: Explain why generational hypothesis holds, walk Eden → Survivor → Old Gen, name G1GC as modern default.

Common mistakes: Calling System.gc() as a fix, or unable to distinguish minor vs major GC impact.

Expert answer: HashMap is non-synchronized and generally faster in single-threaded usage; it allows one null key and multiple null values. HashTable is synchronized, legacy, and does not allow null key/value. For concurrent scenarios, I prefer ConcurrentHashMap rather than HashTable because it offers better throughput with finer-grained concurrency controls. Interviewers usually expect this recommendation and collision/load-factor awareness. I also mention that map choice should be driven by threading model and performance profile, not old defaults.

What interviewers evaluate: Map implementation trade-offs and thread-safety awareness at collection layer.

Answer strategy: Compare sync behaviour, null key policy, and performance; recommend ConcurrentHashMap for concurrent access.

Common mistakes: Using HashTable “because it is thread-safe” without noting performance cost, or ignoring ConcurrentHashMap.

Expert answer: For high-throughput, low-latency core backend paths, I would typically choose Java because JVM JIT optimization, mature concurrency primitives, and predictable long-running service performance are strong advantages. Python can still be excellent for rapid iteration, data-heavy workflows, and I/O-bound APIs with async frameworks. So I choose by workload and team context: Java for latency-critical compute and strongly typed large systems; Python when developer velocity and ecosystem fit are higher priorities.

What interviewers evaluate: Technology trade-off reasoning — not language loyalty or one-word answers.

Answer strategy: Define workload (CPU-bound vs I/O-bound), then match Java JVM/concurrency strengths or Python async fit.

Common mistakes: Declaring Java always wins, or ignoring GIL/async distinctions for I/O-heavy services.