Why pre-screen Java developers before the technical interview
The problems that cost real time in Java are not language problems. They are a garbage collector pausing under load, a thread pool exhausted by a slow dependency, or a query that was fine with ten thousand rows. Developers who have been through that reason about the runtime, not just the code. A short screen asks for one of those diagnoses, which separates them from developers who have only worked in a framework.
What actually matters when screening Java Developer candidates
- 01
Technical proficiency
Check depth in modern Java (records, streams, virtual threads) plus Spring Boot, JPA/Hibernate, Maven or Gradle, and how they handle concurrency and garbage collection tuning.
- 02
Systems and trade-offs
Probe service decomposition calls: monolith versus microservices, REST versus Kafka messaging, caching with Redis, connection pooling, and where they accepted latency or consistency trade-offs.
- 03
Evidence and rigour
Test testing and debugging habits: JUnit 5 and Mockito coverage, integration tests with Testcontainers, profiling via JFR or async-profiler, and diagnosing production memory leaks.
- 04
Collaboration and communication
Assess pull request review behaviour, working with QA and product on ticket scope, and how they explain a refactor or tech debt case to non-engineers.
Pre-screening questions to ask Java Developer candidates
12 questions grouped by what they test. Ask the same set in every screen and score answers on a consistent scale, or send them as an async video screen and compare answers side by side.
Systems they shipped
3 questions01Can you provide examples of large-scale projects where you used Java extensively?
Listen forSystems in production with scale described, and their own components rather than the team's work.
Projects described at a team level, or nothing that ran under real load.
02Can you describe a challenging Java project and how you worked through the difficulties?
Listen forA genuine technical difficulty with the reasoning that resolved it, not a delivery problem.
Challenges described as deadlines or requirements, with no technical content.
03Do you have experience building Java microservices?
Listen forService boundaries reasoned about, with failure handling between services designed rather than assumed.
Services split by convention with synchronous chains and no timeout or retry strategy.
Concurrency and memory
3 questions04What is your experience with multi-threading and synchronisation in Java?
Listen forA real concurrency problem such as contention or a deadlock, with how it was diagnosed.
Concurrency avoided entirely, or synchronisation described only as adding a keyword.
05Are you familiar with Java memory management and garbage collection behaviour?
Listen forHeap behaviour understood under load, with collector pauses and leaks investigated using real tooling.
Memory treated as automatic, or no experience of a leak or a pause affecting a service.
06How do you apply object-oriented design in the code you write?
Listen forDesign decisions justified by the problem, with a preference for simple structures over deep hierarchies.
Patterns recited by name, or abstraction added ahead of a second use case.
Debugged in production
3 questions07What tools have you used for debugging and troubleshooting in a Java environment?
Listen forProfilers, heap and thread dumps used on live systems, with a specific problem they found that way.
Debugging limited to the development environment, or production issues escalated to someone else.
08What is your experience with relational databases and query performance?
Listen forQuery plans read and indexes reasoned about, with a slow query they diagnosed under real data volume.
Database work entirely through an object mapper, with no idea what queries it produces.
09Have you integrated Java applications with other systems or services?
Listen forIntegration with timeouts, retries and failure modes handled, including what happens when a dependency is slow.
Integrations built for the happy path, or no handling for a dependency that stops responding.
Code others maintain
3 questions10Can you explain how you maintain code quality in your Java projects?
Listen forReview, static analysis and tests treated as normal, with a standard they hold in their own code.
Quality described as a process others run, or tooling configured and then ignored.
11Do you have experience with test-driven development in Java?
Listen forTests written where they earn their keep, with a view on what is worth testing and what is not.
Coverage targets treated as the objective, or tests that only exercise the framework.
12Can you describe your experience designing and maintaining Java APIs?
Listen forInterfaces designed for the consumer, with versioning and backward compatibility handled deliberately.
Breaking changes shipped without versioning, or consumers discovered by the errors they raise.
How to score responses
Score every candidate on the same four criteria immediately after the screen. At this stage you are shortlisting for panel interviews, not making the final call.
Technical proficiency
35%5Names JDK versions used, explains collection or concurrency choices precisely, and describes GC or heap tuning done on a real service.
Systems and trade-offs
25%5Walks through a specific architecture, quantifies throughput or latency effects, and states what they deliberately chose not to build.
Evidence and rigour
25%5Cites heap dumps, thread dumps, or APM traces that located a real defect, with before and after metrics.
Collaboration and communication
15%5Gives concrete review examples, defends design decisions without defensiveness, and translates technical risk into delivery impact.
The expensive problems are a collector pausing under load, not a logic bug. A one-way video screen asks for one they diagnosed.
Try it on HirevireScreening FAQ
Process basics
How long should a pre-screening round for this role take?
Fifteen minutes across eight to ten questions, answered async. Enough to establish what they shipped, test runtime understanding, and hear a production debugging story before a technical round.
Should I include a coding exercise in the screen?
No. Keep the screen to experience and reasoning, then use a focused technical round for code. A take-home attached to a first-stage screen loses good candidates for no extra signal.
Evaluating answers
What is the strongest signal when screening this role?
A production problem diagnosed. Developers with depth describe heap dumps, thread dumps or profiling. Anyone whose hardest problems were logic bugs has not carried a system in production.
How do I judge their concurrency understanding?
Ask about a threading problem they hit. Real answers describe shared state, contention or a deadlock and how it was found. Anyone who says they avoid threads has not worked at load.
Go deeper on this role
Sanat has been hiring since 2012 and watching the recruitment industry change up close ever since, and turned that screening process into Hirevire's video screening platform. LinkedIn
