How to assess · For hiring teams

How to Assess Java Skills When Hiring

The test formats that actually work for Java, what a strong answer looks like, sample questions and a scoring rubric you can use as-is.

The short answer

Assess Java with a task, not a conversation: live coding exercise, take-home assignment, ai-generated coding assessment, design and code review discussion or mcq knowledge check. Score it against written criteria you fix before you see any submissions, and weight the criteria that the role actually depends on.

Designs with sound object-oriented principles: clear responsibilities, composition over inheritance, and sensible interfaces
Knows the collections framework and picks the right structure (List, Set, Map) for the access pattern and complexity
Understands generics, immutability, and how equals and hashCode work together
Reasons correctly about concurrency: thread safety, shared state, and when to use higher-level concurrency utilities

Build a Java assessment →Read the full article ↓

Paste a job description; Cohesyve generates a role-specific assessment and rubric. Ten candidates free, no card.

When you are hiring a Java developer, you are usually staffing systems that need to run reliably for years, often back-end services, enterprise platforms, or Android apps. Java's maturity means there are many experienced developers, but also many whose knowledge stopped a decade ago or who lean entirely on a framework. As a recruiter or hiring manager, you need to test object-oriented design, the collections framework, concurrency, and how candidates reason about robust systems. This guide covers what to evaluate, which methods work, and how to score genuine Java ability before an offer.

Why Java is worth testing

Java is widely used for long-lived, high-stakes systems, so design quality and correctness compound over years. The talent pool ranges from deeply skilled engineers to people who only know one framework or outdated practices. Testing directly reveals whether a candidate understands object-oriented design, the collections framework, concurrency, and exception handling, rather than reciting syntax. That depth is exactly what keeps an enterprise codebase maintainable and prevents expensive production failures.

What strong Java looks like

Designs with sound object-oriented principles: clear responsibilities, composition over inheritance, and sensible interfaces
Knows the collections framework and picks the right structure (List, Set, Map) for the access pattern and complexity
Understands generics, immutability, and how equals and hashCode work together
Reasons correctly about concurrency: thread safety, shared state, and when to use higher-level concurrency utilities
Handles exceptions deliberately, distinguishing checked from unchecked and avoiding swallowed errors
Writes testable code with JUnit and understands dependency injection rather than hard-wiring everything
Knows modern Java features (streams, Optional, records) and uses them where they improve clarity

Ways to assess Java

Live coding exercise

A timed screen-share implementing a small, well-bounded class or algorithm, with attention to design and edge cases.

Pros

Shows object-oriented thinking, use of collections, and how the candidate handles edge cases live.

Cons

Pressure can suppress strong candidates and it consumes interviewer time.

Best for Mid and senior back-end roles where design and correctness matter.

Take-home assignment

A scoped project such as a small service or library built on the candidate's own time.

Pros

Reveals class design, package structure, testing, and dependency management closer to real work.

Cons

Authorship is hard to verify, frameworks and AI can inflate output, and large tasks deter strong candidates.

Best for Roles where production code quality, structure, and tests are the priority.

AI-generated coding assessment

An automated test like Cohesyve's that gives each candidate a unique Java problem in a live IDE with real test execution.

Pros

Cheat-proof and scalable: unique per-candidate problems cannot be shared or pasted, and scoring is objective and async.

Cons

For senior design hires, add a short discussion to probe architecture trade-offs.

Best for Screening a high volume of applicants fairly before live interviews.

Design and code review discussion

Discuss how the candidate would design a small system, or hand them a flawed class to critique for thread safety, mutability, and design.

Pros

Surfaces depth in object-oriented design, concurrency, and judgment that pure coding may miss.

Cons

Subjective and needs an experienced interviewer with a shared rubric.

Best for Senior and lead hires responsible for architecture and reviews.

MCQ knowledge check

A short quiz on language semantics: collections complexity, equals/hashCode, checked exceptions, and the memory model.

Pros

Fast, consistent early filter on fundamentals.

Cons

Rewards recall and cannot show whether the candidate writes well-designed code.

Best for An early gate before a hands-on stage, never as the deciding signal.

Cohesyve

Run a Java assessment on your next opening

Cohesyve generates a unique Java task per candidate from your job description, with the scoring rubric attached. Questions are different for every applicant, so they cannot be shared or looked up.

Try it free →Book a 30-min demo

What to test

Object-oriented design

The core of maintainable Java. Test responsibility separation, interfaces, and composition versus inheritance.

Design a small set of classes for a real domain and justify the boundariesRefactor a god class into focused, testable unitsExplain when you would favour composition over inheritanceDefine an interface and explain how it improves testability

Collections framework and generics

Choosing the right collection and reasoning about complexity, plus correct generics usage.

Pick between ArrayList, LinkedList, HashMap, and TreeMap for a given access patternExplain the relationship between equals and hashCode for use as a HashMap keyImplement a generic method or class and explain the boundsReason about the time complexity of lookups in different collections

Concurrency and thread safety

A frequent source of subtle production bugs. Test shared-state reasoning and modern concurrency tools.

Explain a race condition in shared mutable state and how to prevent itChoose between synchronisation, concurrent collections, and an executor serviceExplain why immutability simplifies concurrent code

Exceptions and robustness

Deliberate error handling distinguishes production-ready Java.

Explain checked versus unchecked exceptions and when to use eachCritique a catch block that swallows exceptionsUse try-with-resources for safe resource cleanup

Modern Java and testing

Whether the candidate keeps current and writes verifiable code.

Rewrite an imperative loop as a stream pipeline and discuss readability trade-offsUse Optional to avoid a null-pointer riskWrite JUnit tests for a class, including edge cases, and explain mocking

Sample Java questions

What is the difference between an interface and an abstract class, and when would you use each?

Entry

Look for Strong: interfaces define a contract and allow multiple implementation, abstract classes share state and partial implementation; mentions default methods. Weak: confuses the two or gives no use case.

You need a collection with fast lookups by a key. Which collection do you choose and why?

Entry

Look for Strong: HashMap for average O(1) lookup, notes the equals/hashCode requirement, contrasts with TreeMap for ordering. Weak: picks a List and scans it, or cannot justify the choice.

Why must you override hashCode whenever you override equals?

Mid

Look for Strong: explains the contract that equal objects must have equal hash codes, and what breaks in hash-based collections otherwise. Weak: knows they are related but cannot explain the consequence.

Describe a race condition you might hit with shared mutable state, and how you would make the code thread-safe.

Mid

Look for Strong: concrete example, fixes with synchronisation, concurrent collections, atomics, or immutability, and weighs the trade-offs. Weak: vague or thinks adding synchronized everywhere is free.

What is the difference between checked and unchecked exceptions, and how do you decide which to use?

Mid

Look for Strong: checked for recoverable conditions callers should handle, unchecked for programming errors; warns against swallowing exceptions. Weak: treats all exceptions the same.

How would you design a thread-safe in-memory cache with expiry? Walk me through the trade-offs.

Senior

Look for Strong: discusses concurrent data structures, eviction, locking granularity versus contention, and existing libraries; reasons about correctness and performance. Weak: a single synchronized HashMap with no expiry plan.

When do you favour composition over inheritance, and what problems does deep inheritance cause?

Senior

Look for Strong: explains fragile base classes, tight coupling, and how composition keeps designs flexible and testable. Weak: defaults to inheritance for all reuse.

Critique this class that exposes mutable internal state and catches Exception generically. What would you change?

Senior

Look for Strong: spots the leaked mutable state (defensive copies or immutability), the overly broad catch that hides bugs, and proposes specific fixes. Weak: misses the encapsulation issue or only catches one problem.

Red flags

Defaults to deep inheritance hierarchies and cannot articulate composition trade-offs
Cannot explain the equals and hashCode contract or its impact on hash-based collections
Picks the wrong collection and cannot reason about lookup or insertion complexity
Has no real grasp of thread safety beyond adding synchronized everywhere
Catches Exception generically and swallows errors without logging or rethrowing
Knowledge appears frozen years ago, with no awareness of streams, Optional, or records
Strong only inside one framework and helpless writing plain Java

Scoring rubric

Criterion	Weight	What strong looks like
Object-oriented design	30%	Clear responsibilities, sensible interfaces, composition over inheritance, and testable structure.
Collections, generics, and complexity	20%	Chooses the right collection, respects equals/hashCode, and reasons accurately about complexity.
Concurrency and thread safety	20%	Reasons about shared state, picks appropriate concurrency tools, and values immutability.
Exceptions and robustness	15%	Handles exceptions deliberately, cleans up resources, and never silently swallows errors.
Modern Java, testing, and communication	15%	Uses current language features where they help, writes meaningful tests, and explains trade-offs.

Mistakes hiring teams make

Over-indexing on whiteboard algorithm puzzles instead of real object-oriented design
Equating years of Java experience with current, modern Java knowledge
Trusting enterprise brand-name resumes as proof of hands-on depth
Testing only framework-specific knowledge and never plain-language Java fundamentals
Skipping any concurrency check for roles that clearly involve shared state
Ignoring testing and exception-handling habits, which predict production reliability

Roles that need Java

Java DeveloperBackend EngineerSoftware EngineerAndroid DeveloperEnterprise Application DeveloperFull-Stack DeveloperMicroservices EngineerPlatform Engineer

Common questions

How do I tell if a Java developer's knowledge is current?

Ask how they would use modern features such as streams, Optional, or records, and whether they reach for composition and immutability. Long-experienced developers can still be excellent, but knowledge frozen a decade ago shows up as deep inheritance, manual loops everywhere, and no awareness of newer concurrency utilities or testing practices.

Should I test plain Java or a framework like Spring?

Start with plain Java. Object-oriented design, collections, concurrency, and exception handling transfer across every framework, while a candidate strong only in one framework often struggles without it. Add a framework-specific round when that framework is central to the role, but never let it substitute for verifying core language depth.

How do I keep a high-volume Java screen fair and cheat-resistant?

Use unique, per-candidate problems. An AI-generated assessment like Cohesyve's gives each candidate a different Java challenge in a live IDE with real test execution, scored objectively, so answers cannot be shared or pasted from the web. Your engineers then spend interview time only on candidates who already passed a genuine coding bar.

Is concurrency knowledge necessary for every Java hire?

Not for every role, but for most back-end and platform positions it is. Many Java systems handle concurrent requests, so subtle thread-safety bugs are expensive. Calibrate to the job: a junior maintaining a single-threaded app needs less, while anyone touching shared state should demonstrate sound reasoning about race conditions and safe design.

Cohesyve · Skill assessments for hiring

Test Java before the first interview

Generate a role-specific Java assessment from your job description and see who can do the work before you spend interview time on them.

1,500+

assessments completed

50%

faster time-to-hire

90%

completion rate

5 min

from JD to assessment

No credit card · 10 free candidates · Plans sized to your hiring volume

From the blog

Related skill guides