Java · OOP, JVM and backend craft
What Java practices do you apply in production code?
Short answer
Good Java code is readable, explicit and easy to change. Favour small methods, immutability, clear names, focused exceptions and measured optimization over clever tricks.
Most production cost is change, not initial writing. Code should make intent obvious: names that describe purpose, methods that do one thing, and types that encode invariants. Cleverness that saves a line but slows a reviewer is a net loss.
public record Customer(String name, String email) {
public Customer {
Objects.requireNonNull(name);
Objects.requireNonNull(email);
}
}Practices that pay off
- Prefer immutability and final fields for value objects
- Use constructor injection instead of field injection
- Catch specific exceptions and preserve the cause
- Return empty collections rather than null
- Use Optional for lookup return types, not for fields
- Keep streams short and free of side effects
- Log with structured context, not string concatenation in hot paths
- Measure before optimizing; the JIT often surprises intuition
Consistency with the surrounding codebase matters more than personal preference. Follow the team's formatter, naming and testing conventions. When a rule conflicts with clarity, explain the trade-off rather than silently diverging.
Follow-ups you should expect
Interviewers use these to check whether the first answer was understanding or memorisation.
- 1When do you introduce an interface instead of a concrete class?
- 2Why is returning null for a collection a poor choice?
- 3How do you decide when to optimize?
- 4How do you balance consistency with local improvement?
Say it in the interview
I aim for code that is easy to read and change: clear names, small methods, immutable value types and explicit error handling. I use constructor injection, avoid returning null collections and keep streams simple. I measure before optimizing because the JIT makes intuition unreliable. I also avoid premature abstraction, adding interfaces when there is a real second use case, and I follow the team's conventions unless there is a concrete reason to deviate.
Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.
Related questions
Reading is step one
Now say it out loud.
Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live Java mock interview and get scored feedback on depth, clarity and confidence.