Infosys Java Developer Interview Experience — 3

Interview of a candidate with 7+ years of Experience

If you are not a paid member of Medium, please use my friend link to read the entire article: Friend Link

One of my followers, recently, appeared for the Infosys interview for Java Lead role.

For context, he has over 7 years of experience in Java, SQL, Spring Boot, Microservices, and related technologies.

I’ll break this down in 2 parts:

1. Interview Process
2. Interview Questions

This is how it went:

1. Interview Process:

The process was smooth and as follows:

• He got an email from Infosys Talent Acquisition team regarding hiring in Infosys.
• He shared the requested details in a survey form.
• After sharing the details, the first technical round was setup.

On the day of the interview:

• The interviewer joined the call on time.
• They exchanged pleasantries and got straight into technical questions.
• The interviewer were professional and courteous throughout.

2. Interview Questions:

Below are some of the technical questions he was asked. I’ve merged similar questions and follow-up queries for clarity.

I’ll include textbook explanations for all the answers to help anyone preparing for interviews.

Q1. Explain Singleton class. How to create a Singleton class?

This question was also asked in EPAM Interview (Question 4). So, this is an important question.

I have already written a detailed article on Singleton classes. Request you to please go through the same:

[embed]Singleton Design Pattern A Deep Divemedium.com

Q2. What do you mean by Scaling?

In software architecture, scaling means increasing the system’s capacity to handle higher loads — whether that’s more users, more data, or more requests — without compromising performance or reliability.

There are two types of scaling:

1. Vertical Scaling (Scaling Up):

You increase the capacity of a single machine — for example, adding more CPU, RAM, or SSD storage.

It’s the easiest to implement but has physical and cost limitations.

Example scenario: You have a monolithic Java application running on a single EC2 instance. When traffic increases, you move it to a more powerful instance.

Pros:

• Simple to implement (no code changes)
• Works well for small-scale systems

Cons:

• Limited by hardware
• Expensive and not fault-tolerant

Example: Using a larger thread pool to utilize more resources on a single server.

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class VerticalScalingExample {
    public static void main(String[] args) {
        // Increase thread count to handle more concurrent tasks
        ExecutorService executor = Executors.newFixedThreadPool(20);
        for (int i = 0; i < 100; i++) {
            executor.submit(() -> {
                System.out.println(Thread.currentThread().getName() + " is processing request...");
            });
        }
        executor.shutdown();
    }
}

Here, scaling up means we’re using a bigger machine that can handle a larger thread pool.

2. Horizontal Scaling (Scaling Out):

Instead of upgrading one machine, you add more machines (nodes) and distribute the load among them.

This is the preferred approach for large-scale systems and microservices architectures.

Pros:

• Highly scalable
• Fault-tolerant
• Cost-effective with cloud-based auto-scaling

Cons:

• Complex to manage
• Requires load balancing and distributed caching

Example: Scaling out a stateless microservice using multiple instances behind a load balancer.

// Example using Spring Boot
@RestController
public class OrderController {

@GetMapping("/orders")
    public String getOrders() {
        String instanceId = System.getenv("HOSTNAME"); // Each instance has a unique ID
        return "Orders served by instance: " + instanceId;
    }
}

When multiple instances of this service are deployed, a load balancer (like Nginx or AWS ALB) distributes incoming requests among them.

Q3. What is Database Partitioning?

Database partitioning is the process of dividing a large database table into smaller, more manageable pieces called partitions, while still treating them as a single table.

Partitioning improves performance, manageability, and scalability, especially for very large tables.

Partitioning can help:

• Speed up queries by scanning only relevant partitions.
• Improve maintenance (backup, restore, indexing).
• Enable horizontal scaling of the database.

Types of Partitioning:

1. Horizontal Partitioning (Sharding):

• Each partition contains a subset of rows from the table.
• Rows are distributed based on a partition key (e.g., user_id, region).
• Common in distributed databases.

Example: Suppose we have a users table with millions of rows. We can partition by region:

CREATE TABLE users (
    user_id INT,
    name VARCHAR(50),
    region VARCHAR(20),
    PRIMARY KEY(user_id, region)
)
PARTITION BY LIST(region) (
    PARTITION p_north VALUES IN ('North'),
    PARTITION p_south VALUES IN ('South'),
    PARTITION p_east  VALUES IN ('East'),
    PARTITION p_west  VALUES IN ('West')
);

• Queries like SELECT * FROM users WHERE region='North'; only scan p_north.

2. Vertical Partitioning:

• Each partition contains a subset of columns instead of rows.
• Useful when certain columns are accessed more frequently than others.

Example: Split users table into two tables:

-- Frequent accessed info
CREATE TABLE users_basic (
    user_id INT PRIMARY KEY,
    name VARCHAR(50),
    email VARCHAR(50)
);

-- Less frequently accessed info
CREATE TABLE users_profile (
    user_id INT PRIMARY KEY,
    address VARCHAR(100),
    date_of_birth DATE
);

• users_basic is small and fast to query frequently used data.
• users_profile is only accessed when needed.

3. Range Partitioning:

• Rows are partitioned based on a range of values in a column.

CREATE TABLE orders (
    order_id INT,
    order_date DATE,
    customer_id INT
)
PARTITION BY RANGE (YEAR(order_date)) (
    PARTITION p_2023 VALUES LESS THAN (2024),
    PARTITION p_2024 VALUES LESS THAN (2025)
);

• Queries for a specific year only scan the relevant partition.

Why Partitioning is Useful:

• Reduces query execution time by scanning fewer rows.
• Helps maintain large tables efficiently (backup, archiving, indexing).
• Enables parallel processing in large-scale systems.

Q4. What are the differences between REST vs gRPC vs Kafka?

Q5. What is Caching? Why is it used?

Caching is the process of storing frequently accessed data in a temporary storage (cache) so that future requests can be served faster without repeatedly fetching the data from the original source (like a database or API).

Why caching is used:

1. Improves performance — reduces response time by avoiding repeated expensive operations.
2. Reduces load — lowers database or backend system usage.
3. Enhances scalability — handles more requests efficiently.
4. Provides faster user experience — especially for read-heavy applications.

Types of Caching:

1. In-Memory Caching — Stored in the application memory.

• Examples: Java HashMap, ConcurrentHashMap, Ehcache, Caffeine

// Simple in-memory cache using ConcurrentHashMap
import java.util.concurrent.ConcurrentHashMap;

public class UserCache {
    private static ConcurrentHashMap<Integer, String> cache = new ConcurrentHashMap<>();
    public static String getUser(int userId) {
        return cache.get(userId);
    }
    public static void putUser(int userId, String name) {
        cache.put(userId, name);
    }
    public static void main(String[] args) {
        putUser(101, "Shivam");
        System.out.println(getUser(101)); // Fast retrieval from cache
    }
}

2. Distributed Caching — Stored outside the application, shared across multiple servers.

• Examples: Redis, Memcached
• Used in microservices or clustered environments.

// Using Redis with Jedis (Java client)
Jedis jedis = new Jedis("localhost");
jedis.set("user:101", "Shivam");
String name = jedis.get("user:101"); // Fast retrieval

When to Use Caching:

• Frequently accessed data (like user profiles, product catalog).
• Expensive computations or database queries.
• Read-heavy applications where the data doesn’t change frequently.

Q6. How will you decide between SQL and NoSQL databases?

Choosing between SQL (relational) and NoSQL (non-relational) depends on data structure, consistency requirements, scalability needs, and query patterns.

We can follow the below steps:

Step 1: Understand Your Data

• SQL: Structured, relational data with fixed schema and strong relationships.
• NoSQL: Flexible, semi-structured or unstructured data, dynamic schema.

Step 2: Consider Transaction Requirements

• SQL: ACID compliance → essential for financial transactions, orders, or payments.
• NoSQL: Often eventual consistency → fine for product catalogs, logs, analytics, or session storage.

Step 3: Evaluate Scalability Needs

• SQL: Vertical scaling is easier (upgrade server), horizontal scaling is harder.
• NoSQL: Designed for horizontal scaling → handles large volumes of traffic/data efficiently.

Step 4: Analyze Query Patterns

• SQL: Complex queries, joins, aggregations → relational DB preferred.
• NoSQL: Simple lookups, fast reads/writes, hierarchical or document-based queries.

Step 5: Make the Choice (or Hybrid Approach)

• Transactional data (users, orders, payments) → SQL
• Flexible or high-volume data (product catalog, sessions, logs) → NoSQL
• Often, hybrid approach works best: SQL + NoSQL together in the same system.

Example:

• Users & Orders → MySQL/PostgreSQL (ACID, relational)
• Product Catalog → MongoDB/DynamoDB (flexible schema, scalable)
• Search & Analytics → Elasticsearch or Redis

Q7. What are the differences between SQL vs NoSQL databases?

Q8. Explain BASE.

BASE is a concept used in NoSQL databases as an alternative to the strict ACID properties of traditional relational databases.

It stands for:

• B.A. (Basically Available): The system guarantees that every request receives a response, though it might be stale or not fully up-to-date.
• S (Soft state): The state of the system may change over time, even without new input, due to eventual propagation of updates.
• E (Eventual consistency): The system may not be immediately consistent, but given enough time, all nodes will converge to a consistent state.

BASE vs ACID

Example: Social Media Feed

• A user posts a new message.
• BASE guarantees the post will eventually appear on all followers’ feeds, but some users might see slightly stale data immediately.
• This trade-off ensures high availability and scalability.

Q9. What is Database Connection Pooling? How is it implemented?

Database connection pooling is a technique where a pool of reusable database connections is maintained so that applications can reuse existing connections instead of creating a new one every time a database request is made.

Pooling improves performance, reduces overhead, and manages resources efficiently.

Why use connection pooling:

1. Reduces connection creation overhead — establishing a DB connection is expensive.
2. Improves performance — faster response for queries.
3. Limits number of connections — prevents overwhelming the database.
4. Manages resources efficiently — connections are reused and released properly.

How it works:

1. When the application starts, the pool initializes a fixed number of connections to the database.
2. When a query is executed, the application borrows a connection from the pool.
3. After the operation, the connection is returned to the pool for reuse.
4. If no free connections are available, the request waits until a connection is released.

Implementation in Java:

1. Using HikariCP (popular connection pool library)

import com.zaxxer.hikari.HikariConfig;
import com.zaxxer.hikari.HikariDataSource;

import java.sql.Connection;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
public class ConnectionPoolExample {
    public static void main(String[] args) throws Exception {
        HikariConfig config = new HikariConfig();
        config.setJdbcUrl("jdbc:mysql://localhost:3306/ecommerce");
        config.setUsername("root");
        config.setPassword("password");
        config.setMaximumPoolSize(10); // Max 10 connections
        HikariDataSource dataSource = new HikariDataSource(config);
        try (Connection conn = dataSource.getConnection()) {
            PreparedStatement ps = conn.prepareStatement("SELECT * FROM users WHERE user_id=?");
            ps.setInt(1, 101);
            ResultSet rs = ps.executeQuery();
            while (rs.next()) {
                System.out.println("User: " + rs.getString("name"));
            }
        }
        dataSource.close();
    }
}

2. Using Apache DBCP (another common library)

BasicDataSource ds = new BasicDataSource();
ds.setUrl("jdbc:mysql://localhost:3306/ecommerce");
ds.setUsername("root");
ds.setPassword("password");
ds.setMaxTotal(10);

Connection conn = ds.getConnection();
// use connection
conn.close(); // returns to the pool

Q10. How to migrate a monolithic application to a microservices application?

This question was also asked in EPAM Interview (Question 1). So, this is an important question.

When we move from a monolith to microservices, the goal is to make the system more scalable, maintainable, and independently deployable.

The key is to break it down gradually, not rewrite everything at once.

Below is a Step-by-Step Approach for the same:

1. Identify Service Boundaries:

Use Domain-Driven Design (DDD) concepts — break the monolith into business domains like:

• User Service
• Order Service
• Payment Service
• Inventory Service

Each service should handle one domain’s logic and data.

2. Extract One Module at a Time:

Initially, your monolith might look like this:

// Monolithic code example
@RestController
public class OrderController {
    @Autowired
    private PaymentService paymentService;

@PostMapping("/order")
    public String placeOrder(@RequestBody Order order) {
        paymentService.processPayment(order.getPaymentDetails());
        return "Order placed successfully!";
    }
}

Here, PaymentService is a local call within the same JVM.

Now, after converting PaymentService into a separate microservice, it becomes a REST API call:

// OrderService calling external PaymentService
@FeignClient(name = "PAYMENT-SERVICE")
public interface PaymentClient {
    @PostMapping("/payment")
    String processPayment(@RequestBody Payment payment);
}

@RestController
public class OrderController {
    @Autowired
    private PaymentClient paymentClient;
    @PostMapping("/order")
    public String placeOrder(@RequestBody Order order) {
        String response = paymentClient.processPayment(order.getPaymentDetails());
        return "Order placed: " + response;
    }
}

Using Spring Cloud OpenFeign simplifies inter-service communication.

3. Database Separation:

Initially, the monolith might share a single database. In microservices, each service should own its own schema.

• Order Service → order_db
• Payment Service → payment_db

For data consistency between services, use:

• Event-driven architecture with Kafka or RabbitMQ
• Saga pattern for distributed transactions

Example (event publishing):

kafkaTemplate.send("order-created-topic", orderEvent);

4. Add Supporting Infrastructure:

Example application.yml for Eureka:

spring:
  application:
    name: ORDER-SERVICE
eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/

5. Implement Resilience:

Handle service failures using Resilience4j:

@CircuitBreaker(name = "paymentService", fallbackMethod = "fallbackPayment")
public String callPaymentService(Payment payment) {
    return paymentClient.processPayment(payment);
}
public String fallbackPayment(Payment payment, Throwable ex) {
    return "Payment service unavailable. Please try later.";
}

Challenges in Migration:

Q11. What are the differences between Single Database vs Database-per-Service approach?

Final Thoughts:

The interview was pretty straight forward and very much in line with what you would expect from Infosys.

Candidate cleared this round and then an offline Techno-Managerial round was setup, where the candidate was asked about technical use cases related to his project.

After clearing that, an offline HR round was scheduled.

If you or someone you know recently had an interview or if you’d like me to explain any topic, feel free to reach out to me via email. I’ll write an detailed article on the same.

If you need help with interview preparation, or need consultation in general. Please reach out to me over the email.

Email: shivamsrivastava.iec@gmail.com

For collaboration, clarifications or support please connect with me on:

Email: shivamsrivastava.iec@gmail.com

Quora: Shivam Srivastava

X.com (Twitter): Shivam on X

Buy Me a Coffee: Shivam Srivastava

If you liked this article, you’ll also enjoy my below list of articles:

[embed]Interview Experiences and Learnings Edit descriptionmedium.com

[embed]Deep Dive Series Edit descriptionmedium.com