Java coding test practice

What the real test usually looks like

There is no single Java coding test. Each employer chooses a testing platform and then sets its own questions, number of tasks, time limit and allowed languages. Your test invitation is the best guide to yours. Public examples show the range:

• HackerRank. HackerRank lists its Java (Basic) skills test as 6 questions in 1 hour, covering topics like classes (HackerRank). Its help center lists the question types an employer can put in a test, including coding, multiple choice, database, back-end developer, code review and subjective questions, and says employers can add questions from HackerRank's library or write their own (HackerRank Help).
• TestGorilla. TestGorilla's Java coding tests page says most of its coding tests take between 15 and 35 minutes, lists an entry-level algorithms test at 15 minutes, and says candidates read the problem, choose Java from a language menu and write their solution in an online editor (TestGorilla).

Parts commonly reported in employer Java tests:

• Coding tasks: write a method in an online editor, run it against sample inputs, then submit it to be checked against more test cases you may not see.
• Multiple choice: Java concepts such as types, classes, collections and exceptions, what a snippet prints, and which code is correct.
• Debugging or code review: find and fix the problem in code someone else wrote.
• Sometimes more: a SQL question, a framework or back-end project, a take-home assignment, or webcam and screen monitoring during the test.

What our mocks cover. Our full mocks have 20 questions in 60 minutes in four sections: Java concepts (6), what the code prints (6), finding the bug (5) and building a solution (3). All code is Java 17. You can go back, change an answer and flag questions until you submit. Our mocks practice reading, tracing, debugging and choosing code. They do not run code you write. Many real assessments do ask you to write code that runs against hidden test cases; this practice builds the reading, tracing and debugging skills behind that, so add some timed practice in a real editor as well. Our mocks also leave out proctoring, plagiarism checks, video interviews, take-home and project tasks, and any employer pass mark.

Question types with worked examples

One worked example for each section, with the trap most people fall into.

1. Java concepts. What is the difference between an int and an Integer? An int is a primitive value; an Integer is an object that wraps one and can be null. Collections such as List hold Integer, and Java converts between the two automatically. Trap: comparing two Integer objects with ==. It compares references and can be false for equal values; use equals.

2. What the code prints. System.out.println(1 + 2 + "3" + 4 + 5); prints 3345. Java works left to right: 1 + 2 is the number 3, then adding "3" makes the string "33", and from then on every + joins text. Trap: doing all the arithmetic first. Trace one operator at a time and note the type after each step.

3. Finding the bug. A method reads if (status == "done") and never matches, even when the status is "done". The fix is "done".equals(status), which compares the characters and also copes with a null status. Trap: fixing the first line that looks unusual. Trace a tiny input through the code and find the first line where the value goes wrong.

4. Building a solution. You need to count how often each word appears. A HashMap with counts.merge(word, 1, Integer::sum) in a loop does it in one line per word. Trap: picking the option that handles the normal case but not the edges. Check every choice against an empty array, one item, repeats, negative numbers and null.

How to prepare

1. Read your invitation first. Find out which platform you will use, how many tasks there are, the time limit, which Java version the editor runs, and whether the test is monitored. Formats vary too much to assume.
2. Try the platform's practice area if it has one. Get used to the editor, the Run button, how input is read and how sample test cases are shown, so the screen is not new on the day. HackerRank, for example, describes candidates clicking Run to run the test cases while they work (HackerRank Support).
3. Trace code by hand. For short snippets, write each variable's value and type after every line. Integer division, string joining and references are where most surprises hide.
4. Know the everyday tools. Arrays, String and StringBuilder, ArrayList, HashMap, HashSet, Arrays.sort and Collections.sort, equals and hashCode, exceptions, and basic classes and interfaces.
5. Think about edge cases before you submit. Empty arrays and strings, one item, repeated values, negative numbers, null, and values large enough to overflow an int. Hidden test cases often check exactly these.
6. Write some code against the clock. Our mocks train reading and debugging. Also solve a few small problems in a real editor with a timer, so writing, compiling and running code under pressure feels normal.
7. Practice at the real pace. If your test is like HackerRank's Java (Basic) example, 6 questions in 1 hour gives about 10 minutes a question (HackerRank). Take full timed mocks so pacing yourself feels normal.

How scoring usually works

Scoring depends on the platform and the employer. There is no universal scale and no universal pass mark. Coding questions are usually scored automatically against test cases. Two public descriptions:

• HackerRank says coding questions are evaluated with predefined test cases that measure correctness and efficiency. Each test case has its own score: code that passes a test case receives that test case's full score, and code that fails it receives zero. The question's total is the sum of the test cases passed, so a solution that passes some test cases earns part of the points (HackerRank Support). Coding and multiple choice questions are evaluated automatically, while back-end questions are evaluated automatically with a manual review recommended (HackerRank Help).
• TestGorilla describes percentile-based scoring based on overall correctness, meaning whether given inputs produce the correct outputs, and a report showing each test case's result (TestGorilla).

What counts as a good result is up to each employer, and many look at your code as well as the score.

Our practice score is the number of our own questions you answered correctly, with a breakdown by section, so you can see where to focus. It is a practice score: it is not a score on any platform's test and does not predict whether you will pass.

Common mistakes

• Comparing strings with ==. Use equals, or "text".equals(value) when the value might be null.
• Expecting decimals from integer division. 7 / 2 is 3. Make one side a double first when you need 3.5.
• Forgetting that strings are immutable. s.trim() and s.toUpperCase() return new strings; assign the result.
• Off-by-one errors in loops. Indexes run from 0 to length - 1, so the usual loop test is i < a.length.
• Changing a list inside a for-each loop. Use removeIf or an explicit Iterator and its remove method.
• Ignoring overflow. Sums and products of large int values can wrap around silently. Use long when values can grow.
• Only testing the example. The visible example usually passes. Hidden test cases check empty input, single items, duplicates and large inputs.
• Running out of time on one task. If you are stuck, submit a simple version that passes some test cases, move on, and come back if time allows.