In a timed online coding assessment with three problems, how should you decide the order to attempt them?
answer
- The listed order is not a ranking
- First minutes are for reading, not typing
- Price each problem before starting it
- Cheapest full solve first, hardest last
- Every budget needs a hard stop
basics
~20 sRead all three problems before writing code, then attempt them cheapest-first rather than in the listed order. The given order is not a difficulty ranking, and banking the solves you are sure of protects points the clock would otherwise take.
solid answer
~40 sI spend the first four or five minutes reading every problem end to end, constraints included, and tagging each one cheap, medium or expensive. Then I attempt them in ascending order of expected cost and give each a written time budget with a hard stop. For an 82-minute, three-problem assessment that might be roughly 15, 25 and 35 minutes with the remainder as slack for submitting. The classic way to lose one of these is to start at the first problem, discover it is the expensive one, and reach the last problem with nine minutes left and nothing submitted. Cheapest-first means that if the clock beats me, it beats me on the problem I was least likely to finish anyway.
go deeper
Know that you read every problem before typing and that the listed order is not a difficulty order. This much test-taking discipline is expected on a first assessment, and it is where most avoidable points are lost.
Be able to describe the mechanics: pricing each problem during a short read-through, ordering by expected cost rather than by point weight, and reserving slack at the end to submit on every problem.
Show what you do when the plan breaks — how you decide mid-window to abandon a problem you mispriced, and how you weigh a certain partial score against a possible full one.
Own the tradeoff that triage optimises for the score, not for showing depth, and that a stage gated this way selects partly for exam technique. If you set such a stage for a team, that is the bias you are accepting.
## The shape of the stage An automated online assessment gives you a fixed window, a set of independent problems, and a grader that scores each submission against a hidden suite of test cases. Nobody is watching you think. The only thing that leaves the room is a score report: how many points each problem earned, when you submitted, and how the window was spent. That makes an assessment a *test-taking* problem sitting on top of a coding problem, and the single largest score swing available to most candidates is the order they attempt the problems in. ## Why the presented order is not a ranking Problems are usually assembled from a bank and slotted into a template. The order can reflect a rough intent, but it is not a promise, and problem weights are frequently uneven — a harder problem carries more points precisely because fewer people finish it. Two consequences follow. First, the most expensive problem can sit first. Second, the cheapest problem can sit last, where the clock never reaches it. A worked illustration, invented but typical: a mid-size product consultancy screens junior frontend candidates with an 82-minute, three-problem assessment. The weights are 300, 120 and 180 points, and each problem is scored on its hidden tests — 26, 11 and 17 of them respectively. The first problem is the expensive one. | Candidate | Order taken | Result | |---|---|---| | A | 1, 2, 3 as listed | 51 minutes on problem 1 (14 of 26 tests, 162), 22 rushed minutes on problem 2 (9 of 11, 98), 9 minutes left for problem 3 and nothing submitted (0). Total 260 of 600. | | B | 2, 3, 1 after reading all three | Problem 2 in 11 minutes (11 of 11, 120), problem 3 in 24 minutes (16 of 17, 169), problem 1 with the remaining window and a hard stop, submitting a correct but slow version (19 of 26, 219). Total 508 of 600. | Same skill, same problems, roughly double the score. Candidate A did not run out of ability; they ran out of clock on the problem that was always going to be hardest, and paid for it with the cheap points they never reached. ## The routine 1. **Read everything first.** Four or five minutes reading all the problem statements, including the constraints and the output format, is not lost time — it is the only time you will get to price the work. 2. **Tag each problem.** Cheap (you can see the whole solution), medium (you can see the approach but not the details), expensive (you would need to think). Note the point weights beside the tags. 3. **Order by expected cost, not by weight.** A 300-point problem you have a 30 percent chance of finishing is worth less than a 120-point problem you will certainly finish. 4. **Budget with hard stops.** Write the minute at which you will leave each problem before you start it. The stop is the whole point of the budget. 5. **Keep slack.** Reserve the last several minutes to submit whatever exists on every problem, re-read output formats, and make sure your best version is the one sitting in the editor at the buzzer. ## When the plan is wrong Misjudging a problem during the read-through is normal. What separates a good run from a bad one is what happens at the hard stop: you take the partial score you have banked and move on rather than sinking another twelve minutes into the sunk cost. If you finish early, you can always come back — an abandoned problem is still there, and a returned-to problem starts from your last saved code. ## What triage is not Triage does not make you better at the underlying problems, and it will not rescue a run where nothing was solvable. It protects you from the one failure that is purely procedural: attempting the problems in the order given and timing out on the hardest with the cheap ones untouched.
- You have nineteen minutes left and only a brute-force solution you are confident is correct — do you submit it?Yes, submit the correct slow version immediately, then optimise on top of it. Banked points cannot be taken away, and a partially passing submission usually beats an elegant one that never compiled. Check the instructions for whether the grader keeps your final submission or your best one; where only the final counts, re-submit the working version before the window closes.
- How do you set per-problem time budgets before you know how hard the problems are?Set them right after the read-through, not before it. Divide the usable window by the number of problems, then shift minutes toward the ones you tagged expensive and away from the ones you can already see the solution to. Hold back roughly a tenth of the window as slack for submitting and re-checking output formats.
- Twenty minutes in you realise you misjudged which problem was cheapest — what do you do?Re-rank on the evidence you now have and move at the next natural break rather than at the end of the problem. Save what you have written so the partial solution is still there, take the score it earns, and start the problem you now believe is cheapest. The cost of switching is small; the cost of finishing a misjudged problem out of stubbornness is the whole window.
saying these in an interview costs you the question
- Starting the first problem immediately without reading the others
- Treating the presented problem order as a difficulty order
- Letting one expensive problem consume most of the window
- Setting time budgets but never enforcing a hard stop
- Reaching the buzzer with a working solution never submitted