What I look for when I interview Java engineers

I’ve interviewed engineers at two companies: as a technical interviewer at EPAM, and later on LTIMindtree’s technical interview panel, for both project-level and organisation-level hiring. The rounds were mostly technical (Java, Spring, REST, SQL) plus coding and problem-solving, and I interviewed both freshers and experienced hires.

After enough interviews, patterns show up. This is what I look for, what usually goes wrong, and what I’d tell anyone preparing.

What I look for

Fundamentals over frameworks. Spring Boot makes it easy to build a working service without understanding much of what’s underneath. I care whether a candidate knows why things work: what an annotation actually does, how a collection behaves, what happens when an exception propagates. Frameworks change. Fundamentals carry over.

Thinking out loud. A candidate who talks through their reasoning, asks clarifying questions and weighs options tells me far more than one who sits silently and then produces an answer. Even when they’re wrong, I can see how they think, and that’s what I’ll be working with every day.

Honesty about gaps. “I don’t know, but here’s how I’d work it out” is one of the best answers anyone can give. Nobody knows everything. Bluffing is easy to spot, and it makes me doubt everything else the candidate has said.

Real project depth. If you’ve built something, you should be able to go deep on it: why it was designed that way, what broke, what you’d change. That depth is hard to fake and easy to recognise.

Why candidates don’t make it

Memorised answers. Textbook definitions recited word for word, with nothing behind them. The moment I ask a follow-up (“why?”, “what if?”), the answer falls apart.

The resume doesn’t match reality. A project is listed on the CV, but the candidate can’t explain what they did on it, how it worked, or why decisions were made. If it’s on your resume, it’s fair game.

Weak basics. Collections, OOP, exception handling, SQL joins. Gaps here are hard to overlook, however impressive the frameworks on the CV.

Not taking a hint. When a candidate is stuck, I often nudge them in the right direction. Some pick it up and run with it. Others ignore it and keep pushing down the same dead end. Using guidance well is a skill you’ll need on any team.

Freshers and experienced hires

I don’t use the same yardstick for everyone. With freshers, I’m looking for potential: solid basics, clear thinking, and the ability to learn. Nobody expects deep production experience from someone just starting out. With experienced candidates, I’m looking for depth: real projects they can explain in detail, and the judgement that only comes from having built and maintained systems.

My one piece of advice

Master the basics first. It’s tempting to prepare by collecting framework buzzwords, but most interviews are won or lost on fundamentals: core Java, collections, OOP, exceptions and SQL. Get those solid, and everything built on top of them, including Spring, becomes easier to explain, because you actually understand it.