Service-based Java interviews

Also called: IT services, consultancies, system integrators

Breadth over depth, and predictability over surprise. The interviewer is often staffing a specific client project, so they are checking that you can be billed on it without supervision. Questions come from a recognisable pool, which means preparation pays off unusually directly — but it also means a rehearsed-sounding answer to a common question is expected rather than penalised. The failure mode is not being outsmarted; it is being unable to explain your own project.

TCSInfosysWiproAccentureCognizantCapgeminiHCLTechTech MahindraLTIMindtree

The rounds

  1. 1. Online assessment

    60-90 min

    Aptitude, some verbal, and easy-to-medium coding — often on a platform with a strict timer. Java-specific MCQs on output prediction are common.

    Clears it: Speed on the aptitude section; most candidates lose time there, not on the code.

    Ends it: Running out of time. Accuracy matters less than completion rate.

  2. 2. Technical round 1

    30-45 min

    Core Java breadth. OOP definitions, collections, exceptions, strings, and simple output-prediction. Then Spring Boot basics and SQL if the role calls for them.

    Clears it: Correct, confident definitions plus one concrete example each.

    Ends it: Hedging on fundamentals — 'I have used it but I do not remember the difference'.

  3. 3. Technical round 2

    30-45 min

    Your project, in depth. Architecture, your specific contribution, why the choices were made, and what you would change. Often more decisive than round 1.

    Clears it: Being able to draw your system and defend a decision you did not make.

    Ends it: Describing a project you cannot answer follow-up questions about.

  4. 4. Managerial and HR

    20-30 min

    Fit, notice period, location and shift flexibility, and salary expectations. Usually not a technical filter, but it is a real one.

    Ends it: Inflexibility on location or shift for a client-facing role.

What it weights

Relative emphasis out of five — where preparation time actually pays back here.

  • Core Java breadth

    The largest single block. Definitions with an example beat deep internals here.

  • Project explanation

    Frequently the deciding round, and the one candidates prepare least.

  • Spring Boot basics

    Annotations, REST endpoints, dependency injection, and how a request flows.

  • SQL and joins

    Write a query on paper. Joins and group-by come up far more than tuning.

  • Coding / DSA

    String and array manipulation, collections logic. Rarely beyond easy-medium.

  • System design

    Mostly absent below six years, and high-level when present.

By experience

The same company type asks a different interview at two years and at six. Questions that link have a full write-up.

1-2 years

Prove you know the language and can be given work

Almost entirely core Java definitions plus output prediction, with a light coding question. Your project matters but is expected to be small, so honesty about your scope is better than inflation.

Where to spend your time

Questions at this band— 6 answered in depth

3-4 years

Language depth plus a framework and a database

The same core-Java pool, but follow-ups now go one level deeper, and Spring Boot and SQL become real sections rather than a courtesy. You are expected to own a module and explain its design.

Where to spend your time

Questions at this band— 1 answered in depth

  • How does HashMap work internally?
  • HashMap vs Hashtable vs ConcurrentHashMap?
  • What does @Autowired do, and what are the injection types?
  • What is the difference between a stream and a collection?
  • How do you handle exceptions in a REST controller?
  • Write a query to find the second-highest salary.
  • What is the difference between @Component, @Service and @Repository?
  • How would you find duplicates in a list using streams?

5-6 years

Design decisions and the ability to lead a module

Core Java is assumed and checked quickly. The weight moves to design choices, why your project is built the way it is, code review judgement, and mentoring. Some concurrency, usually practical rather than memory-model deep.

Where to spend your time

Questions at this band

  • Is HashMap thread-safe? How would you make it safe?
  • How do you size a thread pool for an I/O-bound service?
  • How does @Transactional actually work, and when does it silently not?
  • How would you debug a memory leak in production?
  • What would you change about your current project's design?
  • How do you review a junior developer's pull request?
  • How do you handle a slow SQL query reported in production?

Why candidates get rejected here

  • Being unable to explain your own project's architecture or your part in it
  • Uncertainty on fundamentals the role assumes — collections, OOP, exceptions
  • Writing code that does not compile when asked to write it by hand
  • Notice period, location or shift constraints the client will not accept

Compare with

Read this as a guide, not a prediction. These are patterns across many interviews, not a guarantee about any one company. Process varies by company, by team, by hiring manager and by year, and a single company can run all three shapes for different roles. Use this to decide where to spend preparation time, not to predict a specific loop.