Online assessment tomorrow: how to prepare in one evening

An online assessment is graded by hidden tests and a clock, not by a person who watches you think. So tonight is not for new algorithms. Spend three hours on the four things that actually decide an OA score: a paste-ready input template in the language you will submit in, two full-length timed problems, a written edge-case sweep, and the logistics that eat your first ten minutes tomorrow if you leave them until then.

An OA takes away three things a live round gives you

Most last-minute advice is written for a 45-minute conversation with an engineer. An OA removes the engineer, and every removal changes what you should practise tonight.

One nuance worth flagging rather than asserting: scoring differs by platform. Some award partial credit per passing test, others want every test green. If your invitation email does not say, assume partial credit exists and submit early and often, because that assumption is cheap when wrong and expensive when right.

The three-hour evening plan

Offsets from the moment you sit down. Do both problems in the exact language you will submit in tomorrow. Not the language you are learning. Not the one that benchmarks faster. The one where you can write a hashmap, a custom sort and a queue without pausing to remember the syntax.

The template you paste before reading the first problem

Fast input parsing is worth having ready because it is pure overhead: it earns no points, and improvised under a clock it fails the same way every time. Python first.

import sys
from collections import defaultdict, deque, Counter
import heapq, bisect, math

def solve(n, a):
    # one line here first: the approach and its complexity
    return 0

def main():
    data = sys.stdin.buffer.read().split()
    pos = 0
    def ni():
        nonlocal pos
        pos += 1
        return int(data[pos - 1])
    def ns():
        nonlocal pos
        pos += 1
        return data[pos - 1].decode()

    n = ni()
    a = [ni() for _ in range(n)]
    sys.stdout.write(str(solve(n, a)) + "\n")

def selftest():
    for case in ([], [7], [3, 3, 3], [-4, 0, 9], list(range(200000))):
        print(len(case), solve(len(case), case))

if __name__ == "__main__":
    sys.setrecursionlimit(300000)
    main()

Two notes on that. Reading sys.stdin.buffer.read() once, rather than calling input() inside a loop, is the difference between passing and timing out on the largest hidden test in Python. And deep recursion is the classic Python OA failure: if your solution recurses over a long linked list or a 1000 by 1000 grid, convert it to an explicit stack rather than trusting a raised limit, because the interpreter can still die on the real stack instead of raising something you can catch. The selftest function is the harness for the checklist below, and it is also the thing you delete before you submit.

The Java equivalent, since browser editors rarely give you completion worth using:

import java.io.*;
import java.util.*;

public class Main {
    static StreamTokenizer in = new StreamTokenizer(new BufferedInputStream(System.in));
    static PrintWriter out = new PrintWriter(new BufferedOutputStream(System.out));

    static int ni() throws IOException { in.nextToken(); return (int) in.nval; }

    static long solve(int n, long[] a) {
        // approach and complexity in one line, before any code
        return 0L;
    }

    public static void main(String[] args) throws IOException {
        int n = ni();
        long[] a = new long[n];
        for (int i = 0; i < n; i++) a[i] = ni();
        out.println(solve(n, a));
        out.flush();
    }
}

Note the deliberate long[] for the values and the long return type even when the problem looks like it fits in an int. That one choice prevents the most common silent OA failure, described below. A caveat on StreamTokenizer: it parses numbers through a double, so if the constraints permit magnitudes beyond about nine quadrillion, read tokens as strings with a BufferedReader and Long.parseLong instead. Also remember the out.flush(). Buffered output that is never flushed produces an empty submission and a score of zero on code that was correct.

Let the constraints choose the complexity

In a live round you can ask. In an OA the constraint line is the hint, and it is the only one you get. Read it before the story about warehouses and robots.

The edge cases hidden tests love

Run this list before every submit. It takes about ninety seconds and it is the highest-scoring ninety seconds in the assessment, because these are the cases a test author adds on purpose.

1. Empty input. n equals zero, an empty string, an empty list. What does your loop return? Plenty of solutions return something sensible by luck, and plenty crash on a[0].
2. A single element. Any two-pointer, sliding window or pairwise comparison that quietly assumes two items breaks here.
3. All elements identical. The killer for two-pointer duplicate skipping, and for anything that used a set where a multiset was meant.
4. Duplicates where the story implied uniqueness. The prompt says "user IDs" and you assume they are distinct. The constraints never said so.
5. Integer overflow. Two hundred thousand values of up to a billion sum to 2 times 10 to the 14, which wraps silently in a 32-bit int in Java, C++ or C#. The three usual sites are running sums, products, and the midpoint in a binary search. Python is immune here, which is one honest reason to pick it.
6. Negatives and zero. Prefix sums, division, the modulo of a negative number, and any greedy that assumed values only ever grow.
7. Already sorted and reverse sorted input. The pathological case for a naive partition and for anything that early-exits on the first comparison.
8. The maximum size the constraints allow. Generate it locally with a one-line loop and time it. Correct plus too slow scores what wrong scores.
9. Off-by-one on indexing. Problems that describe positions as 1-indexed while your array is 0-indexed give answers that are the right shape and wrong by one, which is exactly the failure that passes the samples.
10. Output format. A trailing space, a missing newline, a float printed where an integer was expected, an unsorted answer for a result the grader compares in order. String comparison forgives none of it.

Where this plan stops working

This is a sharpening plan and it assumes a base. If you have never written a breadth-first search or a hashmap counting solution, one evening will not create that, and the realistic goal shifts to passing the visible sample tests on both problems rather than clearing every hidden one. Nothing above helps a domain assessment either. A SQL round, a front-end build task or a language-specific quiz needs its own rehearsal.

Be equally clear-eyed about tooling, ours included. OfferPilot AI runs on Windows 10 and 11 only, with no macOS, Linux, mobile or browser version, so if you are taking the assessment on a MacBook tomorrow, tonight's practice hours are the only place it fits at all. Its overlay is excluded from screen capture at the operating-system level, which means it does not appear in Zoom, Teams, Meet or a screen recording. That statement is about screen sharing and nothing else. It does nothing about webcam monitoring, a lockdown browser, a proctor watching you in person, eye tracking, or a second-device camera, and online assessments commonly use exactly those. Where an assessment's rules forbid outside assistance, the honest place for any tool is the evening before, not the assessment window. If you are unsure what your platform monitors, the invitation email and the platform's own candidate FAQ are the sources to trust, not a forum thread.

Tomorrow morning

Read your edge-case card twice. Paste the template into a scratch file so it is one keystroke away. Open the assessment with two hours of clear runway rather than twenty minutes before the deadline, because a browser or network problem at that point costs the whole score. Then read the constraints first, write the approach line, and start.

One last thing that is easy to skip: decide in advance what you do when a problem is not falling. Fifteen minutes, then the brute force gets written and submitted, then you move on and come back if the clock allows. Deciding that now is worth more tomorrow than any pattern you could still cram tonight.

Related guides

• How to Prepare for a Coding Interview in 1 Week: 7-Day Plan
• 3-Day Coding Interview Prep Plan: Hour-by-Hour Schedule
• The Night Before a Coding Interview: A 6pm to Lights-Out Plan
• How Long to Prepare for a FAANG Interview: 4 Real Timelines
• Coding Interview Prep in 1 Month While Working Full Time