Mini Task - Advanced

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 actually 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.

Use the warm-up as a spoiler, not a quiz

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 free, instant, and sandboxed; a wrong run that shows you the actual output of one case is worth more than five minutes of staring. The reveal button exists as a genuine 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, rather than code alone, 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, not that the runner is 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.