Free Java developer interview questions for small business owners: 6 sets by seniority, frameworks, stage, and culture, plus a scorecard. Download as DOCX.
Six question sets for the owner or manager running the interview: core Java, seniority levels, frameworks and build tooling, interview stages, culture, and situational judgment, each with good-answer notes and a rubric. Download as DOCX.
The hardest interview I have ever run was for a Java developer, and I was the least qualified person in the room to run it. The candidate talked confidently about the framework, the build, and the deployment pipeline, and I had no way to tell whether any of it was true. I hired on impression. It did not go well, and the lesson stuck: an owner can absolutely interview a developer, but not by pretending to grade the code.
These six question sets are built for the person on the employer side of that table. They cover core Java, the differences between junior, mid-level, and senior candidates, frameworks and build tooling, a three-stage process, culture and collaboration, and situational judgment, plus a full scorecard. Every question that needs one carries a note on what a good answer sounds like.
At FirstHR we build for owners and managers who make these hires themselves, with no technical panel and no recruiter. If you have not written the posting yet, start with the Java developer job description templates and come back here for the interview.
TL;DR
Interview a Java developer on six areas: fundamentals, frameworks and build tooling, code quality, debugging, judgment, and communication. You do not need to grade the Java. Judge whether answers stay specific under one more question, add one practical exercise, and score every candidate on the same rubric. Federal data puts the software developer median at $135,980 a year.
What a Java Developer Actually Works On
A Java developer at a small business writes and maintains the server-side software your product or operations depend on: the business logic, the APIs, the database work behind it, and the jobs and integrations that move data between systems. The federal occupation that covers this work is software developers, which groups the role regardless of language.
Knowing the shape of the job tells you what to ask about. Java is used most heavily for backend services and long-lived business systems, which means the interview should spend more time on data, reliability, and maintenance than on clever algorithms. The four areas below are where the actual hours go.
Backend services
Business logic behind your product or portal
APIs that other systems and apps call
Scheduled jobs, imports, and integrations
Data and persistence
Data models and schema changes over time
Queries, and keeping them from getting slow
Reporting and data corrections when things go wrong
Build and release
Dependency and build configuration
Automated tests that run before a merge
Getting a change from a branch into production
Support and incidents
Reproducing and diagnosing customer-reported bugs
Restoring service, then finding the root cause
Logging and monitoring so problems are visible
On a small team one person usually covers all four areas, plus talking to customers when something breaks. That is very different from a large platform team where each of those is somebody else’s specialty, and it should change what you weight in the interview.
Choosing the Right Question Set
Pick the set that matches the level and the stage you are at, then ask the same questions of every candidate for that role. The core set runs through all of them; each of the others adds the questions that fit a specific situation.
Core Java Questions
Start here
The base set for any Java hire: language fundamentals, collections, exceptions, memory, and threads, each with a note on what a good answer sounds like.
By Seniority Level
Junior, mid, senior
Separate blocks for junior, mid-level, and senior candidates, so you hold the bar you set before the interview rather than the one the candidate meets.
Frameworks and Build Tooling
The real stack
Dependency injection, configuration, persistence and the N+1 problem, migrations, build tools, tests, and how a change reaches production.
By Interview Stage
Screen, exercise, final
A three-stage process: a short screen, a code review or take-home exercise with scoring guidance, and a final technical and fit conversation.
Culture and Collaboration
Working style
Plain-language communication, handling unclear requirements, code review behavior, disagreement, and how they work when nobody is watching.
Situational and Scorecard
Judgment and rating
Incident, deadline, and inherited-codebase scenarios, plus the full six-area scorecard and a red-flag checklist to compare candidates on evidence.
Match the Set to the Situation
Any Java hire, first conversation: Core. Deciding between candidates at different levels: By Seniority. Checking whether they have really worked in your stack: Frameworks and Build Tooling. Designing the whole process: By Interview Stage. A small team where fit carries weight: Culture and Collaboration. The final round and the decision: Situational and Scorecard. Most small businesses use Core plus Frameworks in round one, then Situational plus the scorecard in the final round.
6 Free Java Developer Question Sets to Download
Download all six as one Word document or copy the sets you need. Each follows the same structure: when to use it, the questions with good-answer notes, a what-to-listen-for block, and a scoring rubric at the end. The situational set adds the full six-area scorecard and a red-flag checklist. Applicant tracking is coming soon to FirstHR, so for now these are built to be printed, filled in, and filed.
Download All 6 Java Developer Question Sets
Core Java, seniority levels, frameworks and build tooling, interview stages, culture, and situational judgment with a full scorecard. All in one DOCX.
Set 1: Core Java Questions
The base set for any Java hire: the JDK and JVM, equals and hashCode, collections, exceptions, memory leaks, and thread safety, each with a note on what a good answer sounds like. Start here.
Core Java Developer Interview Questions
CORE JAVA DEVELOPER INTERVIEW QUESTIONS
Candidate: __
Company: __
Interviewer: __
Date: _
HOW TO USE THIS SET
This is the starting set for most small businesses hiring a Java developer. Ask
8 to 10 of these questions. Every question that needs one carries a note on what
a good answer sounds like, so you can judge the response even if you do not write
Java yourself. Score on the rubric at the end, right after the interview.
LANGUAGE AND OBJECT-ORIENTED BASICS
1. Explain the difference between the JDK, the JRE, and the JVM.
(Good answer: the JVM executes bytecode, the JRE is the JVM plus the standard
libraries needed to run a program, and the JDK adds the compiler and developer
tools. Should sound understood, not memorized.)
2. What is the difference between == and .equals() for objects?
(Good answer: == compares references, .equals() compares whatever the class
defines as equality. A strong candidate mentions that comparing Strings with ==
is a classic production bug.)
3. If you override equals(), what else must you override, and why?
(Good answer: hashCode(), because hash-based collections such as HashMap and
HashSet depend on the two staying consistent with each other.)
4. When do you reach for an interface, and when for an abstract class?
5. Why are Java Strings immutable, and when do you use StringBuilder instead?
(Good answer: immutability makes strings safe to share and cache; StringBuilder
is for repeated concatenation, especially inside loops.)
COLLECTIONS AND DATA HANDLING
6. Walk me through how you choose between a List, a Set, and a Map.
7. When does ArrayList beat LinkedList, and when is it the other way around?
(Good answer: ArrayList for indexed access and for almost everything by
default; LinkedList only for heavy insertion or removal at the ends.)
8. What happens inside a HashMap when two keys land in the same bucket?
9. What did lambdas and the Stream API change about the way you write Java?
ERRORS, MEMORY, AND CONCURRENCY
10. Checked versus unchecked exceptions: what is the difference, and when do you
use each?
11. How do you decide whether to catch an exception, wrap it, or let it rise?
(Good answer: catch only where you can actually do something about it; never
swallow an exception silently.)
12. Java has garbage collection, so how does a Java application still leak memory?
(Good answer: references held longer than needed, static collections that keep
growing, unclosed resources, listeners that are never removed.)
13. Tell me about code you made thread-safe. What did you use and why?
(Good answer: names concrete tools such as immutable objects, synchronized
blocks, concurrent collections, or an executor service, and explains the
tradeoff rather than reciting a definition.)
WHAT TO LISTEN FOR
•Explains the concept plainly, then gives an example from real work
•Talks about tradeoffs instead of reciting textbook definitions
•Says "I do not know" and then reasons out loud toward an answer
•Names the actual class or tool, not just the general category
•Corrects themselves when they realize they were wrong
SCORING RUBRIC
5 = Strong, specific evidence 4 = Solid evidence 3 = Some evidence
2 = Weak or mixed evidence 1 = No evidence or red flags
Separate blocks for junior, mid-level, and senior candidates, because the same answer means different things at different levels. Decide the level first, then use the matching block.
Dependency injection, environment configuration, the N+1 query problem, schema migrations, build tools, test suites, and how a change actually reaches production. Cross out anything not in your stack.
Frameworks and Build Tooling Questions
JAVA FRAMEWORKS AND BUILD TOOLING QUESTIONS
Candidate: __
Our stack: __
Interviewer: __
WHEN TO USE THIS SET
Very little commercial Java is written with the language alone. Most business
applications run on a framework, talk to a database through a persistence layer,
and are assembled by a build tool. This set checks whether the candidate has done
real work in that ecosystem or has only seen it from a distance. Cross out
anything that is not in your stack before the interview.
FRAMEWORK AND DEPENDENCY INJECTION
1. What does dependency injection actually buy you?
(Good answer: loose coupling and code you can test without standing up the
whole application. Constructor injection preferred over field injection, with
a reason.)
2. What does auto-configuration do in a Spring Boot application, and how do you
override it when the default is wrong?
3. How do you keep configuration separate per environment, and where do secrets
live?
(Good answer: profiles and externalized configuration; secrets never committed
to the repository.)
4. Walk me through how a request travels from an HTTP endpoint to the database
and back in your last application.
PERSISTENCE AND DATA
5. What is the N+1 query problem, and how do you find and fix it?
(Good answer: one extra query per parent row instead of a single join or batch
fetch. Finds it by looking at generated SQL or query counts, fixes it with a
fetch join or batching, not by guessing.)
6. How do you manage database schema changes across environments?
(Good answer: versioned migration scripts checked into the repository, applied
in order, never a manual change on the server.)
7. Where do you put transaction boundaries, and what goes wrong when you get
them wrong?
BUILD, TESTING, AND DELIVERY
8. Which build tool have you used most, and what do you like and dislike about it?
(Good answer: real experience with at least one of the common ones, can explain
the build lifecycle and how dependencies are resolved. Tool preference matters
far less than whether they understand the build.)
9. How do you stop dependency versions from drifting across a project?
10. What does your test suite look like, and what runs on every commit?
(Good answer: fast unit tests on every commit, slower integration tests
somewhere, and an honest answer about coverage rather than a made-up number.)
11. How do you handle logging so that a production problem is diagnosable?
12. Walk me through how your last team got a change from a branch into production.
WHAT TO LISTEN FOR
•Concrete, first-hand detail about their own project, not a tutorial summary
•Understands why the framework does what it does, not only which annotation
•Treats tests, migrations, and logging as part of the job, not extras
•Can say which parts of their stack they chose and which they inherited
SCORING RUBRIC
Framework depth [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Persistence and data handling [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
A three-stage process: a short screen, one practical exercise with a ready-made code-review setup and scoring guidance, and a final technical and fit conversation with pass criteria for each stage.
Questions by Interview Stage
JAVA DEVELOPER QUESTIONS BY INTERVIEW STAGE
Candidate: __
Interviewer: __
WHEN TO USE THIS SET
Three stages are enough for a small business, and a fourth usually costs you good
candidates. Use the same three stages, in the same order, for everyone applying
to the same role. Decide in advance what a pass looks like at each stage so the
decision is not made on impression alone.
STAGE 1: PHONE OR VIDEO SCREEN (20 TO 30 MINUTES)
Goal: confirm the basics, the level, and the practical details before anyone
invests more time.
1. Tell me about the Java work you have done in the last couple of roles.
2. What is your stack day to day, and which parts do you know deepest?
3. What kind of problem do you most want to be working on next?
4. What are you looking for in salary, and what is your timeline?
5. Do you have any restriction that would affect this role, such as a notice
period or a non-compete you are still under?
Pass criteria: the experience is real and at the right level, the stack overlaps
with yours, and the pay expectation is inside your range.
STAGE 2: PRACTICAL EXERCISE (CODE REVIEW OR SHORT TAKE-HOME)
Goal: see how they actually work. Keep it to about two hours of candidate time,
and pay for it if it is longer.
Option A, code review (recommended, costs the candidate the least):
Send a small piece of Java with three or four deliberate problems, such as a
mutable field exposed by a getter, a swallowed exception, an equals() without
hashCode(), and a query inside a loop. Ask them to review it in writing or live.
1. What would you change first, and why?
2. Which of these would you block a merge over, and which is a comment?
3. What would you test here?
Option B, short take-home:
Give a small, self-contained problem close to real work: an endpoint, a data
transformation, or a bug in a tiny repository. Ask for tests and a short readme.
Score the exercise on: correctness, readability, tests, and the quality of the
explanation. A clean, well-tested simple solution beats a clever unclear one.
STAGE 3: TECHNICAL AND FINAL CONVERSATION
Goal: depth, judgment, and fit, with the founder or hiring manager in the room.
1. Walk me through your exercise. What did you leave out and why?
2. Pick the hardest bug you have fixed and take me from symptom to root cause.
3. How would you approach the first month here?
4. What would make you leave a job like this within a year?
5. What questions do you have about the business, not the code?
Pass criteria: depth holds up under follow-up questions, judgment fits the size
of your team, and their questions show real interest in the business.
WHAT TO LISTEN FOR
•Consistency across the three stages, with no story that changes
•Better answers under follow-up, not vaguer ones
•Interest in the problem your business solves, not only the technology
•A short, respectful process on your side keeps strong candidates in it
SCORING RUBRIC
Screen: level and stack match [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Final: motivation and fit [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Total: ______ / 25
NOTES
__
Set 5: Culture and Collaboration Questions
Plain-language communication, unclear requirements, code review behavior, disagreement, and how they work when nobody can see the screen. On a small team this set carries more weight than it would elsewhere.
Culture, Collaboration, and Remote Questions
CULTURE, COLLABORATION, AND REMOTE WORK QUESTIONS
Candidate: __
Company: __
Interviewer: __
WHEN TO USE THIS SET
On a small team a developer is not one voice among many. They will talk to
customers, argue with you about scope, and carry a pager. This set checks working
style and collaboration. Ask about behavior and evidence, never about protected
characteristics such as race, color, religion, sex, national origin, age,
disability, or genetic information.
WORKING WITH THE BUSINESS
1. Explain something technical you built to me as if I were a customer.
(Good answer: plain language, no jargon, checks whether the listener followed.
This is the single most useful signal for a small business hire.)
2. Tell me about a time the requirements were unclear. What did you do?
(Good answer: asked, wrote down an assumption, and confirmed it, instead of
guessing quietly for two weeks.)
3. How do you push back when someone asks for something you think is a bad idea?
4. Describe a time you had to cut scope to hit a date. How did you decide what
to cut?
TEAM AND CODE REVIEW
5. What makes a code review comment useful rather than annoying?
6. Tell me about disagreeing with a teammate on a technical decision. How did it
end?
(Good answer: describes the other position fairly. Candidates who cannot state
the opposing view charitably tend to be hard to work with.)
7. What does good documentation look like on a small team?
8. How do you like to receive feedback on your work?
REMOTE AND AUTONOMY
9. How do you keep others informed when nobody can see what you are working on?
10. What hours do you work best, and how much overlap can you offer us?
11. Tell me about a week where you had no direction. What did you do?
12. What kind of manager gets the best work out of you?
WHAT TO LISTEN FOR
•Explains technical work without jargon and checks for understanding
•Asks questions rather than guessing at unclear requirements
•States the other side of a disagreement fairly
•Communicates proactively without being chased
•Interested in the customer problem, not only the stack
Set 6: Situational Questions, Scorecard, and Red Flags
Outage, deadline, and inherited-codebase scenarios, plus the full six-area scorecard and a red-flag checklist so you compare candidates on evidence rather than on which conversation felt best.
Situational Questions, Scorecard, and Red Flags
SITUATIONAL JUDGMENT QUESTIONS, SCORECARD, AND RED FLAGS
Candidate: __
Company: __
Interviewer: __
Date: _
WHEN TO USE THIS SET
Situational questions put the candidate inside a situation your business will
actually produce, then let you compare answers side by side. Ask the same three
or four of everyone for the role. There is no single correct answer; you are
scoring the reasoning, the priorities, and the honesty.
SITUATIONAL QUESTIONS
1. Production is down and customers are calling. Walk me through your first
thirty minutes.
(Good answer: restore service first, gather evidence while doing it, then find
the root cause afterward. Communicates status to the business as it goes.)
2. You are two days from a promised launch date and the feature is not ready.
What do you tell me, and when?
(Good answer: tells you early, brings options such as cutting scope or moving
the date, and does not quietly hope it will be fine.)
3. You inherit a codebase with no tests and no documentation. What are your first
two weeks?
(Good answer: reads before rewriting, gets it building and running, adds tests
around whatever gets touched next. A candidate who wants to rewrite everything
in week one is a risk on a small team.)
4. A change you shipped caused a data problem that a customer noticed. What
happens next?
(Good answer: contains it, tells the business immediately, fixes it, then adds
the check that would have caught it. No blame-shifting.)
5. I ask for something that will take three weeks and I want it in one. How do
you handle that conversation?
6. You are the only developer here. Which parts of the work would you insist on
keeping, and what would you outsource?
7. A dependency you rely on has a known security issue. What do you do, and how
fast?
WHAT TO LISTEN FOR
•Puts customers and service restoration ahead of being right
•Communicates bad news early and with options attached
•Respects existing code before proposing to replace it
•Owns mistakes without steering the story toward someone else
•Weighs business cost, not only technical elegance
FULL SCORECARD
Score each area 1 to 5 immediately after the interview, while it is fresh, and
anchor every score to something the candidate actually said. If more than one
person interviews, each scores independently before comparing. Use the identical
scorecard for every candidate for the role.
5 = Strong, specific evidence 4 = Solid evidence 3 = Some evidence
2 = Weak or mixed evidence 1 = No evidence or red flags
Java fundamentals
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Frameworks and build tooling
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Code quality and testing
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Debugging and problem solving
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Judgment under pressure
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
Communication with non-developers
Score [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
Evidence: ______
RED FLAGS (WEIGH CAREFULLY)
[ ] Cannot describe their own contribution to a project in specific terms
[ ] Blames every past problem on managers, teammates, or "the legacy code"
[ ] Wants to rewrite everything before understanding anything
[ ] Treats tests, code review, or documentation as somebody else’s job
[ ] Cannot explain a technical idea without jargon
[ ] Buzzword fluency with no depth behind any of it
[ ] Dates, titles, or responsibilities that shift between conversations
How to Judge Java Skill If You Are Not a Developer
You do not need to grade the Java; you need to tell a strong answer from a weak one. The pattern is consistent across technical interviews: strong answers are specific, name the actual tool or class, describe a tradeoff, and get more detailed when you ask a follow-up question. Weak answers get vaguer under the same pressure.
Three questions carry more signal than the rest, and each has a clear tell. Read the strong and weak versions below before the interview, and you will hear the difference in real time.
If you override equals(), what else must you override, and why?
Strong answer: Says hashCode(), and explains that hash-based collections such as HashMap and HashSet rely on the two staying consistent, so overriding one without the other produces objects that go missing from a set or a map. A strong candidate has been bitten by this and can describe the symptom.
Weak answer: A weak answer names hashCode() with no idea why, or does not connect it to collections at all. Recognizing the mechanism matters more than the keyword.
Java has garbage collection, so how does an application still leak memory?
Strong answer: Explains that garbage collection only frees objects nothing references, so anything the application keeps a reference to stays alive: static collections that grow forever, caches with no eviction, unclosed resources, listeners that are never unregistered. Points at a real case they investigated.
Weak answer: A weak answer says Java cannot leak memory, or repeats that the garbage collector handles it, with no notion of held references.
Tell me about a bug that reached production. How did you find the cause?
Strong answer: Walks a real path: the symptom, how they reproduced it, how they narrowed the search, the actual root cause, the fix, and the test or check added afterward so it cannot come back quietly. Owns their part in it.
Weak answer: A weak answer has no specifics, blames someone else, or ends at the fix with no mention of prevention. Vagueness here almost always means it did not happen the way it is being told.
Two habits make the rest easier. Ask one more question after every answer, because depth is what separates real experience from a memorized definition. And ask the candidate to explain something technical to you as if you were a customer, since a developer who cannot do that will be expensive to work with on a small team.
The Cheapest Technical Check You Can Run
Send a small piece of Java with three or four deliberate problems in it: a mutable field exposed by a getter, a swallowed exception, an equals() with no hashCode(), and a query inside a loop. Ask the candidate what they would change first, what would block a merge versus be a comment, and what they would test. It takes under an hour, it is close to real daily work, and you can score it against a list you wrote in advance. If you know a developer outside the company, have them write the sample and sit in on the final round.
Frameworks and Build Tooling
Very little commercial Java is written with the language alone, so framework and build-tool experience is where a resume most often overstates reality. Ask about the specific stack the candidate claims, and listen for first-hand detail about their own project rather than a tutorial summary.
Ask
What a strong answer includes
What does dependency injection actually buy you?
Loose coupling and testable code; prefers constructor injection and can say why
How does auto-configuration work, and how do you override it?
Sensible defaults wired from what is on the classpath, overridden deliberately
How do you configure settings per environment?
Profiles and externalized configuration; secrets never committed to the repository
What is the N+1 query problem and how do you fix it?
One query per parent row instead of a join or batch fetch; finds it in the generated SQL
How do you manage database schema changes?
Versioned migration scripts in the repository, applied in order, never manual edits
Which build tool have you used most, and why?
Real experience with one; explains the build lifecycle and dependency resolution
Tool preference matters far less than whether the candidate understands the build. Someone fluent in one common build tool learns the other quickly; someone who has never looked inside the build file will struggle the first time a dependency conflict blocks a release. The same goes for tests, migrations, and logging: treat them as part of the job in the interview, and you will get a developer who treats them that way afterward.
Junior, Mid-Level, and Senior Candidates
Level is about scope of ownership, not years on a resume. Decide which level you are hiring before the first interview and write down what a pass looks like, because the most common mistake is quietly moving the bar to fit whoever you liked best.
Signal
Junior
Mid-level
Senior
Writes correct code with guidance and review
Owns a feature end to end without hand-holding
Debugs a production problem to root cause alone
Designs the data model and API for new work
Sets testing and release standards for the team
Score juniors on reasoning, curiosity, and how they handle not knowing, and expect to invest in them. Score mid-level candidates on ownership of a whole feature, testing instinct, and debugging method. Score seniors on tradeoffs, scope judgment, and the willingness to describe a decision that turned out to be wrong, which is the fastest way to separate real seniority from a long tenure.
Red Flags in the Interview
The most reliable red flags are behavioral, not technical, which is good news if you are not a developer. A candidate can be rusty on one language detail and still be excellent; a candidate who cannot describe their own contribution or who blames everyone they have worked with is telling you exactly what the next year will look like.
Cannot describe their own contribution
Everything is what the team did. Ask what they personally wrote, what decision was theirs, and what they would change now. A real contributor answers in seconds.
Everything was somebody else’s fault
Past managers, past teammates, and the legacy code all failed them. One tough story is normal; a pattern across every job predicts how they will describe your company next.
Wants to rewrite before understanding
A candidate whose first instinct on any existing codebase is a full rewrite is expensive on a small team. Strong candidates read first and improve in place.
Treats tests and review as optional
Testing, code review, and documentation described as things that slow real work down. On a small team there is nobody else to catch what they miss.
Buzzwords with nothing behind them
Fluent in the vocabulary until you ask a follow-up question. The tell is that answers get vaguer under probing instead of more specific.
Details that move between conversations
Dates, titles, or scope of responsibility that shift between the screen and the final round. Confirm with a reference check before you decide.
None of these is disqualifying on its own, and one difficult past job is normal. A pattern across several is the signal. When something does not add up, resolve it with a reference check rather than a hunch, and read the broader interview red flags guide for the non-technical warning signs that apply to any role.
Scoring the Interview
Score every candidate on the same six areas, from 1 to 5, immediately after the interview while it is fresh, and anchor each score to something the candidate actually said. If two people interview, each scores independently before comparing notes, so the more confident voice does not set the answer for both.
Scoring area
What a 5 looks like
Java fundamentals
Explains concepts plainly, with tradeoffs and examples from real work
Frameworks and build tooling
First-hand work in a comparable stack, understands the build
Code quality and testing
Writes tests by default and can justify what to test and what not to
Debugging and problem solving
Walks a real incident from symptom to root cause and prevention
Judgment under pressure
Restores service first, communicates early, weighs business cost
Communication with non-developers
Explains technical work to an owner without jargon
Using the same questions and the same scorecard for every candidate is the core of a structured interview, and it is also your best defense if a hiring decision is ever challenged. Keep every question job-related and apply it consistently; the EEOC guidance on prohibited employment policies is the reference for what stays off the table, including race, color, religion, sex, national origin, age, disability, and genetic information.
Turn the scores into a decision the same day. A completed interview evaluation form per candidate, plus a short written interview feedback note, gives you a comparable record instead of six half-remembered conversations.
Java Developer Pay
Java developers sit among the higher-paid occupations, so decide your range before the screen rather than after you have fallen for a candidate. Use federal data as the anchor, then adjust for your metro, the level, and the specialization.
Median $135,980 a Year (BLS OEWS, May 2025)
According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), software developers had a median annual wage of $135,980, about $65.38 an hour, with the lowest 10 percent under $82,460 and the highest 10 percent over $214,670 (U.S. Bureau of Labor Statistics). The separate BLS employment projections program projects 15 percent growth for software developers, quality assurance analysts, and testers from 2024 to 2034, with about 129,200 openings a year.
Location moves that number hard in both directions, and a remote hire in a lower-cost market can be well below the national median while a major technology metro runs well above it. Budget for total cost rather than base salary: payroll taxes, benefits, equipment, and tooling all add up on top.
Classification: Usually Exempt, but Check the Duties
A Java developer is normally exempt under the FLSA computer employee exemption, which covers software engineers and similarly skilled workers whose primary duties are systems analysis, program design, and software development. The employee must be paid on a salary or fee basis of at least $684 per week, or hourly at a rate of at least $27.63 an hour (DOL Fact Sheet 17E). Pay for this role usually clears the threshold easily, so the duties are what matter. State law can be stricter. This is general information, not legal advice.
If you are weighing a full-time hire against a contractor for a first build, the classification question deserves a real answer up front, since the employee versus contractor line is decided by the facts of the working relationship rather than by what the agreement is called.
Hiring a Java Developer as a Small Business
A large company runs this interview with a technical panel, a recruiter, and a calibrated rubric. You are running it between everything else, probably without a developer on staff. That reality changes the process, and it is where the avoidable mistakes happen.
You are hiring a Java developer without being one yourself
Most owners running this interview cannot grade the Java. You do not have to. What you can grade is whether an answer is specific, whether it holds up when you ask one more question, and whether the person can explain the work to you at all. That is why every question in these kits that needs one carries a note on what a good answer sounds like. Add one practical exercise, a code review or a short take-home, and you have covered most of what a technical panel would have caught. If you have a friendly developer in your network, borrowing them for forty-five minutes on the final round is the cheapest quality control available.
The developer you hire will be one of very few, or the only one
At a large company a new developer joins a team that already has standards, reviewers, and an on-call rotation. At a small business the hire often is the standard. That changes what you interview for: judgment about scope, willingness to work on unglamorous maintenance, comfort talking directly to customers, and the discipline to write tests when nobody is enforcing it. A brilliant specialist who has only ever worked inside a large, well-staffed platform team can struggle badly here, while a solid generalist who has shipped whole features alone often thrives. Weight the situational and culture sets accordingly.
A long, sloppy process loses the candidates you want
Java developers with real experience are rarely short of options, and the process itself is part of your offer. Three stages is enough: a short screen, one practical exercise capped at about two hours, and a final conversation. Tell candidates the stages and the timeline up front, give feedback fast, and pay for any exercise that runs long. Run the same questions and the same scorecard for everyone, which is both fairer and easier to defend later. Applicant tracking is coming soon to FirstHR, and until it ships a shared spreadsheet with one row per candidate and one column per scoring area is enough to keep a small hiring process honest.
One more thing worth saying plainly: the strongest signal on a small team is not the deepest Java answer. It is the candidate who can explain the work to you, tell you when a date is at risk, and improve code they did not write. Weight the culture and situational sets accordingly, and compare them against the general interview questions to ask candidates you would use for any role.
From Interview to Onboarding
Once you choose someone, a developer hire has two extras most roles do not: an intellectual-property assignment agreement signed before the first commit, and deliberate access decisions across the repository, the build system, and production. Get both right on day one and you avoid the two problems that are painful to fix later.
Offer, NDA, and IP assignment
Confirm role, level, and pay in writing, and have the developer sign a confidentiality and intellectual-property assignment agreement before the first commit.
Access on day one
Repository, build system, ticket tracker, staging, and any production access, granted deliberately and with the least privilege that lets them work.
A first-week plan
A small real change shipped in week one beats a week of reading. Pair the plan with the person who knows the codebase best, even if that is you.
Store the paperwork
Signed offer, agreements, I-9, W-4, and policy acknowledgments kept together and easy to find later.
The rest is standard: the offer, a confidentiality agreement, and the usual new-hire paperwork including the I-9 and W-4, followed by a structured first week. FirstHR connects the offer, the agreements, e-signature, document storage, and the access-and-policy checklist in one place, so a small business can bring a developer on without a folder of scanned PDFs. Applicant tracking is coming soon to FirstHR. An onboarding template gives the first week a shape, and shipping one small real change in week one beats a week of reading documentation.
Key Takeaways
Score a Java developer on six areas: fundamentals, frameworks and build tooling, code quality, debugging, judgment, and communication.
You do not need to grade the Java; judge whether answers are specific and whether they hold up under one more follow-up question.
Add one practical exercise, and prefer a code review of a small sample with deliberate problems over a long take-home.
Decide the level before the interview, because the common mistake is moving the bar to fit whoever you liked most.
The most reliable red flags are behavioral: no specifics, blame in every story, and a rewrite instinct before understanding.
Federal data puts the median for software developers at $135,980 a year, about $65.38 an hour (BLS OEWS, May 2025).
Frequently Asked Questions
What questions should I ask when hiring a Java developer?
Ask questions that test language fundamentals, framework and build-tool experience, code quality, debugging, and judgment. Strong core questions include: explain the difference between the JDK, the JRE, and the JVM; what is the difference between == and .equals(); if you override equals(), what else must you override and why; Java has garbage collection, so how does an application still leak memory; and tell me about a bug that reached production and how you found the cause. Add framework questions on dependency injection, configuration per environment, the N+1 query problem, database migrations, and the build tool your project uses. Finish with situational questions about an outage, a slipping deadline, and inheriting an untested codebase. This page has six ready-to-use sets plus a scorecard, and every question that needs one carries a note on what a good answer sounds like.
How do I interview a Java developer if I am not technical?
You can run a good interview without writing code yourself. You are not grading the Java; you are grading whether an answer is specific, whether it survives one more follow-up question, and whether the candidate can explain their work to you plainly. Use the good-answer notes in each kit as your reference, and treat vagueness that increases under probing as the main warning sign. Add one practical exercise: send a small piece of Java with a few deliberate problems in it and ask the candidate to review it, or give a short take-home with tests. Then judge correctness, readability, tests, and the explanation. If you know a developer outside the company, bringing them into the final round for forty-five minutes is the cheapest quality control you can buy.
What should a Java developer interview process look like?
Three stages is enough for a small business, and a fourth usually costs you candidates. Stage one is a short screen of twenty to thirty minutes confirming the experience is real, the stack overlaps with yours, and the pay expectation fits your range. Stage two is one practical exercise capped at about two hours of candidate time: either a code review of a small piece of Java containing deliberate problems, or a short take-home with tests and a readme. Pay for anything longer. Stage three is a technical and fit conversation with the founder or hiring manager, walking through the exercise and pushing on depth and judgment. Tell candidates the stages and the timeline up front, use the same questions and the same scorecard for everyone, and give feedback quickly.
What is the difference between a junior, mid-level, and senior Java developer?
The difference is scope of ownership, not years on a resume. A junior developer writes correct code with guidance and review, and should be scored on reasoning, curiosity, and how they handle not knowing something. A mid-level developer owns a feature end to end, from requirements through release, has a real opinion about what to unit test versus cover with an integration test, and can debug a production problem to root cause. A senior developer designs the data model and API for new work, weighs technical debt against shipping, reviews others productively, and sets testing and release standards, which matters enormously when they are one of very few developers you have. Decide the level before the interview and hold that bar, rather than moving it to fit whoever you liked most.
Should I give a Java coding test or a take-home assignment?
Give one practical exercise, and prefer a code review over a long take-home. Send a small piece of Java containing three or four deliberate problems, such as a mutable field exposed by a getter, a swallowed exception, an equals() implementation with no hashCode(), and a query inside a loop. Ask what the candidate would change first, what would block a merge versus be a comment, and what they would test. It takes under an hour, it is close to real daily work, and it is much easier for you to score than raw code. If you prefer a take-home, keep it to about two hours, make it a self-contained problem near the real job, ask for tests and a short readme, and pay for anything longer. Score correctness, readability, tests, and the explanation.
What are red flags in a Java developer interview?
The most reliable red flags are behavioral rather than technical. Watch for a candidate who cannot describe their own contribution in specific terms and only speaks about what the team did; who blames every past problem on managers, teammates, or the legacy code; whose first instinct on any existing codebase is a full rewrite before understanding it; who treats tests, code review, and documentation as somebody else’s job; who is fluent in buzzwords but gets vaguer rather than more specific under follow-up questions; and whose dates, titles, or responsibilities shift between conversations. Refusing to ever say I do not know is also a warning sign, because it usually means you cannot trust the confident answers either. Verify anything inconsistent with a reference check before you make a decision.
How much does a Java developer cost to hire?
Java developers sit among the higher-paid occupations, and the closest federal category is software developers. According to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025), software developers had a median annual wage of $135,980, about $65.38 an hour, with the lowest 10 percent under $82,460 and the highest 10 percent over $214,670. Pay varies sharply by location, seniority, and specialization, with major technology metros well above the national median and remote hires in lower-cost markets often below it. Budget for total cost rather than base salary alone: payroll taxes, benefits, equipment, and software licenses all add up. Use the federal figures as a floor for your thinking, then benchmark to your metro and to the specific level you are hiring. This is general information, not compensation advice.
Is a Java developer exempt from overtime?
In most cases yes, under the Fair Labor Standards Act computer employee exemption, which covers computer systems analysts, programmers, software engineers, and similarly skilled workers whose primary duties involve systems analysis, program design, and software development. To qualify, the employee must be paid on a salary or fee basis at a rate of at least $684 per week, or on an hourly basis at a rate of at least $27.63 an hour, and the duties test must genuinely be met. Because pay for this role typically runs well above the salary threshold, the compensation part is rarely the issue; the duties are what matter. Classification follows the actual work, not the job title, and state law can be stricter than the federal rule. Confirm the classification against the real duties, and check your state. This is general information, not legal advice.
