The online assessment

Every submission is run against a hidden set — typically fifteen to thirty cases you never see, including the empty input, the single element, the maximum size and one adversarial case built to blow up an O(n²) solution. Three things get scored:

• Cases passed, usually as a percentage. Most platforms give partial credit — eleven of fifteen is a real score, not a fail.
• Time limit, per case. A correct brute force on n = 10⁵ does not "run slowly", it is killed and marked failed.
• Memory limit, which almost never matters unless you are memoising an entire grid.

The consequence is the whole strategy for this round: a submitted brute force scoring 60% beats an unsubmitted optimal solution scoring nothing, and unsubmitted is what happens when you spend fifty minutes on the elegant version.

Pick the language you will not have to think about. For you that is TypeScript or JavaScript — a round that filters on speed is not the round to prove you know Python.

The trap is input handling. Most platforms hand JavaScript candidates a bare process.stdin and no scaffold, and a real number of people lose the first fifteen minutes to reading input instead of solving anything. Learn this block once and type it from memory:

const lines = require("fs").readFileSync(0, "utf8").split("\n");

let p = 0;
const nextLine = () => lines[p++];
const nextInt = () => Number(nextLine().trim());
const nextInts = () => nextLine().trim().split(/\s+/).map(Number);

const n = nextInt();
const arr = nextInts();

const out = [];
out.push(solve(n, arr));
console.log(out.join("\n"));

Two more JavaScript-specific things that fail silently on a platform and never in your editor:

• Integer overflow. Anything past 2⁵³ needs BigInt. Sum-of-large-numbers problems are written specifically to catch this.
• Recursion depth. Node blows the stack around ten thousand frames. A recursive DFS over 10⁵ nodes crashes — convert to an explicit stack.
• Printing inside a loop. console.log per line on 10⁵ lines is slow enough to time out on its own. Buffer into an array and print once, as above.

Product and service assessments usually bolt fifteen to twenty-five multiple-choice questions onto the front. Candidates skip preparing for them entirely and then lose the cutoff by four marks. They come from a small, predictable pool:

• Output prediction. Hoisting, this, closures in loops, promise versus setTimeout ordering, type coercion. This is R3 content in multiple-choice form — if you have read that round, you already have these.
• Complexity. "What is the time complexity of this snippet?" Nested loop over the same array, binary search inside a loop, sort then scan.
• SQL. One or two: what a LEFT JOIN returns when the right side is empty, what GROUP BY without an aggregate does, index usage. R6 covers this properly.
• HTTP and web basics. Status codes, idempotency, CORS, what a preflight is.
• Occasionally aptitude. Percentages, ratios, one series. Service companies only. Do not lose sleep, but do not be surprised.

Answer every one — there is no negative marking on any platform in common use, so a blank is strictly worse than a guess.

• 0–5 min. Read both problems before writing anything. Then start with the one you can see the ending of. There are no bonus marks for order and the second problem is not always the harder one.
• 5–20 min. Brute force the easier one, submit it, and take the partial score. It is now banked and cannot be lost.
• 20–40 min. Optimise only if the brute force actually timed out. If it passed everything, do not touch it — go to the second problem.
• 40–55 min. Second problem, same pattern: working first, fast second.
• 55–60 min. Submit everything, including the half-solution. Test one edge case per problem with custom input.

The people who fail this round are almost never the people who could not solve the problems. They are the people who solved one beautifully and ran out of clock on the other.

Assume everything is recorded, because it is. Standard proctoring on HackerRank, Codility, HackerEarth and CodeSignal logs all of this:

• Tab and window focus. Every time you leave the tab is timestamped and shown to the reviewer as a count. Two or three is normal and nobody cares. Fifteen reads as a second screen.
• Full-screen exit, if the test enforces it. Exiting can end the attempt outright on strict settings.
• Paste events. A 40-line paste into an empty editor is flagged and shown as one event with a size. Typing your own boilerplate takes twenty seconds and looks like typing.
• Webcam and screen capture, on senior and remote-first roles. Sit somewhere plain, and do not talk to anyone in the room.
• Code similarity. Submissions are compared against every other submission for that problem and against public solutions. A pasted LeetCode answer with the variable names intact is the most-caught thing in this round.

• Fixed-window OA. "Complete within 72 hours, 90 minutes once you open it." Open it when you are sharp, not at 11pm because it expires tomorrow. The window is for scheduling; the clock inside is real.
• Certified assessment. CodeSignal-style, one score reused across many companies. Worth taking seriously once — a good score gets you skipped past this round elsewhere for a year.
• The 24-hour take-home OA. A small build task on the platform rather than DSA. This is a take-home round wearing an OA badge — read that chapter, not this one.
• The paired follow-up. Some companies bring your OA solution into the next round and ask you to explain or extend it. Keep a copy of what you submitted. You will not get it back from the platform.

OA rejections are almost never communicated, and the cutoff is not published. Three real reasons, in order of frequency:

• You were under the cutoff, which is often set at a percentile of that week's applicant pool rather than an absolute score. The same submission passes in a quiet week.
• A proctoring flag put your attempt in a manual review queue that nobody drained.
• Nothing to do with you. The role was filled or frozen and the pipeline was dropped whole.

The useful response is to keep your own record: date, company, platform, problems, roughly what you scored. After four of them a pattern shows up — usually "I keep timing out on the second problem", which is a fixable thing, not a talent problem.