Java Software Engineer Interview Questions and Scorecard
Six question sets for the employer running the interview without a CTO or an HR department: service ownership, boundaries and API contracts, JVM incident evidence, running Java in production, leveling from junior to staff, and a weighted scorecard. Every question states why it is worth asking and what a strong answer sounds like. Download as DOCX.
The hard part of hiring a Java software engineer at a small business is that the work you are buying is invisible for about a year. The code arrives quickly. The consequences of how it was structured arrive much later, usually to somebody else, and by then the person who made those calls has moved on.
At FirstHR, we build for owners and managers who make this hire themselves, without an HR department and usually without a CTO. These six sets cover service ownership, boundaries and API contracts, JVM incident evidence, running Java in production, leveling from junior to staff, and a weighted scorecard. Every question states why it is worth asking and what a strong answer sounds like.
TL;DR
Interview a Java software engineer on five things: what they personally built and still run, where they think code belongs and how they change a contract other systems call, how they diagnose a JVM problem from real evidence, how they operate the service in production, and how plainly they explain any of it. Two questions almost nobody asks carry the most signal: how much of a two gigabyte container limit goes to the heap, and what would you have logged in advance so today’s incident took ten minutes. Use federal wage data as a baseline: a median of $135,980 for software developers. Download six sets and a weighted scorecard as DOCX.
What to Assess in a Java Software Engineer
Assess five things: what the candidate has personally built and run in Java, how they decide where code belongs, how they read production evidence when something breaks, how they operate the service after it ships, and how clearly they explain all of it to somebody who does not write code. Every other Java topic is a detail of one of those five.
Notice what is missing. Language trivia, framework quizzes, and puzzles with one clever trick predict very little about whether someone will keep your system correct and running. They survive because they are easy to grade, not because they work, and a small employer has no reason to inherit that habit from companies with entirely different problems.
Ownership signals
Names the service, the callers, and the numbers
Separates their work from the team's in seconds
Knows what broke after they handed it over
Boundary judgment
Argues against a split as readily as for one
Adds before removing on a published contract
Designs what happens when a dependency fails
Production evidence
Reads a dump or a graph before theorizing
Says which answer is a stopgap
Owns an incident they personally caused
Red flags
Rewrite proposed before reading the code
More memory offered before any measurement
Answers get vaguer under follow up
The most useful move in any of these areas is to follow up until the answer becomes concrete. Which service, how many users, how long did the fix take, what did you change first. Strong engineers get sharper under that pressure because they were actually there. Weaker candidates get vaguer, and the difference usually shows within two follow-ups.
Decide the Scope Before You Interview
Write down what the engineer must own in their first ninety days before you speak to anyone, because scope decides which sets you weight and what you should pay. The common small-business mistake is interviewing for a generic Java engineer and then discovering the role was really about keeping one aging application alive, or really about splitting it.
What the role is really about
Weight these sets
The question that decides it
One long-lived application you cannot afford to break
Ownership, running in production
What do you do in your first three days in a codebase you have never seen?
Splitting or joining services
Boundaries and API contracts
What would make you leave part of the application alone?
A system that must stay up during business hours
JVM evidence, running in production
What did the thread dump tell you, and what did you check second?
A contract other companies or teams call
Boundaries, ownership
How do you change an endpoint somebody else already calls?
Your first and only engineer
All six, running in production weighted highest
What happens the week you take a vacation?
Scope also settles the title question, which matters more here than in most roles. A Java developer interview leans toward delivery inside an existing structure, while these sets lean toward owning the system and its production behavior. If the role is explicitly senior, the senior Java questions go deeper on mentoring and modernization than the leveling set here does.
Both Directions Are Expensive
Paying senior rates for mid-level judgment is the failure everyone anticipates. The one that catches small businesses more often is hiring a junior Java engineer into a role with nobody available to review their work, because the budget fit felt right. That arrangement fails the business and it is unfair to the person, who needed a reviewer and received a production system instead. If nobody here can look at their work weekly, do not hire at that level.
The Six Question Sets
Use the ownership screening set with every candidate, then pick the rest based on what the engineer will actually own. For a first and only engineer, the two sets about production behavior matter more than anything else you could test.
Service Ownership Screening
Every candidate
What Java system they own, which part was theirs, which version it runs on, and how they get productive in code they did not write. Eight questions, all levels.
Boundaries and API Contracts
Anyone who decides where code goes
When to split an application and when not to, shared library against shared service, changing a contract other systems call, timeouts, queues, and failure design.
JVM Incidents and Evidence
Artifacts, not stories
A thread dump, a rising memory graph, a slow tail. The candidate reads the evidence in front of them, which is far harder to borrow than an incident story.
Running Java in Production
The set nobody else asks
Heap inside a container limit, a platform kill against an application error, connection pools times instances, graceful shutdown, health checks, and secrets.
Leveling: Junior to Staff
Your bar, not their title
One calibration question asked of everyone with a written expectation per band, plus level specific questions from junior through staff.
Scorecard and Red Flags
Score, do not guess
A weighted 1-to-5 rubric with space for written evidence, a ten item red flag checklist, and a level check to run before any offer goes out.
Which Sets to Use for Which Hire
First and only engineer: ownership, JVM evidence, running in production, and the scorecard. Adding to an existing team: ownership, boundaries, and leveling. A contractor for a defined project: ownership, boundaries, and the handover questions inside the production set. A junior hire with a reviewer available: ownership and leveling, scored against the junior expectation. Use the scorecard with every combination, and pair the result with the level you actually posted in the Java developer job description.
6 Free Question Sets to Download
Download all six as a single Word document, or copy the individual sets you need. Each follows the same structure: when to use it, the questions with a stated reason for asking and what a strong answer sounds like, what to listen for, and space for notes. Fill in the blanks and use them as they are.
Download All 6 Java Software Engineer Question Sets
Service ownership, boundaries and API contracts, JVM incident evidence, running Java in production, leveling from junior to staff, and a weighted scorecard with red flags. All in one DOCX.
Set 1: Java Service Ownership Screening Questions
The opening set for every candidate at every level: which Java system they own, which part was theirs, which version it runs on, and how they get productive in code they did not write. Start here.
Java Service Ownership Screening Questions
JAVA SOFTWARE ENGINEER INTERVIEW: SERVICE OWNERSHIP SCREENING
Candidate: __
Interviewer: __
Date: __
WHEN TO USE THIS SET
Use this set with every candidate at every level, in the first conversation. It
is not a Java knowledge quiz. It establishes what the person has actually owned
in a running Java system, which is the single fact the rest of the interview
depends on. Twenty five minutes is enough.
QUESTIONS, WHY THEY ARE WORTH ASKING, AND WHAT A GOOD ANSWER SOUNDS LIKE
1. Describe a Java service you own today. What does it do, who calls it, and
how many people work on it?
Why ask: it sets the scale of everything that follows. An engineer from a
fifty person platform team and an engineer who is the only person on call
have very different habits, and neither is wrong for your business.
Good answer: concrete and bounded. The service does one describable thing,
the callers are named, the traffic has a rough number attached, and the team
size is honest.
Weak answer: a list of technologies with no description of what the system
does for anyone.
2. On that system, what did you personally write and what did somebody else
write?
Why ask: the highest yield question in any engineering interview, and the
one candidates rehearse least. It separates a contributor from a passenger.
Good answer: a clean line. This module was mine, that one I reviewed, this
decision I argued against and lost. Specific within seconds.
Weak answer: everything is "we," and the line never gets drawn even after
you ask twice.
3. Which Java version does it run on, and who decided that?
Why ask: it tells you whether the candidate follows the platform or inherits
whatever the employer was stuck on, and it opens the upgrade conversation
without asking a trivia question.
Good answer: names the version, knows whether it is a long term support
release, and can say what would be involved in moving. An honest "we are on
an old version and here is why" is a fine answer.
Weak answer: does not know, and shows no curiosity about why not.
4. You join a Java codebase you have never seen. What do you do in the first
three days?
Why ask: at a small company this is literally the first week of the job.
Good answer: run it locally, follow one real request from the entry point to
the database, read the tests to learn the intent, ship one tiny change to
prove the path works. Asks who to talk to.
Weak answer: proposes a rewrite, or plans to read the whole codebase before
touching anything.
5. What is the last thing you shipped that a customer actually noticed?
Why ask: it pulls the conversation from architecture back to delivery.
Good answer: a real feature or fix, with what changed for the user and
roughly when it went out.
Weak answer: only internal work, indefinitely, with no user facing result in
recent memory.
6. What in that system would you change if you had a free week, and why has
nobody done it?
Why ask: the second half of the question is the good half. It surfaces how
the candidate thinks about constraints rather than just about quality.
Good answer: a specific change, a real cost estimate, and a clear-eyed reason
it has not happened: risk, priorities, or nobody understands that part.
Weak answer: "the whole thing should be rewritten in something modern."
7. How do you find out whether a change you shipped is working?
Why ask: it separates an engineer who ships from one who ships and watches.
Good answer: names something they look at after a release. Error rate, a
dashboard, a specific log line, a metric that would move. Says how long they
watch before moving on.
Weak answer: the tests passed and the deploy succeeded, so it works.
8. Which part of your current stack would you not choose again?
Why ask: it tests whether the candidate can criticize their own decisions
without blaming people.
Good answer: a specific technology or pattern, the reason it was chosen at
the time, and what they learned. Judgment without bitterness.
Weak answer: nothing, everything was right, or a complaint about a former
colleague.
WHAT TO LISTEN FOR
•A clear line between their work and the team's work
•Numbers attached to claims without being asked
•Curiosity about the version, the tooling, and the constraints
•Something shipped recently that a person outside engineering noticed
NOTES
__
__
Set 2: Service Boundary and API Contract Questions
For anyone who will decide where code belongs: when to split an application and when to leave it alone, shared library against shared service, changing a contract other systems call, timeouts, queues, and what happens when a dependency fails.
Service Boundary and API Contract Questions
JAVA SOFTWARE ENGINEER INTERVIEW: SERVICE BOUNDARIES AND API CONTRACTS
Candidate: __
Interviewer: __
Date: __
WHEN TO USE THIS SET
Use this set for anyone who will decide where code goes, which at a small
company is anyone above a junior. Boundary decisions are the ones you cannot
cheaply undo: a badly placed split costs you for years, and so does a single
application that nobody dares to change. Weight it heavily if the hire will be
your most senior engineer.
QUESTIONS, WHY THEY ARE WORTH ASKING, AND WHAT A GOOD ANSWER SOUNDS LIKE
1. We run one Java application that does everything. What would make you split
part of it out, and what would make you leave it alone?
Why ask: it is the defining judgment question for this role, and the answer
reveals whether the candidate reasons from your constraints or from a
conference talk.
Good answer: splits for a real reason. A piece with a different scaling
profile, a different failure tolerance, or a different team owning it.
Explicitly says that one application with clean internal boundaries beats
four services nobody can deploy independently, especially at a small company.
Weak answer: services are simply better, or the number of services is a
measure of maturity.
2. Two parts of the code need the same logic. When does that become a shared
library, and when does it become a service?
Why ask: Java teams reach for a shared jar by reflex, and shared jars create
version coupling that is invisible until it hurts.
Good answer: a library when the logic is stable and the callers can upgrade
on their own schedule; a service when the logic changes often, owns data, or
must be consistent everywhere at once. Mentions the cost of every caller
having to rebuild to pick up a fix.
Weak answer: always a library, or always a service, with no tradeoff named.
3. How do you change an endpoint that another system already calls?
Why ask: a published contract is a promise, and how a candidate treats it
predicts how many surprise outages you get.
Good answer: add before you remove. Ship the new field or endpoint, migrate
callers, then delete once nothing uses it. Knows how to find out who is
calling, and gives notice rather than announcing a breaking change on the
day.
Weak answer: version everything as v2 and hope, or change it and tell people
afterwards.
4. Service A calls service B, and B has become slow. What should A do?
Why ask: it tests whether the candidate has felt a cascading failure or only
read about one.
Good answer: a timeout that is shorter than the caller's own patience, a
limited number of retries with backoff, and a decision about what A returns
when B is simply unavailable. Bonus for saying that retries without a limit
turn one slow system into two dead ones.
Weak answer: retry until it works, or no timeout mentioned at all.
5. When would you put a queue between two parts of the system?
Why ask: queues solve real problems and create new ones, and the reasoning
matters more than the tool.
Good answer: when the work can be done later, when the load is spiky, or when
the caller should not wait. Names the cost too: ordering, duplicates, and the
need for the consumer to be safe to run twice on the same message.
Weak answer: queues everywhere for decoupling, with no mention of what
happens to a message that fails.
6. What belongs in the request, and what belongs in a background job?
Why ask: it is a daily decision in Java service work and a common source of
slow endpoints.
Good answer: the user waits only for what they need to see. Email, reports,
third party calls, and anything that can fail independently move out of the
request. Says how the user finds out that the background work finished.
Weak answer: everything in the request because it is simpler, with no view on
the response time cost.
7. What does your service return when the database is unavailable, and what does
the caller see?
Why ask: failure design is where most engineers stop thinking, and it is
exactly where a small business gets hurt.
Good answer: a deliberate answer. A clear error rather than a hang, a status
the caller can act on, no stack trace leaking to a user, and an alert firing.
Weak answer: has never thought about it, or assumes the framework handles it.
8. Tell me about a boundary you drew that turned out to be wrong.
Why ask: a claim you can verify, and one that senior candidates enjoy.
Good answer: names the split, why it seemed right, what went wrong (a chatty
interface, a shared database, a transaction that spanned both sides), and how
they merged or moved it back.
Weak answer: no example, or an example where the problem was entirely
somebody else's decision.
WHAT TO LISTEN FOR
•Reasons a split should NOT happen, offered without prompting
•Treats a published contract as a commitment to other people
•Designs the failure case, not only the success case
•Has moved a boundary after learning it was wrong
NOTES
__
__
Still Using Spreadsheets for Onboarding?
Automate documents, training assignments, task management, and track onboarding progress in real time.
Built around artifacts rather than stories. A thread dump, a memory graph that keeps climbing, a slow tail behind a healthy average. An incident story can be borrowed from a teammate; a reading of the evidence in front of them cannot.
JVM Incident and Evidence Questions
JAVA SOFTWARE ENGINEER INTERVIEW: JVM INCIDENTS AND READING THE EVIDENCE
Candidate: __
Interviewer: __
Date: __
WHEN TO USE THIS SET
This set is deliberately built around evidence rather than stories. Each
question hands the candidate an artifact, a dump, a graph, a log, and asks what
it says. Stories about past incidents can be borrowed from a teammate. A reading
of a graph cannot. Use it in the second round with anyone who will be near your
production systems, at any level, scoring a junior on method rather than on the
conclusion.
QUESTIONS, WHY THEY ARE WORTH ASKING, AND WHAT A GOOD ANSWER SOUNDS LIKE
1. I hand you a thread dump taken while the service was not responding. Almost
every request thread is sitting in the same place. What are you looking for,
and what would you conclude?
Why ask: a thread dump is the cheapest diagnostic in Java and the one most
candidates have never actually read.
Good answer: reads what the threads are waiting on. If they are all blocked
on one lock, find the thread holding it. If they are all waiting on a
database or an external call, the problem is downstream or the connection
pool is exhausted. Says they would take a second dump a minute later to see
whether anything moved.
Weak answer: talks about deadlock in the abstract without saying what the
dump would show.
2. Here is a memory graph. After every garbage collection the heap sits a little
higher than after the last one, for six days, and then the service restarts
itself. What is that, and what do you ask for next?
Why ask: this is the shape of a real leak, and recognizing a shape is a
skill you can test in ninety seconds.
Good answer: a leak, or at least unbounded growth. Asks for a heap dump taken
before the restart, then looks for what is retaining the memory: a cache with
no eviction, a collection that only grows, a listener never removed. Says
raising the heap buys time and does not fix it.
Weak answer: restart it on a schedule and move on, presented as a solution
rather than as a stopgap.
3. Average response time looks fine, but the slowest one percent of requests
take four seconds. Where do you look first?
Why ask: averages hide everything that matters, and the answer shows whether
the candidate has watched real traffic.
Good answer: looks at the slow requests specifically rather than the average.
Candidates: garbage collection pauses, a query that is slow only for large
accounts, a lock, or waiting for a connection from a pool. Says they would
check whether the slow requests share a customer, an endpoint, or a time.
Weak answer: proposes adding servers or caching before knowing the cause.
4. The service failed once at two in the morning with an out of memory error and
has been fine since. What do you do?
Why ask: it tests discipline. The lazy answer is available and tempting.
Good answer: treats a single occurrence as a warning. Finds out whether the
dump was kept, whether it was heap or something else, what was happening at
that moment, and whether the same pattern is building again. Decides on
evidence whether to act now or to add a signal and watch.
Weak answer: it was a one off.
5. What would you have logged in advance so that today's incident took ten
minutes instead of three hours?
Why ask: an unusual question that reveals whether the candidate has been on
the wrong side of a bad logging setup.
Good answer: a request identifier that follows a call through the system,
timings at each boundary, the identity of the caller, and the input that
caused a failure without recording personal data. Says that logging
everything is the same as logging nothing.
Weak answer: more logging, unspecified.
6. Tell me about an incident you personally caused.
Why ask: it is the honesty test in this set, and the follow up is the real
question.
Good answer: names it plainly, describes the effect on real users, and then
describes the change made afterwards so it could not happen the same way
again. Ownership without theatrics.
Weak answer: cannot think of one, or the answer arrives with three reasons it
was not really their fault.
7. How do you reproduce a problem that only happens with production data?
Why ask: this is the daily reality of maintaining a Java system that has been
running for years.
Good answer: get a copy with the sensitive fields removed, find the specific
record or the size that triggers it, write a failing test that captures it.
Mentions not copying customer data around casually.
Weak answer: add logging in production and wait, as the only tool available.
8. When is giving the service more memory actually the right answer?
Why ask: it rewards nuance. Sometimes the boring answer is correct, and a
candidate who can say so is thinking rather than reciting.
Good answer: when the workload genuinely grew, when the current limit was set
arbitrarily years ago, or as a deliberate stopgap while the real fix is
scheduled. The distinction is whether they know which one they are doing.
Weak answer: never, or always.
WHAT TO LISTEN FOR
•Reads evidence before forming a theory
•Distinguishes a stopgap from a fix, and says which one they are proposing
•Owns an incident they caused and names the change that followed
•Explains all of it in language a non-engineer can follow
NOTES
__
__
Set 4: Running Java in Production Questions
The set almost nobody asks: heap size inside a container limit, telling a platform kill from an application error, connection pools multiplied by instance count, graceful shutdown, health checks, configuration, and where the secrets live.
Running Java in Production Questions
JAVA SOFTWARE ENGINEER INTERVIEW: RUNNING THE SERVICE
Candidate: __
Interviewer: __
Date: __
WHEN TO USE THIS SET
Writing Java and running Java are different skills, and small companies pay for
the gap constantly because there is no platform team to absorb it. This set is
about the runtime: memory limits, instances, connections, deploys, and
configuration. Use it for anyone who will be responsible for the service after
it is released, and skip it only for a junior joining a team that operates the
system for them.
QUESTIONS, WHY THEY ARE WORTH ASKING, AND WHAT A GOOD ANSWER SOUNDS LIKE
1. The service runs with a two gigabyte memory limit. How much of that goes to
the heap, and what is the rest for?
Why ask: it is the most practical Java operations question there is, and it
catches the very common belief that the heap is all the memory a Java process
uses.
Good answer: not all of it. Thread stacks, class metadata, buffers used for
input and output, and the runtime itself all live outside the heap, so the
heap gets a fraction and the rest is headroom. Modern runtimes can read the
container limit themselves, and a percentage setting is usually safer than a
fixed number.
Weak answer: give the heap the whole limit.
2. What is the difference between the platform killing your container for memory
and the application throwing an out of memory error, and how do you tell
which one happened?
Why ask: the two look identical to a business owner and require opposite
fixes. Almost nobody asks this, and it is a clean separator.
Good answer: an application error means the heap could not satisfy an
allocation and there is usually a stack trace and possibly a dump. A platform
kill means the whole process exceeded its limit, often with no application
log at all, and the evidence is in the platform events rather than in your
logs. Says where they would look for each.
Weak answer: treats them as the same event.
3. How many database connections should one instance hold, and what changes when
you run four instances?
Why ask: connection pool sizing is where a Java service quietly hits a wall,
and multiplying by the instance count is the part people forget.
Good answer: the pool is per instance, so four instances multiply the load on
the database, and the total has to fit inside what the database allows. A
large pool does not make a database faster. Mentions watching the time spent
waiting for a connection as the real signal.
Weak answer: a number with no reasoning, or no awareness that instances
multiply.
4. What happens to a request that is halfway through when you deploy?
Why ask: graceful shutdown is a small thing that separates careful engineers
from fast ones.
Good answer: stop accepting new requests, finish the ones in flight within a
bounded time, then exit. Says the load balancer needs to know before the
process disappears, and that background consumers need the same treatment.
Weak answer: the deploy restarts it and the client retries.
5. What does your health check actually check?
Why ask: a health check that only proves the process is alive is the reason
traffic keeps flowing to a broken instance.
Good answer: distinguishes "the process is running" from "this instance can
serve traffic," which usually means it can reach its database and its
essential dependencies. Notes the trap of checking a non essential dependency
and taking yourself down when a minor vendor has an outage.
Weak answer: it returns 200.
6. Where does configuration come from, and where do the secrets live?
Why ask: at a small business, this hire may be the only person who knows, so
the answer is also a handover question.
Good answer: configuration comes from the environment rather than the build,
so the same artifact runs in staging and production. Secrets live somewhere
the repository is not, access is limited, and there is a way to rotate a key
when somebody leaves.
Weak answer: a properties file committed to the repository, described as
normal.
7. How long does the service take to start, and does it matter?
Why ask: startup time decides how fast you can roll back at the worst
possible moment.
Good answer: knows roughly, and connects it to something real: deploy speed,
how quickly a failed instance recovers, whether the first requests after
start are slow. Does not pretend to have optimized something they have not.
Weak answer: never measured, never thought about it.
8. We need to run two instances instead of one. What in the application would
stop that from working?
Why ask: the scale up question that actually comes up at a small company, and
it flushes out hidden state.
Good answer: anything held in the memory of a single process. Sessions in
memory, a scheduled job that would now run twice, files written to local
disk, an in process cache that goes stale. Says what they would move and
where.
Weak answer: nothing, just run two, with no state audit at all.
WHAT TO LISTEN FOR
•Knows the process uses more memory than the heap
•Understands that instances multiply pressure on shared resources
•Has thought about the request that is in flight during a deploy
•Can say where the secrets live and who can read them
NOTES
__
__
Companies Using FirstHR Onboard 3x Faster
Join hundreds of small businesses who transformed their new hire experience.
One calibration question asked of every candidate with a written expectation for each band, plus level specific questions for junior, mid-level, senior, and staff. Compare candidates against your bar rather than against their last employer’s titles.
Leveling Questions: Junior, Mid, Senior, and Staff
JAVA SOFTWARE ENGINEER INTERVIEW: LEVELING FROM JUNIOR TO STAFF
Candidate: __
Interviewer: __
Date: __
WHEN TO USE THIS SET
Titles on a resume are set by whoever happened to employ the person, so they do
not transfer. This set gives you a written expectation for each level and one
calibration question that you ask everybody, so you compare candidates against
your own bar rather than against each other. Decide the level you are hiring
before the first interview, and use this set to confirm it before the offer.
THE CALIBRATION QUESTION (ASK EVERY CANDIDATE)
"Walk me through the last significant change you made to a Java system, from the
moment you heard about it to the moment it was running."
Score the same answer against the level you are hiring for:
JUNIOR: describes the change itself accurately, says who told them what to do,
mentions the review that caught something, and can explain the code they wrote.
Needing direction is expected. Not understanding their own code is not.
MID-LEVEL: owns the whole change without being walked through it. Breaks the
work into steps, writes the tests, handles the edge cases nobody mentioned, and
raises the question that the requirements did not answer.
SENIOR: starts before the code. Questions whether the change is the right one,
considers the effect on the rest of the system, plans how it ships safely, and
says how they knew afterwards that it worked. Names what they chose not to do.
STAFF: the answer is about more than the change. They describe how the work fit
into a direction, what they set up so that the next three changes are cheaper,
and who else they brought along. Talks about other engineers by name and by
contribution.
LEVEL SPECIFIC QUESTIONS
JUNIOR
1. Show me some code you wrote and explain why it is written that way.
Good answer: they know their own code, including the parts that are awkward,
and can say what they would do differently now.
2. What is the last thing you got wrong, and how did you find out?
Good answer: a real mistake and a functioning feedback loop, usually a
reviewer or a test. Comfort with being corrected is the whole signal here.
3. How do you decide when to ask for help?
Good answer: a rough time limit, an attempt documented before asking, and a
specific question rather than "it does not work."
MID-LEVEL
4. Tell me about a feature you delivered end to end. What did you decide alone?
Good answer: real decisions, named, with the reasoning that produced them.
5. Something in the requirements is ambiguous and the person who could answer is
away for a week. What do you do?
Good answer: pick the reversible option, write down the assumption, keep
working, and confirm it later. Not "wait" and not "guess silently."
6. What do you test, and what do you deliberately not test?
Good answer: a strategy with tradeoffs. Logic with branching gets unit tests,
anything touching the database gets an integration test, trivial code gets
nothing. A coverage percentage as the only answer is a weak sign.
SENIOR
7. What is the last thing you talked a team out of building?
Good answer: a specific proposal, the cost they saw, and how they made the
case without simply blocking it.
8. How do you ship a change too large for one release?
Good answer: behind a switch, in increments, with the data change split into
an additive step and a cleanup step later, and the branch kept short lived.
9. A junior submits work that is correct but not how you would have written it.
What do you do?
Good answer: distinguishes a preference from a problem. Approves it, and
raises the pattern separately if it matters. A senior who blocks on style is
an expensive teammate at a small company.
STAFF
10. What did you change about how the team works, not about the code?
Good answer: something concrete and adopted: a review standard, a release
process, a decision record, a testing approach, with evidence it stuck after
they stopped pushing.
11. How did you decide what NOT to work on?
Good answer: a real tradeoff, made with information about the business
rather than about the technology alone.
12. Who have you grown, and what are they doing now?
Good answer: names, specifics, and a result they clearly take pride in but
do not claim credit for.
WHAT TO LISTEN FOR
•The level in the answer, not the level on the resume
•A junior who understands their own code and asks well
•A mid-level engineer who resolves ambiguity instead of stalling
•A senior who prevents work, and a staff engineer who changes the system around
the work
NOTES
__
__
Set 6: Scorecard and Red Flags
A weighted 1-to-5 rubric with space for written evidence, a ten item red flag checklist, and a level check to run before any offer goes out. Use it with every set above and for every candidate.
and where the secrets live are all familiar ground
3 = has operated with support from someone else
1 = writing the code is where their responsibility ends
Evidence: ___
5. COMMUNICATION WITH NON ENGINEERS (weight 20%) Score: ___ /5
5 = explains a system plainly, flags a risk before a date slips, says "I do
not know" without discomfort
3 = clear when asked, quiet otherwise
1 = jargon as a shield; you leave the conversation less certain than you
arrived
Evidence: ___
WEIGHTED TOTAL: ______ / 5
RED FLAGS CHECKLIST
[ ] Everything is "we" and the line never gets drawn
[ ] First instinct on any existing codebase is a full rewrite
[ ] Cannot name a single incident they caused
[ ] Answers get vaguer under follow up rather than more specific
[ ] Proposes adding servers or memory before measuring anything
[ ] Treats tests and code review as things that slow real work down
[ ] Dismissive about the Java version or the framework you actually run
[ ] Blames every former employer, every teammate, and all inherited code
[ ] Cannot explain any technical decision in plain language
[ ] Details of scope or dates that shift between conversations
LEVEL CHECK BEFORE THE OFFER
Level posted: _____ Level demonstrated: _____
If these do not match, resolve it now. Offering senior pay for mid-level
judgment is expensive, and hiring a junior into a role with nobody available to
review their work is unfair to the person and bad for the business.
Recommendation: [ ] Strong yes [ ] Yes [ ] No [ ] Strong no
Key strengths: __
Key concerns: ___
Interviewer signature: _
What a Strong Answer Sounds Like
Strong answers share a shape whatever the topic: they are specific, they name a tradeoff, and they admit something. Weak answers stay abstract, present every past decision as obviously correct, and contain no mistakes. That pattern is visible without reading a line of Java.
We run one Java application that does everything. What would make you split part of it out?
Strong answer
Names a specific reason a piece should leave: it scales differently, it fails differently, or a different person owns it. Then says what should stay put and why four services nobody can deploy separately is worse than one.
Weak answer
Services are simply more modern, or the answer describes an architecture with no reference to your situation, your team size, or the cost of running it.
The heap sits a little higher after every collection for six days, then the service restarts itself. What is that?
Strong answer
Calls it unbounded growth, asks for a heap dump from before the restart, and names candidates: a cache with no eviction, a collection only ever added to. Says more memory buys time rather than fixing it.
Weak answer
Suggests restarting on a schedule and treats that as the solution rather than as something to do while the real cause is found.
The container has a two gigabyte limit. How much of that goes to the heap?
Strong answer
Not all of it. Thread stacks, class metadata, and input and output buffers sit outside the heap, so it gets a fraction and the rest is headroom. Prefers a percentage the runtime applies to the real limit.
Weak answer
Gives the heap the entire limit, which produces a process the platform kills with no application log to explain it.
None of those three requires you to know the language, which is deliberate. Every question in these sets was chosen because a non-technical interviewer can score it honestly, a constraint most technical hiring advice quietly ignores. For a language-agnostic view of the same role, the software engineer questions cover code review and testing in more depth.
The Boundary Questions Most Interviews Skip
Ask where code belongs. Boundary decisions are the ones you cannot cheaply undo: a badly placed split costs you for years, and so does a single application nobody dares to touch. Most technical interviews test whether a candidate can write code and never test whether they know where to put it.
The question that works is deliberately two-sided. What would make you split part of this application out, and what would make you leave it alone? A strong candidate answers both halves. They split for a real reason, a piece that scales differently, fails differently, or is owned by different people, and they say plainly that one application with clean internal boundaries beats four services nobody can deploy independently.
The follow-up is about contracts. Ask how they would change an endpoint another system already calls. Add before you remove, migrate the callers, then delete once nothing uses it. A candidate who treats a published contract as a promise will cost you far fewer surprise outages than one who ships a breaking change and announces it afterwards. If most of the role is data modeling and query work rather than service shape, the backend engineer questions cover that ground more thoroughly.
Ask Them to Draw Your Application
Replace the abstract architecture question with your real system. Describe what your application does in two minutes and ask where they would draw the lines, and what they would need to know before deciding. A strong candidate asks about the business before answering: who uses which part, what has to stay consistent, what can be late. A candidate who starts naming services in the first thirty seconds is showing you exactly how the design will go once they are hired.
Judging a JVM Answer Without Writing Java
Hand the candidate evidence instead of asking for a story. Incident stories can be borrowed from a teammate and polished over several interviews. A reading of a thread dump or a memory graph is produced live, and you can score the method even if you cannot verify the conclusion.
Three artifacts do most of the work. A thread dump taken while the service was unresponsive, where a strong candidate asks what the threads are waiting on and takes a second dump to see whether anything moved. A memory graph that climbs a little after each collection for six days, where the answer should be unbounded growth and a request for a heap dump, not a restart schedule. And a healthy average hiding a slow one percent, where the candidate should look at the slow requests specifically rather than the average.
You do not need to know what a correct answer contains to grade these. Listen for whether the candidate looks at the evidence before forming a theory, whether they say out loud which of their proposals is a stopgap and which is a fix, and whether they can explain the reasoning in ordinary English. If your role is really about infrastructure and pipelines rather than application code, the DevOps engineer questions fit better than these.
Leveling a Java Hire from Junior to Staff
Level the candidate against your own written bar, not against the title on their resume. Titles are set by whoever happened to employ the person, and a senior engineer at a forty person company and a senior engineer at a large platform team have almost nothing in common in daily practice.
One question does most of the leveling work when you ask it of everybody: walk me through the last significant change you made to a Java system, from the moment you heard about it to the moment it was running. The same answer scores differently at each band, which is exactly what makes it useful.
Level
What the answer should contain
The clearest tell
Junior
Describes the change accurately, names who directed it, mentions a review that caught something
Understands their own code, including the awkward parts
Mid-level
Owns the change without being walked through it; tests, edge cases, and the question requirements missed
Resolves ambiguity instead of stalling on it
Senior
Starts before the code: is this the right change, how does it ship safely, how did we know it worked
Names what they deliberately chose not to do
Staff
The change fits a direction; sets things up so the next three changes are cheaper; brings others along
Talks about other engineers by name and contribution
Two failures cost the most. Paying senior rates for mid-level judgment is the one everybody expects. Hiring a junior into a role with no reviewer available is the one that actually happens more often at small companies, and it is unfair to the person as much as it is bad for the business. Decide the level before you post, then confirm it against the demonstrated level before the offer using a consistent evaluation form.
A Work Sample Built From Your Own Code
A short paid work sample taken from your real codebase predicts performance better than an algorithm puzzle, and candidates resent it far less. Keep it to two or three hours with a hard cap, publish the criteria you will score against, and give every candidate the same brief so the comparison means something.
Good Java briefs are small and realistic: add one endpoint to a tiny existing service, write a failing test that captures a bug you actually had, or find the deliberately slow path in a sample project. Pay for the time. Unpaid multi-day projects screen out precisely the experienced people with current jobs and family responsibilities you most want to reach. Federal guidance treats any test used to make employment decisions as something that should be job-related and consistent with business necessity, which is one more reason to keep the task close to the actual work.
The Debrief Matters More Than the Code
Score the conversation about the work sample, not only the submission. Ask what they would do with two more days, what they deliberately left out and why, where they used an AI assistant and what they changed about its output, and which error cases they decided to skip. A candidate who submits ordinary code and debriefs brilliantly is usually the better hire, because you are buying judgment for years rather than one afternoon of output.
Scoring the Interview
Score immediately after each conversation, while the evidence is fresh, and anchor every rating to something the candidate actually said. Set the weights before you meet anyone, so the areas that matter for your system are decided by the job rather than by whichever answer impressed you on the day.
Scoring area
Suggested weight
What a 5 looks like
Java service ownership
25%
Built and ran real services; clear about their own part; knows what happened after they left
Boundary and API judgment
20%
Argues both sides of a split; treats a published contract as a commitment
JVM diagnosis from evidence
20%
Reads a dump or a graph, measures before changing, separates a stopgap from a fix
Running the service
15%
Memory limits, instances, pools, deploys, health checks, and secrets are familiar ground
Communication with non-engineers
20%
Explains a system plainly and flags a risk before a date slips
If more than one person interviews, each scores independently before the group talks, so the most senior voice does not anchor everyone else. Compare written evidence first and discuss the gaps second. The same questions and the same rubric for every candidate is the whole of a structured interview, and those scores feed a clean interview feedback step before you decide.
What a Java Software Engineer Costs
There is no separate federal occupation for Java engineers, so the closest published benchmark is software developers. Use it as a national baseline, then adjust for your market, the level you are genuinely hiring, and whether the role is an employee or a contract engagement.
Median $135,980 a Year (BLS OEWS, May 2025)
Software developers had a median annual wage of $135,980, about $65.38 an hour, according to the Bureau of Labor Statistics Occupational Employment and Wage Statistics survey (May 2025). The spread inside the occupation is unusually wide: the lowest 10 percent earned under $82,460 and the highest 10 percent over $214,670, with the 25th percentile at $105,210 and the 75th at $171,980 (U.S. Bureau of Labor Statistics).
A spread of more than $130,000 between the tenth and ninetieth percentile inside one occupation is why a title on a resume tells you almost nothing about cost. An engineer who will be your only one, holding the deploy access and the credentials, sits higher in the band than one joining an established team, because you are paying for judgment and availability as well as output. If you are weighing an employee against a contract engagement, the employee versus contractor distinction changes both the cost and the questions you should ask about who owns the work. The software engineer job description spells out what to put in the posting at each level.
Fair, Legal, and Structured Interviewing
A fair interview, a legal interview, and an effective interview are the same interview. Asking the same job-related questions of every candidate keeps you compliant, reduces bias, and produces better hires at the same time. Java interviews carry a few specific traps worth naming.
Keep every question on the work
Federal anti-discrimination law, enforced by the EEOC, prohibits basing a hiring decision on protected characteristics, and a question that probes one creates risk even when it arrives as friendly small talk. Do not ask about age, race, religion, national origin, sex, pregnancy or family plans, disability, or genetic information. Java interviews have a specific version of this trap, because the language has been around long enough that experience talk drifts into age talk: which version did you start on, what year did you graduate, are you too experienced for a small team. Graduation year is an age question in a technical costume. Every question in these sets stays on the work itself. This is general information, not legal advice.
Ask the same core questions of everyone
A structured interview, where every candidate faces the same questions scored against the same rubric, predicts on-the-job performance far better than a free-flowing technical conversation, and it protects you at the same time. Technical interviews drift more than most: a shared enthusiasm for one framework can quietly become forty minutes that no other candidate received, and then that candidate feels like the strongest simply because you spent longer enjoying the conversation. Write the set in advance, ask it in the same order, and keep the exploratory talk for after the scored questions.
Treat a coding exercise as a selection test
Federal guidance treats any test used to make an employment decision as something that should be job-related and consistent with business necessity, and a take-home exercise or a live coding session is a test. Practically, that means the same brief for every candidate, published criteria, and a task close to work your business actually does. An algorithm puzzle with one clever trick is both a weaker predictor and a harder thing to defend if anyone ever asks why one candidate passed and another did not. Cap the time, pay for it, and score it on a written rubric. This is general information, not legal advice.
Match the sets to the Java you actually run
A Java engineer for a business running one long-lived application on a managed database and one running several services behind a gateway are different hires. If your system is one application that has grown for eight years, weight the ownership and production sets and go lighter on boundaries. If you are already running several services, the boundary set is the one that decides the hire. Write down what the person must accomplish in their first ninety days, then interview for exactly that rather than for a generic large-company engineer you neither need nor can keep interested.
Structure Is Both the Fairer and the More Effective Choice
A structured interview, where every candidate answers the same questions scored against a consistent rubric, predicts on-the-job performance more reliably than an unstructured conversation. Asking the same job-related questions of everyone also keeps you inside the EEOC rules against basing decisions on protected characteristics, and any test used to select employees falls under the Uniform Guidelines on Employee Selection Procedures.
Keep every question tied to the work and skip the small talk that drifts toward age, origin, or family. Java has been around long enough that experience talk slides into age talk without anyone intending it, so the questions employers cannot ask are worth reading once before you interview. This is general information, not legal advice.
Interviewing a Java Engineer Without HR
A large company runs a Java candidate through coordinated panels with a recruiter managing scorecards and a committee calibrating the level afterwards. A small business runs the founder, alone, between everything else, often with nobody technical in the room. That reality changes what a good process looks like, and it is where the avoidable mistakes cluster.
You are the only interviewer, and you may not write code
A large company runs a Java candidate through coordinated panels with a recruiter tracking scorecards and a committee calibrating the level afterwards. At a small business the owner does all of it alone, between everything else, often with nobody technical in the room. That is why every question in these sets carries a stated reason for asking and a description of what a strong answer sounds like. You are grading the shape of an answer: specific, honest, aware of a tradeoff, willing to say I do not know. That is something you can score without reading a line of Java.
This person may be the only one who understands the system
At a small company the Java engineer often holds the deploy access, the database credentials, and the only working knowledge of a system the business runs on. That concentration is the reason the production and running sets matter more here than they would at a company with a platform team, and the reason handover belongs in the interview rather than in the exit conversation. Ask who else could restart the service, where the configuration lives, and what happens the week they take a vacation. A candidate who answers those calmly has been the single point of failure before and took it seriously.
A Java system outlives the person who wrote it
Java code has an unusually long life, which is a compliment to the platform and a warning about the hire. The decisions this engineer makes in their first year will be maintained by somebody five years from now, quite possibly by you paying somebody else to understand them. Structure is the cheapest protection available: the same written questions for every candidate, a short paid work sample, and a weighted rubric filled in before anyone debates. If you want a technical read you do not have in-house, pay a senior engineer you trust for two hours to sit in on one interview and review the work sample. Applicant tracking is coming soon to FirstHR.
A written question set and a rubric exist to make one person's interview as rigorous as a hiring committee's without the overhead of one. Where you find candidates shapes your pipeline more than any single question does, so decide how you will source developers before you start. Browse the rest of the hiring templates if you need the posting, the evaluation form, or the offer to go with it.
From Interview to Onboarding
The interview is step one. Onboarding a Java engineer carries extra steps because of the access involved: a written offer and a confidentiality agreement signed before the first commit, repository, hosting, and database access provisioned from accounts the business owns, and the standard new hire paperwork alongside it.
Score before you discuss
Each interviewer fills the weighted rubric alone, with written evidence, then the group compares notes instead of impressions.
Offer, level, and confidentiality
Put the level, the pay, and the start date in writing, and get the confidentiality and IP assignment signed before the first commit.
Access from company accounts
Repository, build system, hosting, and database access provisioned from accounts the business owns, never from a personal one.
Ship something small in week one
One tiny real change tests the whole path from a laptop to a customer and exposes every broken step in your setup early.
Give the new engineer something small and real to ship in the first week. Shipping once beats two weeks of reading, because it tests the entire path from a laptop to a customer and exposes every broken step in your setup while somebody is paid to notice. A structured developer onboarding plan and a clear offer letter handle most of the rest. Applicant tracking is coming soon to FirstHR.
FirstHR connects the offer, the confidentiality agreement, e-signatures, the new hire paperwork, and the access and policy checklist in one place, and stores the signed documents and interview records on the employee profile where you can find them a year later. FirstHR is an onboarding and HR platform, not a code repository, a deployment tool, or an applicant tracking system, so connect those separately. Applicant tracking is coming soon to FirstHR.
Key Takeaways
Assess five things: what they personally built and ran in Java, where code belongs, how they read production evidence, how they operate the service, and how plainly they explain it.
The highest-yield question is a follow-up: on that system, what did you write and what did somebody else write.
Hand the candidate evidence rather than asking for an incident story, because a thread dump or a memory graph cannot be borrowed from a teammate.
Ask the production questions nobody else does: how much of a container memory limit goes to the heap, and what changes when you run four instances instead of one.
Level against your own written bar using one calibration question, not against the title the last employer happened to use.
Use a short paid work sample built from your own code, and score the debrief as heavily as the submission.
Use BLS data as a baseline: the closest occupation, software developers, reported a median of $135,980 a year in May 2025.
Frequently Asked Questions
What questions should I ask a Java software engineer in an interview?
Ask questions that force specifics about Java systems the candidate has personally run, across five areas: what they built and owned, how they decide where code belongs and how they change a contract other systems call, how they diagnose a JVM problem from actual evidence, how they operate the service in production, and how they explain any of it to somebody who does not write code. Two questions carry unusual signal and almost nobody asks them. The first is how much of a two gigabyte container limit should go to the heap, which catches the common belief that the heap is all the memory a Java process uses. The second is what would you have logged in advance so today’s incident took ten minutes instead of three hours. Skip algorithm trivia with no relationship to your codebase. This page gives you six ready-to-use sets, each question paired with why it is worth asking and what a strong answer sounds like.
How do I interview a Java engineer if I am not technical?
Grade the shape of the answer rather than its technical content, because the shape is visible to anyone. Strong answers are specific, name a tradeoff, and admit something. Weak answers stay abstract, present every past decision as obviously correct, and contain no mistakes. Three moves make this work without any Java knowledge. Ask the same written questions of every candidate so you are comparing like with like. Follow up until the answer becomes concrete: which service, how many users, how long did it take, what did you change first. Then ask them to explain one technical decision as though you were a customer, because an engineer who cannot do that will be expensive to work with regardless of skill. If you want a technical read you do not have in-house, pay a senior engineer you trust for two hours to sit in on one interview and review the work sample.
What is the difference between a Java developer and a Java software engineer?
In the market the titles overlap heavily, but the expectation attached to them usually differs, and it is worth deciding which one you are hiring before you write the posting. A Java developer role is most often framed around building what has been specified: features, fixes, and the frameworks used to deliver them. A Java software engineer role is more often framed around owning a system: deciding where code belongs, designing the contracts other systems depend on, and staying responsible for how the thing behaves in production at three in the morning. Neither title is reliable on a resume, so judge by what the person has personally owned rather than by what their last employer called them. If your role is mostly delivery inside an existing structure, interview for the developer framing. If the person will be the one making the calls nobody else can make, use the sets on this page.
Should I give a Java coding test or a take-home exercise?
Give a short paid work sample built from your own code, not an algorithm puzzle. Two or three hours with a hard cap predicts performance far better than a whiteboard exercise, and candidates resent it far less. Good Java briefs are small and realistic: add one endpoint to a tiny existing service, write a test that captures a bug you actually had, or find and fix a deliberately slow path in a sample project. Give every candidate the same brief and publish the criteria you will score against. Pay for the time, because unpaid multi-day projects screen out exactly the experienced people with current jobs and family responsibilities you most want to reach. Federal guidance treats any test used to make an employment decision as something that should be job-related and consistent with business necessity, which is another reason to keep the task close to real work. Score the debrief conversation as heavily as the code.
How do I tell a mid-level Java engineer from a senior one?
Ask both the same question and score the answer against a written expectation for each level. The question that works is: walk me through the last significant change you made to a Java system, from the moment you heard about it to the moment it was running. A mid-level engineer owns the whole change without being walked through it, breaks it into steps, writes the tests, and raises the question the requirements did not answer. A senior engineer starts before the code: they question whether the change is the right one, consider the effect on the rest of the system, plan how it ships safely, and can say how they knew afterwards that it worked. The clearest senior signal is naming what they deliberately chose not to do. Titles on a resume are set by whoever employed the person, so they do not transfer between companies. Decide your own bar before the first interview.
What should I pay a Java software engineer?
There is no separate federal occupation for Java engineers, so the closest published benchmark 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, roughly $65.38 an hour. The spread inside the occupation is unusually wide: the lowest 10 percent earned under $82,460 and the highest 10 percent over $214,670, with the 25th percentile at $105,210 and the 75th at $171,980. Use the national figure as a baseline, then adjust for your market, the level you are genuinely hiring, and whether the person will be your only engineer. Someone who holds the deploy access and the database credentials alone sits higher in the band than someone joining an established team, because you are paying for judgment and availability as well as output.
What are the red flags in a Java interview?
The reliable ones are behavioral rather than technical. Watch for a candidate who says we for every component and never draws a line around their own work, even after two follow-up questions. Watch for the instinct to rewrite an existing codebase before reading it, which is expensive on a small team that cannot afford a parallel system. Watch for more memory or more servers offered as the first answer to a performance problem, before anything has been measured. Two subtler ones matter as much. A candidate who cannot name a single incident they personally caused is either inexperienced or not being straight with you, and the follow-up question about what they changed afterwards is where you find out which. And answers that get vaguer under probing rather than more specific are the clearest tell there is, because someone who was actually there gets sharper when you ask for detail.
