GCC / captive centres Java interviews
Also called: global capability centres, GICs, offshore development centres
The in-house engineering arm of a foreign parent, building that company's own products rather than client deliverables. The interview sits between the other two and is often the most balanced of the three: real DSA but rarely leetcode-hard, genuine Java and framework depth, and design discussion grounded in the domain. Domain knowledge — payments, retail, healthcare, trading — carries more weight here than anywhere else, and code quality and testing are examined more seriously than at services firms.
The rounds
1. Online assessment
60-90 minOne or two medium DSA problems, sometimes with Java-specific MCQs or a debugging section. Generally gentler than product-company screens.
Clears it: Solid medium-level solutions; hard problems are uncommon.
2. Technical round 1 — coding
45-60 minDSA at easy-to-medium, plus core Java depth in the same session. Interviewers frequently pivot from your solution into how a collection you used actually works.
Clears it: Clean code plus being able to explain the library you leaned on.
Ends it: Using a HashMap in the solution and not knowing how it resolves collisions.
3. Technical round 2 — design and framework
45-60 minSpring in depth, REST API design, database modelling, and low-level design. Transaction behaviour and error handling come up often.
Clears it: Design reasoning tied to a real constraint, not a diagram from a course.
4. Domain and system design
45-60 minDesign within the parent's domain, with its real constraints — idempotency and reconciliation for payments, consistency and audit for banking, privacy for healthcare.
Clears it: Knowing why the domain forces a constraint, not only that it exists.
5. Hiring manager
30-45 minOwnership, collaboration across time zones with the parent's teams, and long-term interest. Genuinely evaluative, and often where offers are decided.
Ends it: Signalling that this is a stepping stone to a product company.
What it weights
Relative emphasis out of five — where preparation time actually pays back here.
Java and framework depth
Deeper than service firms, broader than product companies. The core of the loop.
Low-level design and code quality
Clean abstractions and testability are examined, not assumed.
Domain understanding
The distinguishing factor. Highest weight of the three types.
System design
From about three years, usually framed inside the domain.
DSA
Real but bounded. Medium-level competence, rarely hard problems.
Testing
Asked about far more seriously than at services firms.
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
Fundamentals with mechanisms, not definitionsMedium DSA plus core Java where the follow-up is always 'how does that work'. Testing and clean code start appearing this early, which surprises candidates coming from services interviews.
Where to spend your time
Questions at this band— 5 answered in depth
- How does HashMap work internally?
- What is the contract between hashCode() and equals()?
- Is Java pass-by-value or pass-by-reference?
- When would you use LinkedList instead of ArrayList?
- How do you write a unit test for this method?
- What does try-with-resources do that finally cannot?
- What is the difference between checked and unchecked exceptions?
3-4 years
Concurrency, Spring internals and the domainConcurrency becomes a real section. Spring questions move from annotations to mechanisms — proxying, transaction boundaries, bean scopes. Domain-shaped design questions begin.
Where to spend your time
Questions at this band
- Is HashMap thread-safe? What breaks specifically?
- What does volatile guarantee, and what does it not?
- How does @Transactional work, and when does it silently not apply?
- How do you make an API idempotent?
- How would you handle a partial failure mid-transaction?
- What is the difference between a stream and a parallel stream?
- How do you test code that calls an external service?
5-6 years
Design ownership inside a domainDesign and production judgement dominate, framed in the parent's domain. You are expected to have opinions about reliability, observability and data correctness, and to defend them.
Where to spend your time
Questions at this band
- Design a payment reconciliation system. What is your source of truth?
- How do you size a thread pool, and how would you know it is wrong?
- How do you diagnose a memory leak in production?
- How do you achieve exactly-once processing, or can you?
- What would you monitor for this service, and what would page you?
- How do you migrate a schema with zero downtime?
- What are virtual threads, and would they help this service?
Why candidates get rejected here
- Java that stops at definitions when the round expects mechanisms
- Being unable to explain how a library you used in your solution works
- No opinion about testing, or treating it as someone else's job
- Showing no interest in the parent company's actual domain
- Design answers that recite a pattern without naming the constraint it solves
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.