Foundations

Time management in a coding assessment

A timer changes what "good" means. A beautiful approach that you cannot finish is worth less than a plain approach that passes the tests you were given and the edges you thought of. This page is a way to spend a fixed block of time. It is a practice budget, not the official length of any employer's assessment. If your invitation names a duration, use that number. The ratios below still apply.

The format guide explains why the duration is not something you should invent from a forum post. This page assumes you are already inside a coding section and the clock is running.

Decide the budget before you read the problem

Before the first prompt, split the section into phases on a piece of paper or in a comment at the top of the editor. For a single problem inside a longer section, a useful split is:

• about 15 percent to read and restate
• about 15 percent to build examples, including one edge
• about 40 percent to implement the simplest correct idea
• about 20 percent to test and fix
• about 10 percent held in reserve

On a 25-minute problem that is roughly four minutes to read, four to make examples, ten to code, five to test, and two minutes you do not spend early. The reserve is not a gift to the reading phase. It is there for the bug you did not expect. Candidates who "just start coding" usually steal that reserve in the first minute and then debug in a panic.

If the section has two problems and one shared clock, do not give the first problem the entire clock by default. A common failure mode is polishing problem one while problem two is untouched. Set a checkpoint: when half the time has passed, you either submit a working first solution or you consciously switch. Switching with a partial solution saved is allowed. Switching with an empty second editor and three minutes left is how people describe a bad day in public write-ups.

Reading is part of the solution

Read the prompt once without writing code. Then write, in a comment, three lines: what the function receives, what it returns, and what it must not do. If you cannot write those lines, you are not ready to choose a data structure. Guessing the signature from the sample input is how off-by-one bugs and wrong return types get born.

Look for constraints while you read. An upper bound on the length of the input is a hint about complexity, not flavor text. A bound of a few hundred can tolerate a slower scan. A bound of a hundred thousand usually cannot tolerate a nested loop over the whole input. Say that out loud: "n is large, so I want something linear or n log n." That sentence is allowed to change your plan. It is cheaper than discovering the time limit after the code is written.

Also look for words that change the algorithm: sorted, unique, positive, circular, in place, stable, any order, the earliest index. "Any pair is acceptable" means you can return when you find one. "All pairs" means you cannot. People miss that distinction and then build the heavier solution by habit. The common mistakes page has more of these reading errors.

Examples before code

Write two examples by hand. The first can be the sample if one was provided. The second should be yours, and it should be slightly mean: an empty collection, a single element, duplicates, or a target that is impossible. Walk the examples with the approach you intend to code, not with the finished code. If you cannot do the steps on paper, the approach is still a vibe.

Here is a tiny rehearsal you can use tonight. Give yourself ten minutes. The task is original: given a list of daily temperatures and a threshold, return how many days are strictly above the threshold. It is deliberately easy. The point is the ritual, not the insight.

def days_above(temps: list[int], threshold: int) -> int:
    count = 0
    for temp in temps:
        if temp > threshold:
            count += 1
    return count


assert days_above([18, 21, 19, 25], 20) == 2
assert days_above([], 20) == 0
assert days_above([20, 20], 20) == 0

Time is linear in the number of days. Extra space is constant. The interesting part of the rehearsal is the third assert: "strictly above" excludes equals. If you had written >= because you felt hurried, the sample of [18, 21, 19, 25] would still pass. The edge case is what catches it. Build that kind of assert before you trust a solution on a harder problem.

Implement the finishable idea

When two ideas are available, pick the one you can type cleanly inside the coding budget. A hash map you have written twenty times beats a segment tree you understood once in a lecture. You can note the faster idea in a comment if you want credit for seeing it. Then write the one you can test.

Name variables after the story in the prompt, not after the textbook. left and right are fine for pointers. i and j are fine if the loop is obvious. temp1 and data are how you lose the plot when a test fails. Short functions are easier to check under a clock than one loop that updates six variables.

If you get stuck for more than a couple of minutes, change the question you are asking. Do not ask "what is the clever trick?" Ask "what is a correct answer for n at most 20?" A slow correct function can sometimes be improved by replacing one scan with a map, which is the move the arrays and hashing page is about. It can also be the thing you submit if the constraints are small. Shipping it is a decision, not a defeat.

Testing is a phase, not a vibe

When the code runs on the sample, you are not done. You are at the start of the testing phase. Re-run your mean example. Then change one thing at a time: an empty input, a one-element input, a duplicate, a value equal to the boundary, and if order matters, a case where two answers look plausible. If the editor has hidden tests, your own cases are still worth running, because the hidden failure will be harder to see.

When a test fails, do not immediately edit. Write the input, the expected output, and the actual output. Find the first line where your mental trace and the program disagree. That is the same skill as the debugging guide, compressed into the reserve you saved earlier. Editing randomly burns the reserve and often introduces a second bug.

If the reserve hits zero and the function is wrong, submit the best version you understand rather than a half-applied idea you cannot explain. Partial credit, where it exists, follows code that is coherent. A tangle of commented-out attempts is difficult for a reviewer and difficult for you if you are allowed to return to the problem.

Two problems, one clock

Practice this once a week with a kitchen timer and two problems you have not memorized. Set the checkpoint at the halfway mark. At the checkpoint, say out loud which problem is in better shape and whether you are switching. You are training the decision, not just the syntax.

A reasonable rule: if problem one already works, stop polishing names and start problem two. If it does not work and the checkpoint has arrived, write the idea in one sentence and move. Some screens let you return. Practice as if you might not.

After the timer, spend ten minutes without a clock on the problem you abandoned. That postmortem is where the pattern sticks. The four-week plan schedules these timed reps so they are not a single cram session the night before.

What to ignore

During a real screen, do not open a forum to check the approach, and do not rewrite working code because it looks plain. Also ignore anyone who quotes a universal minute count for every company's assessment. Screens differ. Use the minutes you actually have.

The plan, repeated until it is boring: restate the input and output, write a mean example, choose a finishable approach, implement it, test the edges, and only then spend leftover time on a faster idea or cleaner names. That sequence is slower for the first five minutes and faster at the end, which is when timed screens are actually decided.