How to Clear Online Coding Assessments on HackerRank, HackerEarth and Codility

Online assessments (OAs) are the first technical filter at almost every company that hires software engineers at scale in India, from mass recruiters to Amazon, Microsoft, fintechs and startups. They're usually 60–120 minutes, 2–4 coding problems, sometimes with MCQs, run on HackerRank, HackerEarth, Codility or a similar platform.

Plenty of candidates who can solve the problems still fail OAs. They lose time on input parsing, misjudge the complexity needed, overflow an int, or panic on the hard problem and leave the easy one half-done. This guide is about everything around the algorithm: platform mechanics, constraint reading, templates, scoring strategy, testing, time management and proctoring rules. The algorithms themselves are covered in our DSA patterns guide.

How Online Coding Assessments Work

The typical flow on every major platform:

1. You receive a link with a deadline window (often a few days). Once you start, a timer runs and usually can't be paused.
2. You see the problem statement with an input/output format, constraints, and one or more sample tests.
3. You write code in a browser editor. You can run it against the samples and usually against your own custom input.
4. You submit. Your code runs against hidden test cases: small ones for correctness and large ones for performance. Each case has a time limit and memory limit.
5. The employer sees a report: score per problem, test cases passed, time taken, code, and any proctoring flags or plagiarism matches.

Two implications are easy to miss. First, samples are not the test; passing samples proves very little about the hidden cases. Second, the employer often sees your code and your activity log, not just your score, so clean code and clean conduct both matter.

HackerRank vs HackerEarth vs Codility: Platform Differences

Features change and employers configure tests differently, so always read the instruction page before starting. Most platforms offer a sample or practice test; take it. Five minutes on the practice test saves you from discovering the editor's quirks under time pressure.

Function stubs vs full programs

With a function stub, the platform reads input and calls your function; you only return the answer. Don't print extra output, and don't read from stdin yourself. With a full program, you read input exactly as specified and print output exactly as specified. Extra spaces or debug prints can fail every test case. Remove or comment out debug output before submitting.

A Codility-style function example

Codility tasks typically look like this: given an array A, return the smallest positive integer that does not occur in it. You implement the function only.

import java.util.HashSet;

class Solution {
    public int solution(int[] A) {
        HashSet<Integer> seen = new HashSet<>();
        for (int x : A) if (x > 0) seen.add(x);
        int ans = 1;
        while (seen.contains(ans)) ans++;   // at most n + 1 iterations
        return ans;
    }
}

def solution(A):
    seen = {x for x in A if x > 0}
    ans = 1
    while ans in seen:
        ans += 1
    return ans

O(n) time and space. Note how the performance tests would punish an O(n²) approach (for example, checking ans in A on a list each time), even though it passes every small example.

Reading Constraints: The Most Important Minute

Constraints tell you the intended complexity. A useful rule of thumb is that a C++ solution can do on the order of 10⁸ simple operations per second; Java is in the same ballpark, and Python is substantially slower, often by an order of magnitude or more for loop-heavy code. Time limits are typically 1–2 seconds for C++ (platforms often give other languages more).

Also read the value constraints. If values go up to 10⁹ and you sum up to 10⁵ of them, the total can reach 10¹⁴, which overflows a 32-bit int (max about 2.1 × 10⁹). Use long long in C++ or long in Java. Python integers don't overflow, which is one of its genuine advantages in OAs. For a refresher on analysing complexity, see time and space complexity explained.

Fast I/O Templates for C++ and Python

For full-program problems, input handling is boilerplate you should never write from scratch under pressure. Practise one template per language until it's automatic. Here's a template that reads several test cases, each an array, and prints the maximum subarray sum (Kadane's algorithm) as a stand-in for your logic.

#include <bits/stdc++.h>
using namespace std;
typedef long long ll;

int main() {
    ios::sync_with_stdio(false);   // faster cin/cout
    cin.tie(nullptr);
    int t;
    if (!(cin >> t)) return 0;
    while (t--) {
        int n;
        cin >> n;
        vector<ll> a(n);
        for (auto &x : a) cin >> x;
        ll best = a[0], cur = 0;
        for (ll x : a) {
            cur = max(x, cur + x);
            best = max(best, cur);
        }
        cout << best << '\n';     // '\n', not endl (endl flushes every line)
    }
    return 0;
}

import sys

def main():
    data = sys.stdin.buffer.read().split()   # read everything at once
    idx = 0
    t = int(data[idx]); idx += 1
    out = []
    for _ in range(t):
        n = int(data[idx]); idx += 1
        a = list(map(int, data[idx:idx + n])); idx += n
        best, cur = a[0], 0
        for x in a:
            cur = max(x, cur + x)
            best = max(best, cur)
        out.append(str(best))
    sys.stdout.write("\n".join(out) + "\n")    # one write at the end

main()

Input 2 / 5 / -2 1 -3 4 -1 / 3 / -5 -2 -9 (one token group per line) prints 4 and -2. The Python version reads all tokens at once, which makes it robust to inputs split across lines unexpectedly, and is much faster than calling input() in a loop for large inputs.

Language-specific traps

• Python: recursion depth defaults to about 1,000. Deep DFS on a 10⁵-node tree will crash. Prefer iterative DFS/BFS, or raise the limit with sys.setrecursionlimit knowing it can still hit stack limits. Use collections.deque for queues.
• Java: Scanner is slow for large inputs; use BufferedReader with StringTokenizer. Watch Integer comparisons with == (compares references outside a small cached range); use .equals() or unbox. Our Java collections guide covers the other traps.
• C++: int overflow, uninitialised variables, and endl in tight loops. Know your STL; the C++ STL guide is a quick refresher.

Partial Score Strategy: Bank Points First

Because scoring is per test case, the OA is closer to an exam with partial marks than to a pass/fail interview. A few strategic rules follow from that.

1. Read every problem first (5 minutes total). Rank them by how confident you are, not by order.
2. Fully solve the easiest problem first. A complete solution banks 100% of that problem's points and calms your nerves.
3. On a hard problem, submit a brute force early. If the optimal solution isn't clear within 10–15 minutes, write the simplest correct solution and submit it. It typically passes small cases. Then work on optimising.
4. Handle special cases cheaply. If the full problem is hard but a special case (all values positive, n small) is easy, handling it separately can earn extra cases.
5. Never leave a problem at zero if you have any correct approach, however slow.
6. Resubmit often. Most platforms grade your last (or best) submission; submitting improvements as you go protects you if time runs out.

Testing and Stress-Testing Your Solution

"Passes samples, fails hidden tests" is the most common OA frustration. A systematic test list catches most of it.

The edge-case checklist

Stress-testing with a brute force

When you have spare time and a doubt about correctness, write a brute force and compare it with your fast solution on many small random inputs. It's the single most effective way to find logic bugs, and it takes a few minutes in Python:

import random

def brute(a):
    return max(sum(a[i:j + 1]) for i in range(len(a)) for j in range(i, len(a)))

def fast(a):
    best, cur = a[0], 0
    for x in a:
        cur = max(x, cur + x)
        best = max(best, cur)
    return best

for trial in range(2000):
    n = random.randint(1, 8)
    a = [random.randint(-10, 10) for _ in range(n)]
    if brute(a) != fast(a):
        print("MISMATCH", a, brute(a), fast(a))
        break
else:
    print("all 2000 random tests passed")

Small sizes and small value ranges are deliberate: they make bugs likely to appear and easy to read when they do. If the platform lets you run custom code, you can do this in the editor; otherwise, do it as practice habit beforehand so you develop the instinct for which cases break which algorithms.

Time Management for a 90-Minute, 3-Problem OA

A concrete plan for a common format (three problems: easy, medium, hard):

Two time rules: don't debug in silence for more than 10 minutes (switch problems and return fresh), and don't leave submitting to the last minute, because submissions can queue and the timer won't wait. For the problem-solving method itself, our guide on how to approach a DSA problem applies just as well to OAs.

MCQ, SQL and Aptitude Sections

Many OAs, especially for freshers and mass hiring, add non-coding sections. They're often separately timed and sometimes have negative marking, so read the instructions before the first question.

Two tactics: if there's negative marking, skip questions where you can't eliminate at least two options; if there isn't, never leave a question blank. And for "predict the output" questions, trace on paper rather than in your head, because they're designed around subtle details like integer division, pre- vs post-increment and short-circuit evaluation.

Proctoring Rules: What's Monitored and What Gets Flagged

Employers configure proctoring per test, so what's enabled varies. Assume any of these may be active:

• Webcam and screen monitoring, including snapshots or recordings, and checks for multiple faces or no face.
• Tab-switch and window-focus tracking: leaving the test tab is logged.
• Copy-paste tracking: large pastes into the editor are logged.
• Full-screen enforcement: exiting full screen may be logged or end the test.
• Plagiarism detection: your code is compared with other candidates' submissions and with known sources online. Code shared on Telegram groups for a running OA gets flagged.
• AI-assistance detection is increasingly discussed. Regardless of detection, using AI tools when the instructions prohibit external help is a violation, and you'll face the same problems live in interviews anyway.

What's usually allowed (check your instructions)

• Pen and paper for working out examples.
• Using the platform's own editor features and custom input.
• Language documentation, only if the instructions explicitly permit it.

Your Environment Checklist Before Starting

1. Uninterrupted block of the test length plus 20 minutes. Tell family or roommates.
2. Stable internet, with a mobile hotspot as backup.
3. Laptop charged and plugged in; notifications and auto-updates off.
4. Updated browser as recommended by the platform; close other tabs and apps (especially chat apps that pop up).
5. Webcam and microphone tested if proctoring is enabled; good lighting on your face.
6. Practice test completed on the same platform to learn the editor.
7. Template typed from memory once before starting, so it's fresh.
8. Water, paper and pen on the desk.

Also choose your timing: don't start a 90-minute OA at 1 am after a long day. Many invites give you a window of several days; use the slot when you're sharpest.

A Three-Week OA Practice Plan

OA performance improves fastest with timed practice in OA-like conditions, not with more untimed problem-solving.

Timed contests on LeetCode, Codeforces or CodeChef are excellent OA practice because they combine pressure, unseen problems and hidden tests. If you're preparing for a specific company, also read its OA guide; for example, our Amazon OA guide covers Amazon's work style and simulation sections that general practice won't prepare you for.

Keep an OA error log

After every practice OA, record each lost test case under one of these causes: wrong algorithm, wrong complexity (timeout), overflow, edge case, I/O format, or ran out of time. After three or four OAs, the log tells you exactly what to fix. Most people discover that a large share of their lost points come from the "boring" categories (overflow, edge cases, I/O), which are the cheapest to fix.

Clearing OAs is a learnable, mechanical skill layered on top of DSA knowledge. Read constraints first, use a practised template, bank partial credit, test edges, manage time deliberately and stay clean on proctoring, and your OA scores will reflect your real ability.

Frequently Asked Questions

Pranjal Jain

Ex-Microsoft SDE · IIT Kanpur · Founder of Prepflix. Helps engineers crack startup and product company interviews across India.