Early careers and graduate hiring fundamentals

Mostly whether you are worth an interviewer's hour. Early-career hiring has far more applicants than interview slots, so the online assessment is a filter run before any human reads your application closely, and it is usually scored automatically against test cases or answer keys. That shapes what it rewards: correct output under a time limit, not elegant code or a clever explanation nobody will read. It also means partial credit matters, because a solution passing most of the hidden tests often scores far better than an ambitious one that does not compile. The cost of treating it as a real interview is spending twenty minutes on readability for an audience that is a grader. The cost of treating it as only a filter is forgetting that some employers do show your code to the interviewer later, so write it as if someone might read it, but finish first.

Decide the plan before the timer starts, because the decision about when to stop polishing is the one that is impossible to make well under pressure.

70-minute assessment, 4 problems, unknown difficulty order

Minutes   Block   Task
0-5       5       Read all four statements and the input limits.
                  Rank them easiest to hardest by your own judgement.
5-17      12      Easiest problem. Submit as soon as samples pass.
17-32     15      Second easiest. Submit a working version first.
32-52     20      Third. Brute force first if the optimal is unclear.
52-65     13      Hardest. Aim for partial credit on small inputs.
65-70     5       Buffer: resubmit improvements, check nothing is
                  left unsubmitted.
Total     70

Stop rule: when a block's time is up and the problem has a
submitted version, move on. Return only from the buffer.

The five minutes of reading look expensive and are the best-spent minutes in the plan. Assessments do not always present problems in order of difficulty, and a candidate who starts on problem one because it is first can lose half the time to the hardest question while an easy one sits unread at the bottom.

The blocks grow because the problems usually do, but the important rule is the submission one. A submitted brute force that passes the small hidden tests banks points that a half-written optimal solution does not, and most platforms score the last submission, so an early version costs nothing. Check the invitation for how scoring works on the platform you have been sent to; some score each test case, some only a full pass.

The detail candidates leave out is the buffer. Without it, the last five minutes are spent finishing problem four and a correct fix to problem two never gets resubmitted. The stop rule is what makes the plan survive contact with a problem that is harder than it looked: you are allowed to come back, but only after every other problem has a submitted answer.

You find it from the constraints, not from the samples, and the fastest way to prove it is to compare against a solution too slow to be wrong.

import random

def fast(xs):            # your submitted solution: max subarray sum
    best = cur = 0
    for x in xs:
        cur = max(0, cur + x)
        best = max(best, cur)
    return best

def brute(xs):           # obviously correct, too slow for big inputs
    return max(sum(xs[i:j]) for i in range(len(xs))
                            for j in range(i + 1, len(xs) + 1))

for _ in range(1000):
    xs = [random.randint(-5, 5) for _ in range(random.randint(1, 6))]
    if fast(xs) != brute(xs):
        print("mismatch", xs, fast(xs), brute(xs))
        break

Run this and it prints a mismatch almost at once, on an input where every number is negative: fast([-3, -1]) returns 0 because it starts best at zero, while the brute force correctly returns -1. The samples probably all contained a positive number, which is why they passed.

The constraint list is the other half of the method. Read the limits in the statement and write down an input at each boundary: the empty or single-element case, the maximum size (which exposes a quadratic loop as a timeout rather than a wrong answer), all values equal, duplicates, negatives and zero, and values near the limit whose sum overflows a 32-bit integer in Java or C++. Each one is a hidden test someone wrote on purpose.

Small random inputs matter more than big ones for finding the bug, because the mismatch they print is short enough to trace by hand. Big inputs find performance failures instead. Doing this on an assessment is entirely legitimate: you are testing your own code within the time you have, and it is the same habit an interviewer later wants to see you narrate.

Trace it in a table of variables, one row per loop iteration, instead of reading the code and forming an impression of what it does.

def f(xs):
    total = 0
    for i in range(1, len(xs)):
        if xs[i] > xs[i - 1]:
            total += xs[i] - xs[i - 1]
    return total

a = [3, 1, 4, 1, 5]
b = a
b.append(9)
print(f(a), len(a), 7 // 2, -7 // 2)

# Trace of f(a) where a is now [3, 1, 4, 1, 5, 9]
# i   xs[i-1]  xs[i]  rises?  total
# 1   3        1      no      0
# 2   1        4      yes     3
# 3   4        1      no      3
# 4   1        5      yes     7
# 5   5        9      yes     11
#
# Output: 11 6 3 -4

Three traps sit in four lines, which is typical of these questions. The first is that b = a copies the reference, not the list, so appending to b changes a too, and both the trace and len(a) must use six elements. A candidate who traces the original five gets 7 and 5 and has done the arithmetic perfectly.

The second is floor division. In Python // rounds towards negative infinity, so -7 // 2 is -4, not -3. Java, C and C++ truncate integer division towards zero, where the same expression gives -3. The question is often set precisely so that the language matters.

The third is the loop bound. range(1, len(xs)) starts at one and stops before the length, which is what makes xs[i - 1] safe. Off-by-one questions change exactly this line and ask whether the code now reads past the end or skips the first comparison. Writing the index column first, before any values, is what catches it.

The rules are set by the employer and the platform, so read the invitation and any practice test it links, because that is the authority and not general advice. Typically you are asked for photo identification, a quiet room with nobody else present, a single screen, the webcam and microphone on, and no materials beyond what is explicitly allowed. Looking away repeatedly, another voice, or a second device in view are the behaviours such systems tend to flag for a human to review. Set up to make the honest version look honest: clear the desk, close other applications and notifications, sit facing a light rather than with a window behind you, and keep any permitted scratch paper visible. If you lose your connection or something interrupts you, note the time and contact the support address in the invitation straight away rather than waiting for a result. The rules exist to make scores comparable; working within them is the whole of the advice.

Whether you understand the code before you change it, not whether you can coax the assistant into producing a patch. These sections describe themselves differently on each platform, so read the instructions for what is logged and assessed. The behaviours that generally separate candidates are the same ones a reviewer looks for in a pull request: reading the failing test and the code it exercises first, forming a hypothesis about the cause, asking the assistant narrow questions rather than pasting the whole task, checking its suggestion against the code instead of accepting it, running the tests to verify the fix, and explaining in a sentence what was wrong. A patch that passes because the assistant rewrote a test, or one you cannot explain, is the failure mode. Treat the assistant as a fast colleague whose work you are responsible for reviewing, which is how you will be expected to use one in the job.

Only once you know which section cost you, because retaking with the same preparation tends to produce the same score. Start with a diagnosis: did you run out of time, fail hidden tests, or misread problems? Each has a different remedy. Time trouble is fixed by practising under the real timer, not by learning more topics. Hidden-test failures are fixed by the edge-case habit. Misreading is fixed by spending the first minutes reading everything. Then check the rules in the invitation, because waiting periods, whether the old score is replaced or kept, and whether a result is shared across employers who use the same platform all vary and are not something to assume. The cost of retaking early is that a second weak score may be the one an employer sees. The cost of never retaking is giving up a role over a filter you could have passed with a month of targeted practice.