Coding rounds: formats and what gets scored

Every coding round gives you a problem and a fixed amount of time. What differs is who judges the result and what they count. In a live interview a person watches you think; in an online assessment a program runs hidden tests on whatever you submit; in an AI-assisted round you also direct an assistant and answer for the code it writes. The same habits help in all three, but each one rewards and punishes different things, so it pays to know which kind you are walking into. This lesson compares the three, shows how an automated judge turns hidden tests into a score, and ends with the checks to run on a platform before the day.

Three formats of coding round

In short:

• Live interview. An interviewer watches you work and asks questions; you earn credit for your reasoning, your code and how you test it.
• Online assessment. Hidden test cases check what you submit; you earn credit for each test your code passes.
• AI-assisted round. You work with an AI assistant, either one built into the interview platform or one you choose, while an interviewer watches; you earn credit for how you break the task down, steer the assistant and check its code.

Live interviews

You share an editor (or a whiteboard) with an interviewer, who gives you a problem and stays for the whole session. The code matters, but so does everything around it: the questions you ask before you start, the plan you say out loud, how you react to a hint and whether you test what you wrote. An interviewer can also rescue you. Mention a wrong assumption early and you will usually be corrected; keep it to yourself and you may solve the wrong problem very well.

Online assessments

An online assessment (OA) is a timed test on a platform, usually taken alone. You read a statement, write code, and the platform runs it against test cases. A few are sample cases you can see; the rest are hidden. HackerRank’s documentation of its coding questions describes how the score works there: each test case carries its own points, you get all of them or none, and your score is the sum over the cases you pass. No one hears your reasoning, so the score is only as good as your handling of edge cases and large inputs.

AI-assisted rounds

Some companies now expect you to use AI during the interview itself. Meta’s public hiring page says that select roles include an authorised AI assistant inside CoderPad during technical interviews, that candidates are expected to use it, and that outside AI tools are not allowed. Canva’s engineering blog describes a round in which backend, machine-learning and front-end candidates are expected to use AI tools of their own choice, on problems that are more complex, more ambiguous and closer to real product work than classic puzzles. It lists what the interviewers look for: breaking unclear requirements into parts, deciding where AI helps, and finding and fixing problems in the code it produces. So the quickest way to lose points in such a round is to accept generated code without reading or testing it.

Neither page says the skills of a classic round stop mattering. Canva’s post says computer-science fundamentals are still assessed, and every code review of AI output is a reading, testing and debugging task. A later module of this track, on coding rounds with AI, practises exactly those skills.

What an interviewer writes down

Interviewers usually judge a round against a rubric: they score each area, or the session as a whole, and the decision weighs everything together rather than applying a strict cut-off. A public rubric from the open-source Tech Interview Handbook, released under the MIT licence, uses four areas: communication, problem solving, technical competency and testing. Its author notes that the rubrics of large companies differ mostly in their wording, not in what they look at. Here are ordinary things you do in a round, under the area each one counts for:

• Communication: asking whether the input can be empty and what to return then; saying your plan and what it costs before you start typing.
• Problem solving: starting from a brute force and improving it, naming the work you remove; stating the time and space complexity of the final code correctly.
• Technical competency: writing short, well-named functions with no repeated code; using the language’s own tools, such as a dictionary’s get with a default.
• Testing: tracing your code on a small example by hand and fixing the bug you find; checking the empty input and the largest input before you say you are done.

Two things follow. First, silence costs you twice: an interviewer who cannot hear your plan has nothing to write under communication, and cannot steer you before you waste time. Second, testing is an area of its own. Finding and fixing your own bug is evidence in your favour, not a mark against you; the lowest testing rating in that rubric describes a candidate who calls the code finished with obvious bugs and no basic tests.

How an online assessment adds up your score

Here is an original problem in the style of an OA. Its judge runs ten tests worth one point each: the first is the sample that the statement shows, and the other nine are hidden.

Three people submit three different solutions. The first walks forward from every day (a correct brute force, but O(n²) for a long streak), the second makes one pass but has a bug, and the third makes one pass correctly:

"""A toy online-assessment judge: ten tests (the sample first), one point each, all or nothing.

Real judges stop a program after a time limit in seconds. This one counts the lines a
submission executes instead, so its verdicts are the same on every computer."""
import sys

from submissions import brute_force, fast_end_missed, fast_fixed

STEP_LIMIT = 200_000


class TooSlow(Exception):
    pass


def run_limited(solution, steps, goal):
    """Run one submission on one test; return its answer and the lines it executed."""
    executed = 0

    def count_lines(frame, event, arg):
        nonlocal executed
        if event == "line":
            executed += 1
            if executed > STEP_LIMIT:
                raise TooSlow
        return count_lines

    sys.settrace(count_lines)
    try:
        answer = solution(steps, goal)
    finally:
        sys.settrace(None)
    return answer, executed


N = 3_000
TESTS = [  # (steps, goal, expected answer)
    ([5000, 7200, 8100, 3000, 9000, 9100, 9900, 2000], 7000, 3),  # 1: the sample
    ([], 7000, 0),  # 2: no days at all
    ([1000, 2000, 3000], 7000, 0),  # 3: the goal is never met
    ([8000] * 5, 7000, 5),  # 4: every day meets the goal
    ([8000, 1000, 7000, 7500, 7600], 7000, 3),  # 5: the longest streak ends on the last day
    ([7000, 7000, 6999, 7000], 7000, 2),  # 6: exactly the goal counts
    ([12000], 7000, 1),  # 7: a single day
    ([0 if i % 20 == 0 else 9000 for i in range(N)], 7000, 19),  # 8: long, many short streaks
    ([9000] * N, 7000, N),  # 9: long, one streak
    ([0] * (N // 2) + [9000] * (N // 2), 7000, N // 2),  # 10: long, the streak at the end
]

print("P = pass, W = wrong answer, T = too slow (over", f"{STEP_LIMIT:,}", "lines)")
print(f"{'test':17}" + "".join(f"{i:>3}" for i in range(1, 11)) + "   score")
most = 0
for solution in (brute_force, fast_end_missed, fast_fixed):
    marks = []
    for steps, goal, expected in TESTS:
        try:
            answer, executed = run_limited(solution, steps, goal)
        except TooSlow:
            marks.append("T")
            continue
        marks.append("P" if answer == expected else "W")
        if solution is fast_fixed:
            most = max(most, executed)
    score = marks.count("P")
    print(f"{solution.__name__:17}" + "".join(f"{m:>3}" for m in marks) + f"   {score}/10")
print(f"fast_fixed executed at most {most:,} lines on one test.")

P = pass, W = wrong answer, T = too slow (over 200,000 lines)
test               1  2  3  4  5  6  7  8  9 10   score
brute_force        P  P  P  P  P  P  P  P  T  T   8/10
fast_end_missed    P  P  P  W  W  P  W  P  W  W   5/10
fast_fixed         P  P  P  P  P  P  P  P  P  P   10/10
fast_fixed executed at most 9,003 lines on one test.

"""Three submissions to one online-assessment problem: the longest streak of
consecutive days on which a walker reached the daily step goal."""


def brute_force(steps, goal):
    # Start a streak on every day and walk forward while the goal is met: O(n^2).
    best = 0
    for start in range(len(steps)):
        length = 0
        while start + length < len(steps) and steps[start + length] >= goal:
            length += 1
        best = max(best, length)
    return best


def fast_end_missed(steps, goal):
    # One pass, O(n), but a streak is only compared with the best when a day breaks it.
    best = run = 0
    for count in steps:
        if count >= goal:
            run += 1
        else:
            best = max(best, run)
            run = 0
    return best


def fast_fixed(steps, goal):
    # One pass, O(n): the streak is compared with the best after every day.
    best = run = 0
    for count in steps:
        run = run + 1 if count >= goal else 0
        best = max(best, run)
    return best

Read the table one row at a time:

• The brute force is correct, but it scores 8. It passes every small test and fails tests 9 and 10, long inputs (3,000 days here, to keep the toy quick) that contain a long streak, because it starts over on every day of the streak. A real judge would stop it at the time limit; this toy one stops it after 200,000 executed lines (sys.settrace lets a program watch every line that runs), so it gives the same verdict on every computer.
• The one-pass solution with a bug scores only 5. It is fast, but it compares the current streak with the best only when a day breaks the streak. When the longest streak runs to the last day, as in tests 4, 5, 7, 9 and 10, it is never counted. Notice that it passes the sample: a single visible case can easily miss the bug you have.
• The fixed version scores 10, using at most about 9,000 lines on the longest test, well under the limit.

A slow but correct solution beat a fast but wrong one. In an OA, submit something correct early, then improve it. A missed case that your tests did not cover costs every hidden test that contains it, and you will not be told which case it was.

The same bug in a live round

In a live interview, the bug in fast_end_missed can be caught before any test runs, because you are expected to trace your code by hand. A short trace on two days that both meet the goal is enough:

1. Before the loop, best and run are both 0.
2. Day 1 meets the goal, so run becomes 1; nothing updates best.
3. Day 2 meets the goal, so run becomes 2; still nothing updates best.
4. The loop ends and the function returns best, which is 0, but the answer is 2.

Spotting this yourself, saying “the last streak is never recorded” and moving the comparison inside the loop scores under testing. The same bug in an OA is five silent failures.

Check the platform before the round

The machine that runs your code in a round is not your laptop. Platforms publish their language versions, and they are often older than the ones you practise with. Here is what two platforms’ own pages list:

• HackerRank coding questions (its execution-environment and coding-question pages): Python 3.14.2, Node.js v20.15.1 and OpenJDK 21.0.4 as the newest Java. Time limits: Python 10 s, Java and Go 4 s, C and C++ 2 s. Your code is checked by test cases, each worth its own points, all or nothing.
• CoderPad interview pads (its language pages): CPython 3.10, Node.js v16 and OpenJDK 20. No time limit is stated; you run the code yourself, and the interviewer reads it and what it prints.

These pages change, so look them up again before your own round. Then run a probe: a few lines that print the version and test for the newer functions you might use. Paste it into the platform’s editor in a practice test. Here is one for Python:

# Run this in a platform's editor (a practice test is a good place) before the round:
# which Python is it, and does it have the newer functions you might reach for?
import heapq
import itertools
import math
import platform

print("Python", platform.python_version())
for name, module, attribute, added in [
    ("math.lcm", math, "lcm", "3.9"),
    ("itertools.pairwise", itertools, "pairwise", "3.10"),
    ("itertools.batched", itertools, "batched", "3.12"),
    ("heapq.heappush_max", heapq, "heappush_max", "3.14"),
]:
    found = "yes" if hasattr(module, attribute) else "missing"
    print(f"{name:20} new in {added:5} {found}")

Python 3.14.8
math.lcm             new in 3.9   yes
itertools.pairwise   new in 3.10  yes
itertools.batched    new in 3.12  yes
heapq.heappush_max   new in 3.14  yes

Python 3.14.2
math.lcm             new in 3.9   yes
itertools.pairwise   new in 3.10  yes
itertools.batched    new in 3.12  yes
heapq.heappush_max   new in 3.14  yes

On the CPython 3.10 that CoderPad’s page names, the last two lines would say missing: according to the Python documentation, itertools.batched arrived in Python 3.12 and the heapq max-heap functions such as heappush_max in Python 3.14. A solution that imports them fails before it runs a single test, however good the algorithm is.

JavaScript has the same trap, with bigger gaps:

// The same check for JavaScript: which engine is this, and which newer built-ins does it have?
const isNode = typeof process === 'object';
console.log(isNode ? `Node.js ${process.version}` : 'Not Node.js: there is no process object');
const builtIns = [
  ['Array.prototype.findLast', Array.prototype.findLast],
  ['Array.prototype.toSorted', Array.prototype.toSorted],
  ['Object.groupBy', Object.groupBy],
  ['Set.prototype.union', Set.prototype.union],
];
for (const [name, value] of builtIns) {
  console.log(`${name.padEnd(25)} ${typeof value === 'function' ? 'yes' : 'missing'}`);
}

Node.js v24.21.0
Array.prototype.findLast  yes
Array.prototype.toSorted  yes
Object.groupBy            yes
Set.prototype.union       yes

Not Node.js: there is no process object
Array.prototype.findLast  yes
Array.prototype.toSorted  yes
Object.groupBy            yes
Set.prototype.union       yes

MDN’s compatibility data gives the first Node.js release with each of these built-ins:

• Array.prototype.findLast: from Node.js 18.0.0, so it is missing on v16 and present on v20.15.1.
• Array.prototype.toSorted: from Node.js 20.0.0, so again missing on v16 and present on v20.15.1.
• Object.groupBy: from Node.js 21.0.0, so it is missing on both.
• Set.prototype.union: from Node.js 22.0.0, so it is missing on both.

So toSorted() works on HackerRank’s Node.js but throws a TypeError on CoderPad’s, and Object.groupBy works on neither. When a platform is older than your habits, write the older form: copy and sort ([...a].sort(...)), loop to group, and build set operations from has and add.

Check three more things in the same practice test:

• The shape of the program. HackerRank usually gives you a function to fill in, with a stub that reads the input for you; other platforms want a whole program that reads standard input, and CoderPad’s Java page asks for a public class named Solution with a main method. Practise both shapes.
• The time limit for your language. HackerRank allows Python five times as long as C++, but no limit makes an O(n²) solution pass a test that needs O(n log n). The next lessons turn input limits into a target complexity.
• What you can see. Find out whether the platform shows the output of failed sample tests, and whether you can add your own test input.

Key takeaways

• A live interview scores your reasoning and testing as well as your code; an OA scores only the hidden tests you pass; an AI-assisted round adds how well you direct and check an assistant.
• Rubrics usually group feedback into communication, problem solving, technical competency and testing. Saying your plan and finding your own bugs both count.
• In an OA each hidden test is all or nothing, so a correct slow solution can outscore a fast one with a missed edge case. Submit something correct first.
• Platforms run older language versions than you might expect. Read their environment page and run a probe before the round.