Algorithm Arena · Mini Task - Advanced
Mini Task Advanced - Coding Guide
A advanced-level coding challenge: two warm-up questions, real code run against real tests in your browser, then two wrap-up questions.
What is Big-O notation?
Big-O notation describes how the running time or memory use of an algorithm grows as the size of its input grows, stripping away constant factors and lower-order terms to focus on the dominant trend. An algorithm that touches every element of an n-element input once is O(n); one that touches every pair is O(n squared); one that halves its search space each step is O(log n). The letter n stands for input size, and the notation answers one question: as n gets large, what shape does the cost curve take.
The reason to think in growth rates rather than exact timings is that constant factors and hardware speed wash out at scale while growth rate does not. A quadratic algorithm running on a fast machine will still eventually lose to a linear algorithm on a slow machine, once n is large enough - the crossover point may be small or large, but it always arrives. Common classes, from cheapest to most expensive, are O(1) constant, O(log n) logarithmic, O(n) linear, O(n log n) linearithmic, O(n squared) quadratic, and O(2^n) exponential, and most interview problems live somewhere on that ladder.
Space complexity applies the same idea to memory: how much additional storage an algorithm allocates as a function of input size, separate from the input itself. Building a new array of length n uses O(n) auxiliary space; a fixed number of scalar variables regardless of n uses O(1) space. Many algorithms trade time for space or vice versa, and stating both costs is part of a complete answer.
The reliable way to find an algorithm's complexity is to count operations by structure: identify the loops, note how many times each runs as a function of n, and price whatever happens inside them - a hash-map lookup is constant, a linear scan or array splice is O(n), a sort is O(n log n). Nested loops over the same input multiply their costs; sequential blocks add.
This kind of analysis is the standard follow-up in software and quant-dev coding interviews once code works: an interviewer who has just watched a candidate write a correct function almost always asks what it costs, and whether a cheaper approach exists. Being able to state and defend that cost is what separates a working answer from a strong one.
How it works
Pick the Advanced level on the Mini Task screen and choose a challenge from the list. Every challenge follows the same four-stage path: a warm-up of multiple-choice questions about the idea behind the problem, a coding stage where you write a JavaScript function in the editor, a wrap-up of multiple-choice questions about the solution you just built, and a done screen. Advanced challenges are full interview problems - binary search over strikes, Dijkstra-style routing, inversion counting - where both the algorithm choice and a careful implementation are graded by the tests.
In the coding stage you edit starter code that already declares the function signature. Pressing "Run tests" executes your code inside a sandboxed Web Worker in your browser - no server round trip - against the challenge's fixed test cases. Each case shows a pass or fail row; a failure shows the value your function returned or the error it threw. Code that hangs is killed by a timeout and reported as timed out. You cannot continue to the wrap-up until every test case passes, and a "Reveal solution" button shows the reference solution at any time.
This entry covers every Advanced challenge after the first one - the first challenge in the list is billed under its own "-01" game id as the free taster, and the rest share this id.
How scoring works
There is no points system inside a challenge. Progress is gated: all test cases must pass before the wrap-up questions unlock, and finishing the wrap-up marks the problem cleared.
The HUD tracks three running counters across your session at a level: challenges cleared, and your multiple-choice total as correct answers over questions seen (warm-up and wrap-up combined). The done screen for each challenge reports your multiple-choice score for that challenge out of the warm-up plus wrap-up question count. Changing level resets the counters.
Multiple-choice answers lock on first click - you cannot change an answer after selecting, and the correct choice plus an explanation are revealed immediately.
Read the warm-up as a briefing
The warm-up questions are written about the idea behind the challenge you are about to code. That means they routinely name the exact technique the reference solution uses - a bitwise trick, a specific built-in chain, a data structure. Read them as a briefing: if a warm-up asks which expression detects a power of two, the coding stage almost certainly wants that expression.
Because answers lock on first click, slow down on the warm-up even though nothing gates on it. The explanations shown after each answer are short lessons; the multiple-choice total on the HUD is the only record of how carefully you read them, and it follows you across every challenge at the level.
Let the test cases design your function
Every challenge ships a fixed, visible list of labeled test cases, and the pass condition is exact: your return value is compared to the expected value by JSON serialization. Before writing a line, scan the case labels for the edge cases - empty string, zero, negative input, a single element. Those are the cases that break a first draft, and they are shown to you up front.
The JSON comparison has a practical consequence: return the right shape, not just the right numbers. An array where a scalar is expected, or a string where a boolean is expected, fails even if it looks right when printed. When a case fails, the readout shows exactly what you returned - debug from that, not from re-reading your code top to bottom.
If you are stuck, run early and often. Runs are instant and sandboxed; a wrong run that shows you the output of one case is worth more than five minutes of staring. The reveal button is a study tool - reading a reference solution and then re-deriving it from a blank editor is a legitimate way to train.
Reason about complexity before the wrap-up asks you to
The wrap-up questions consistently probe the solution you just wrote: its time complexity, its space complexity, what a variant input would do, or a slower-but-valid alternative. So while your tests are passing, form the answers in advance - count how many times your loop touches each element, and note every allocation your built-ins make (a split allocates an array of n characters; a join allocates a new string).
This mirrors the interview rhythm exactly: write it, then defend it. Interviewers rarely stop at working code - the follow-up is always cost. Treating each Mini Task as code plus defense is the habit the game is built to install.
A worked example
Take the rookie challenge Reverse a String as the template for how any level plays. The prompt: write reverseString(s) that returns the input reversed. Warm-up question one asks which built-in approach reverses a JS string most directly - the answer is .split("").reverse().join(""), and the explanation notes strings are not arrays, so split converts, reverse flips, join glues. Warm-up two asks the time complexity of that approach - O(n), since each of the three steps touches every character once.
In the coding stage you replace the starter body with: return s.split("").reverse().join("");. Run tests: the five cases check "cat" → "tac", the empty string, a single character, the palindrome "racecar", and "Quant" → "tnauQ". All five pass, unlocking the wrap-up.
Wrap-up one: what does calling the function twice on the same string return? The original string - reversing is its own inverse. Wrap-up two: space complexity? O(n), because split allocates an n-element array and join allocates an n-character string. Finish, and the done screen reports 4/4 multiple-choice with all tests passed. Higher levels follow this identical path with harder problems - the structure never changes, only the material.
Common mistakes
• Guessing warm-up answers fast to reach the code. Answers lock on first click, the explanations are the teaching, and the running MC total is the only score the game keeps.
• Returning the wrong type or shape. Comparison is by JSON serialization, so true and "true" are different answers, and [5] is not 5.
• Ignoring the visible edge-case tests until they fail. Empty inputs, zero, and negatives are listed in the case labels before you write anything - handle them in the first draft.
• Writing an infinite or near-infinite loop and waiting. The worker is killed on a timeout and reports it. A timeout means your loop condition is wrong; the runner is not slow.
• Skipping the mental complexity pass. The wrap-up will ask, and in a real interview the follow-up after working code is always its cost.
Why interviews test this
Quant dev interviews are short-coding-problem interviews: a contained function, visible examples, and an interviewer who follows working code with questions about complexity, edge cases, and alternatives. The Mini Task loop - concept check, implementation against real tests, then a defense of the solution - is that interview compressed into a repeatable rep.
The level ladder maps to how firms calibrate: rookie and novice problems test whether you can translate a clear spec into clean code at all, while intermediate and advanced problems (Kadane-style scans, binary search, heaps, graphs) test whether you reach for the right tool without being told its name.
Play Mini Task - Advanced on Outcry
Mini Task - Advanced is free to play on Outcry, in the Algorithm Arena section, and every run is timed and scored. Read the guide once, then play Mini Task - Advanced and check your score against the strategy above. The guide book has a written guide for every other game, and the practice hub and mock assessments put the same skills under a real screen's clock.