HackerRank-style coding test practice

What the real test usually looks like

There is no single HackerRank test. HackerRank is a platform: each employer builds its own test, choosing the questions, the languages allowed and the time limit. The invitation from the employer is the best guide to yours.

Question types. HackerRank lists many question types for its tests, including coding, database, multiple choice, front-end, back-end, full-stack, code review, subjective and others (HackerRank). Most coding tests lean on a few of them:

• Coding questions: you write a solution in an editor. HackerRank says candidates can run their code against the test cases, and that it is then scored against sample cases you can see and hidden cases you cannot (HackerRank support).
• Database questions: you write a SQL query, and its result is compared with the expected output (HackerRank support).
• Multiple choice: concepts, complexity and what a piece of code does, scored automatically (HackerRank).

Public examples of length. HackerRank's own skills tests give a sense of the range: its Python (Basic) test is listed as 2 questions in 90 minutes (HackerRank) and its SQL (Basic) test as 2 questions in 30 minutes (HackerRank). An employer's test may be shorter or longer, with more or fewer questions.

Topics commonly reported in coding tests: arrays and strings, hash maps and sets, sorting and searching, time complexity, edge cases such as empty or negative input, and basic SQL.

What our mocks cover. Each full mock is 14 questions in 90 minutes in three sections: concepts and code reading (10), coding problems (3) and a database problem (1). For the coding problems you write and run a solution in Python, JavaScript, Java or C++, and for the database problem a SQL query; each is checked against hidden test cases and earns credit for each case it passes. A laptop is recommended. You can go back and flag questions.

What our free sample does differently. The 10 free questions are multiple choice: the coding questions ask which solution passes or which input breaks one, the skills behind writing code that passes. The full mocks have you write and run the code. Our hidden cases are small and check correctness and edge cases, so they do not time a slow solution on huge inputs the way some real tests do; the explanations say where speed would matter.

Question types with worked examples

One worked example for each kind of question, with the trap most people fall into.

1. Time complexity. A loop over a list calls "x in other_list" each time. Both lists have n items. The loop runs n times and each membership check scans up to n items, so the whole thing is O(n squared). Turning other_list into a set makes each check O(1) on average and the loop O(n). Trap: counting only the visible loop. Built-in calls such as "in" on a list, list.index and slicing do work too.

2. Reading code. What does print([x * 2 for x in range(3)]) show? range(3) gives 0, 1 and 2, so the answer is [0, 2, 4]. Trap: starting at 1 or including 3. range stops before its end value.

3. Which solution passes. A problem allows up to 100,000 items. An O(n squared) solution needs about 10 billion steps, which is far too slow for a typical time limit, while O(n) or O(n log n) is comfortable. Trap: choosing the solution that looks shortest. Check its complexity against the stated size first.

4. Which input breaks it. A function returns the average of a list as sum(nums) / len(nums). Which input breaks it? An empty list, which divides by zero. Trap: only testing typical input. Try empty, one item, all equal, negatives and the largest allowed size.

5. Database problem. You need each customer's total spend, including customers who have spent nothing. Use customers LEFT JOIN orders, group by customer and sum the amount, then turn NULL into 0 with COALESCE. Trap: an inner join, which silently drops the customers with no orders.

How to prepare

1. Read your invitation first. Note the time limit, the number and type of questions, and the languages allowed. Employers set all of these, so do not assume.
2. Choose one language and stay with it. Use the language you know best for coding questions. Know its built-in lists, dictionaries, sets, sorting and string methods well enough not to look them up.
3. Learn complexity by input size. Check the stated limits before you code. Up to about 1,000 items, O(n squared) is usually fine; at 100,000 or more, aim for O(n) or O(n log n).
4. Practice edge cases on purpose. Empty input, a single item, duplicates, negatives, very large values and the maximum size. Coding questions are scored on hidden test cases (HackerRank support), and these are where most of them hide.
5. Run the sample cases, then test your own. Passing the visible samples is the start, not the finish. Add a few cases of your own before you submit.
6. Refresh basic SQL. Joins, GROUP BY, HAVING, NULLs and sorting cover most database questions. Check the result row by row, because database answers are compared with the expected output (HackerRank support).
7. Write full solutions under time. Our full mocks have you write and run code against hidden cases; do the same with problems of your own, so typing a full solution under time feels normal.
8. Practice at the real pace. Take full timed mocks so 90 minutes of focused work feels normal on the day.

How scoring usually works

Scoring is set up by each employer. HackerRank describes how its question types are scored, and each employer decides what result is good enough. There is no universal pass mark.

• Coding questions: HackerRank says the system runs your code against every test case and compares each output with the expected output. Each test case carries a set score: passing earns all of it and failing earns none, with no partial scoring within a test case. Your score for the question is the total of the test cases you pass. Sample cases you can see may be worth 0 points, while hidden cases carry the points (HackerRank support).
• Database questions: your query's result is compared with the expected output: a match earns the full score and anything else earns zero, unless the employer reviews it by hand and gives partial credit (HackerRank support).
• Multiple choice: scored automatically (HackerRank).

This is why a solution that is almost right, or right but too slow, can lose most of its points: each hidden case is pass or fail.

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 HackerRank score or any employer's result, and it does not predict whether you will pass.

Common mistakes

• Stopping when the samples pass. Visible samples are a small part of the cases. Test empty input, one item, negatives and the largest size yourself.
• Ignoring the input limits. A correct but slow solution can fail the large hidden cases. Read the limits before you choose an approach.
• Starting a maximum at 0. Start with the first item, or negative numbers break it.
• Mutating a list you are looping over. Removing items while iterating skips elements. Build a new list instead.
• Off-by-one ranges. range(a, b) stops before b, and slices work the same way. Check the first and last index on a tiny example.
• Printing extra output. Coding answers are compared with the expected output, so stray debug prints or extra spaces can fail a case.
• Spending too long on one problem. Submit a working solution first, then improve it if time is left.