Checklist to bring to interviews (as a candidate) or early-stage conversations. Ask these aloud—or work them naturally into technical discussions—and listen for both the content of the answer and the spontaneity with which they can give concrete examples.
| # | Question to the team / hiring tech lead | Green flag | Red flag |
|---|---|---|---|
| 1 | “How deep are the typical inheritance chains in your core domain code?” | “a) There is no. b) 1 or 2 levels. c) we strongly prefer composition / interfaces.” | “We have a common base class everyone extends… then another… then another. like e.g. 7 levels of iheritance” |
| 2 | “When was the last time you replaced an inheritance hierarchy with composition? What prompted it?” | A real story: pain → refactor → composition → happier tests. | “Never needed to. Our base classes are perfect.” |
| 3 | “How do new services declare dependencies—constructor injection, service locator, or direct new calls?” |
Constructor injection, implicit/explicit DI. | Global singletons, static helpers, service locator pattern. |
| 4 | “Do you treat static utility classes as a smell?” | “Mostly yes; we limit statics to pure, side-effect-free helpers (e.g. Duration.ofHours).” |
“We love static methods—they’re everywhere to hold business logic in them.” |
| 5 | “What percentage of code paths can be unit-tested without Spring/Guice boots?” | High percentage; thin adapters around frameworks. | “We spin up the full container for every test.” |
| 6 | “Describe your code review checklist. What architecture or testing items are non-negotiable?” | Tests, SOLID, immutability, small diffs, no hidden side-effects. | “Review? Mostly LGTM if it compiles.” |
| 7 | “How do you prevent problems caused from overusage of inheritance” | “We ban inheritance using ArchUnit / Konsist, discourage deep trees, rely on interfaces + delegation.” | “It’s never bitten us.” |
| 9 | “How do you model domain behavior: rich domain objects, services with pure functions, or big God objects?” | Slim, cohesive objects + pure functions; no huge managers. | 1 000-line *Manager classes. |
| 10 | “All of the front-end components source code lives in version-controlled plain text?” | “Changes land via PRs with diffs.” | “Most UI config is in the database; we copy XML blobs around.” |
| 11 | “Describe your approach to data flow tracing. How quick is it to answer ‘where is this field set?’” | IDE ‘Find Usages’ works; code is modular; minimal reflection. | Requires spelunking through framework magic or DB configs. |
| 12 | “Do you practice trunk-based development or long-lived feature branches?” | Short-lived branches, CI always green. | Months-old branches, infrequent merges, broken main. |
| 13 | “How do you measure code health over time (e.g., cyclomatic complexity, coupling metrics)?” | SonarQube, Gradle/CLI checks in CI; actions taken on trends. | “We tried Sonar once but turned it off.” |
| 14 | “What guidelines do you have around mutability and side-effects?” | Prefer immutability; no hidden state changes—everything that mutates data is plainly advertised so reviewers (and future-you) can spot it instantly; functional style where useful. | “We just trust everyone.” |
- Prioritize 6–8 questions that fit naturally in your conversation slot.
- Listen for specifics. Vague answers ≈ they’ve never thought hard about it.
- Probe gently. If they dodge a question, ask for an example or the last time it came up.
- Watch non-verbal cues. A proud, engaged explanation signals genuine practice; defensiveness or hand-waving often means legacy pain.
Tip: After the interview, jot quick notes. Patterns emerge fast: companies that value clean architecture will light up when talking about refactors, tests, and metrics. The rest will shrug—and you’ve filtered them out long before offer stage.