Interview replay
Full round replay — dependency injection
Timed verbal replay with pass/fail criteria per follow-up.
How to run this
The opener
“Why is constructor injection preferred over field injection?”
Budget: 45 seconds. Going long here is itself a fail signal.
Follow-ups
1. “Why can a constructor-injected field be final but a field-injected one cannot?”
Testing: Language rule or vague preference?
Scoring
Pass: A final field must be assigned by the end of the constructor, and field injection assigns it after construction. The code does not compile — it is a Java rule, not a Spring one.
Fail: Says Spring does not support it, or that you can do it with reflection.
2. “What does field injection cost at runtime?”
Testing: Whether they invent a performance story.
Scoring
Pass: Nothing measurable. The cost is when problems surface: a missing dependency, a half-wired test and a cycle all appear later, as an NPE in whichever method touches the field first.
Fail: Claims it is slower, or that reflection makes it expensive.
3. “I call an injected dependency from my constructor and get a NullPointerException. Why?”
Testing: Do they know the ordering?
Scoring
Pass: Field injection runs after construction, so every injected field is null while the constructor body executes. Move it to @PostConstruct, or take the dependency as a constructor parameter so the mistake cannot be written.
Fail: Suspects a missing bean or component scanning.
4. “How does field injection let a circular dependency work?”
Testing: Two-phase wiring, in their own words.
Scoring
Pass: The container instantiates both beans first and wires them in a second pass, so neither needs the other to exist yet. Constructor injection has no such phase and no valid order, so it fails immediately.
Fail: Thinks Spring resolves it by cleverness, or that constructor injection also works.
5. “Boot 2.6 made circular references fail by default. Was that the right call?”
Testing: Can they hold an opinion with a reason?
Scoring
Pass: Yes — a cycle that the container can satisfy is still two classes that cannot be built, read or tested independently. Failing at startup moves the discovery to the cheapest moment.
Fail: Only knows the flag to turn it back on.
6. “Someone adds @Lazy to break the cycle. Good fix?”
Testing: Whether they can see what it actually changes.
Scoring
Pass: No. It injects a proxy that resolves on first use, so startup succeeds and the cycle survives — a startup failure becomes a runtime one. The fix is to extract the type both classes were reaching for.
Fail: Accepts it because the application starts.
7. “Do you need @Autowired on a constructor?”
Testing: Version awareness.
Scoring
Pass: Not since Spring 4.3, when the class has exactly one constructor. With two or more you must mark the one Spring should use.
Fail: Says it is always required, or always optional.
8. “Is field injection ever the right choice?”
Testing: Whether they can defend the other side.
Scoring
Pass: In test classes, where the container is present and nothing else constructs the object. Setter injection has a narrower case: a genuinely optional or reconfigurable dependency.
Fail: Treats it as always wrong, with no case where it is fine.
9. “Your constructor has nine parameters. What now?”
Testing: Do they hide the signal or read it?
Scoring
Pass: Nine collaborators means more than one responsibility. Split the class or introduce a facade that means something. Hiding the list removes the only signal that was working; @RequiredArgsConstructor removes the typing without removing the signal.
Fail: Switches to field injection to shorten it.
Score yourself
← Back to Why is constructor injection preferred over field injection?