Java Interview Experience
My CGI Java Developer Interview Experience (2.8 Years): Questions and Answers
A round-by-round account of the Core Java, Spring Boot, Linux, SQL, coding, production support, and managerial questions I encountered.
If you are preparing for a CGI Java Developer interview experience at the 2–3 year level, the process may test much more than definitions. In my interview for a Java Developer position with 2.8 years of experience, the questions moved from Java fundamentals to realistic production problems, followed by a managerial discussion.
Round 1: Core Java, Spring Boot, Linux, and Coding
The first round checked whether I understood everyday Java concepts and could apply them. These are simple ways to explain the topics in an interview.
1. What is finally?
A finally block runs after the try/catch flow, whether an exception occurs or not. It is commonly used for cleanup. It may not run if the JVM terminates abruptly, such as after System.exit().
try {
processFile();
} catch (IOException e) {
log.error("File processing failed", e);
} finally {
closeResources();
}2. Difference between throw and throws
throw actually raises one exception inside a method. throws appears in a method signature and declares exceptions that the caller may need to handle.
public User findUser(long id) throws SQLException {
User user = repository.findById(id);
if (user == null) {
throw new IllegalArgumentException("User not found");
}
return user;
}3. What causes ConcurrentModificationException?
It commonly occurs when a collection is structurally changed while a fail-fast iterator is traversing it. Use the iterator’s remove() method, removeIf(), or a suitable concurrent collection. It does not necessarily mean multiple threads are involved.
List<String> names = new ArrayList<>(List.of("Ana", "", "Raj"));
names.removeIf(String::isBlank); // Safe and readable4. How does HashMap work internally?
A HashMap uses the key’s hash to choose a bucket. It then uses equals() to locate the correct key within that bucket. Collisions are stored in a linked structure, which can become a balanced tree after a threshold in modern Java. Good hashCode() and equals() implementations are essential. Average get/put time is O(1), and the map resizes when its capacity and load-factor threshold are exceeded.
5. How can you create a thread?
The classic answers are extending Thread and implementing Runnable. A Callable can return a value and throw checked exceptions. In production, I would normally submit tasks to an ExecutorService instead of manually creating threads.
ExecutorService pool = Executors.newFixedThreadPool(4);
Future<Integer> result = pool.submit(() -> calculateTotal());
pool.shutdown();6. Can we overload the main() method?
Yes. Java allows multiple methods named main with different parameter lists. However, the JVM starts the application only through public static void main(String[] args). Other overloads must be called explicitly.
7. Can a constructor throw an exception?
Yes. A constructor can throw checked or unchecked exceptions when an object cannot be initialized correctly. For a checked exception, declare it with throws. The object is not successfully created if construction fails.
public Config(Path path) throws IOException {
this.properties = Files.readString(path);
}8. @Repository vs. @Component
Both register a Spring bean. @Component is a general stereotype, while @Repository communicates that the class belongs to the data-access layer and enables Spring’s persistence exception translation. I use @Repository for DAO classes because it makes the class’s responsibility clear.
9. @Controller vs. @Component
@Controller is a web-layer specialization detected by Spring MVC and is intended for handling requests and returning views. @RestController combines @Controller with @ResponseBody for REST responses. A plain @Component has no controller-specific meaning.
10. Useful Linux commands for Java developers
ps -ef | grep java— find a Java process.toportop -H -p <pid>— inspect CPU, memory, and threads.tail -f app.log— follow application logs.grep -n "ERROR" app.log— locate errors with line numbers.df -handdu -sh *— inspect disk usage.curl -i http://localhost:8080/actuator/health— test an endpoint.
Coding problem: Character frequency using Stream API
Convert the string to a stream of characters and group identical values. Using LinkedHashMap preserves the order in which characters first appear.
String input = "interview";
Map<Character, Long> frequency = input.chars()
.mapToObj(c -> (char) c)
.collect(Collectors.groupingBy(
Function.identity(),
LinkedHashMap::new,
Collectors.counting()
));
System.out.println(frequency);SQL problem: Third-highest salary without a subquery
If the database supports pagination, sort distinct salaries in descending order, skip the first two, and fetch the next one. This returns the third distinct highest salary.
SELECT DISTINCT salary
FROM employee
ORDER BY salary DESC
LIMIT 1 OFFSET 2;Note: Syntax varies by database. In SQL Server, use OFFSET 2 ROWS FETCH NEXT 1 ROW ONLY.
Round 2: Production Scenarios and Performance
This round was scenario-based. A strong answer should be systematic: measure first, isolate the bottleneck, make one evidence-based change, and confirm the improvement.
1. A Spring Boot application is slow in production. What would you do?
- Confirm the impact using response-time percentiles, request rate, error rate, CPU, memory, garbage collection, and thread metrics.
- Use logs and distributed tracing to identify whether time is spent in application code, SQL, an external API, or a queue.
- Capture thread dumps for blocked threads and inspect JVM/GC data for memory pressure or long pauses.
- Fix the measured bottleneck—for example an N+1 query, an undersized connection pool, excessive logging, or a blocking remote call.
- Load-test the change, deploy gradually, and compare the same metrics.
Practical example: If tracing shows that 80% of request time is spent loading child records individually, I would replace the N+1 access pattern with a join fetch or a purpose-built query, then compare query count and p95 latency.
2. A REST API increased from 1 second to 10 seconds. How would you troubleshoot it?
I would first check what changed: deployment, traffic, data volume, database plan, or a downstream service. Then I would follow a slow request through trace spans, review timeouts and pool saturation, reproduce it with the same payload, and profile only the suspected path. If a downstream call is slow, I might add a strict timeout, safe retry with backoff, circuit breaker, or cache—but only where the operation’s behavior allows it.
3. A SQL query takes 20–30 seconds on a large table. How would you optimize it?
I would inspect the execution plan instead of guessing. I would check full-table scans, costly joins, incorrect row estimates, sorting, locking, and whether the filters can use an index. Typical improvements include a selective composite index, returning only required columns, avoiding functions on indexed filter columns, reducing rows before joins, and updating database statistics.
-- Supports filtering by customer and date, then reading status
CREATE INDEX idx_orders_customer_date
ON orders (customer_id, created_at);
SELECT id, status, created_at
FROM orders
WHERE customer_id = ?
AND created_at >= ?
ORDER BY created_at DESC;An index adds storage and write cost, so I would validate it with the plan and production-like data before keeping it.
4. The application works for 500 users but slows down at 5,000. What would you do?
I would run a controlled load test and watch where saturation begins. I would check application threads, database and HTTP connection pools, CPU, memory, network, queue depth, database limits, and downstream rate limits.
- Remove shared-state bottlenecks and long synchronized sections.
- Use bounded pools and backpressure rather than unlimited queues.
- Cache frequently read, stable data with a clear expiry strategy.
- Move suitable long-running work to asynchronous processing.
- Keep services stateless where practical and scale instances horizontally behind a load balancer.
- Protect the database through query tuning, sensible pagination, and pool sizing based on database capacity.
5. Memory keeps increasing until OutOfMemoryError. How would you investigate?
First I would identify the exhausted area from the error and JVM metrics: heap, metaspace, direct memory, or native threads. For a heap issue, I would enable safe heap-dump capture, compare class histograms, and use a memory analyzer to find large retained object graphs and their GC roots.
Practical example: An unbounded static cache may retain every customer response. The fix is not simply increasing heap; I would use a bounded cache with expiry, remove unnecessary references, and verify under a soak test that the post-GC baseline remains stable. I would also check unclosed resources, listeners, ThreadLocal values, oversized queues, and excessive object allocation.
Round 3: Face-to-Face Managerial and HR Discussion
The final conversation covered my project, architecture, responsibilities, deployment process, API development, database design, team collaboration, and challenges. The manager appeared interested in what I had personally contributed—not just what the team had built.
A simple structure for explaining your project
- Context: What business problem does the application solve?
- Architecture: Briefly explain services, APIs, database, messaging, and deployment.
- Your role: Name the modules and decisions you owned.
- Challenge: Describe one specific issue, the evidence you gathered, and your action.
- Result: Quantify the impact where possible.
Behavioral questions
Use the STAR format—Situation, Task, Action, Result—for questions about conflict, tight deadlines, production incidents, mistakes, and collaboration. Keep the situation short, make your own actions clear, and end with the outcome and what you learned.
Preparation Tips for 2–3 Years of Experience
- Revise collections, exceptions, concurrency, streams, object contracts, and JVM basics.
- Understand Spring bean stereotypes, dependency injection, REST error handling, validation, transactions, and application monitoring.
- Practice short Java Stream and SQL problems without relying only on memorized solutions.
- Read execution plans and learn how indexes, joins, pagination, and locking affect performance.
- Practice Linux commands used for processes, logs, disk, networking, and service health.
- Prepare a two-minute project explanation and two strong troubleshooting stories with measurable results.
Most importantly, explain why you chose an approach, what trade-off it introduced, and how you verified the result. That sounds far stronger than reciting a definition.
Frequently Asked Questions
How many rounds are there in the CGI Java Developer interview?
In my experience, there were three rounds: two technical interviews and one face-to-face managerial/HR discussion. The exact process can vary by role, team, and location.
Does CGI ask Java coding questions?
Yes. My first round included a Java Stream API problem involving character frequency.
Are production scenario questions included?
Yes. My second technical round focused on slow APIs, SQL performance, scalability, memory growth, and production troubleshooting.
Is Spring Boot important for this interview?
Yes. Spring stereotypes and application performance were part of my discussion. Candidates should also be ready to explain how they use Spring Boot in a real project.
Should I prepare Linux and SQL?
Absolutely. Basic Linux troubleshooting and SQL optimization both appeared in the interview.
What difficulty level should I expect?
For me, it was moderate to difficult because the interview combined fundamentals with practical production scenarios. Hands-on project experience made the scenario questions easier to approach.
Conclusion
My CGI Java Developer interview experience was well structured. The first round tested Java fundamentals, Spring Boot, Linux, SQL, and coding. The second examined how I would diagnose real production issues. The final discussion focused on project ownership, collaboration, and communication.
If you have around 2–3 years of experience, combine concept revision with practical stories from your own work. Be honest about your contribution, reason through scenarios step by step, and explain how you would measure whether a solution worked. Best of luck with your interview!






