OA Strategy: Constraints, Time, Brute Force and Partial Scoring

Two students with the same knowledge take the same 90-minute assessment with two problems. The first opens problem one, spends 70 minutes trying to find the optimal solution, gets close, and submits nothing that compiles. Problem two goes unread. Score: zero.

The second reads both problems, starts with the one she recognises, submits a working solution in 25 minutes, then writes a slow but correct solution to the harder one, which passes 6 of 10 test cases, and spends the last 15 minutes on edge cases. Score: well over half. Same knowledge, very different results. The difference is strategy, and strategy can be learned in a week.

• A time plan for a multi-problem assessment.
• How to read a problem so you understand it before coding.
• How constraints tell you the complexity, and so the approach, you need.
• Why brute force first, and how partial scoring rewards it.
• An edge-case checklist, and stress testing for practice.

For a typical assessment with two or three problems in 60 to 120 minutes:

1. Read everything first (about 5 minutes). Skim every problem: what it asks and its constraints. Problems are not always in order of difficulty.
2. Start with your most confident problem. A quick, complete solution early lowers pressure for the rest.
3. Set a time cap per problem. For two problems in 90 minutes, about 35 to 40 minutes each. When the cap arrives, submit your best working version and move on. You can return.
4. Keep the last 10 minutes for testing edge cases and re-submitting, not for starting new code.
5. Multiple-choice sections have their own timers on some platforms. Do not leave easy marks unanswered: if there is no negative marking, answer everything; if there is, skip only what you cannot narrow down.

Most wrong answers start with misreading. A three-step read:

1. Read the examples first, then the statement. Work out by hand how each example input becomes its output. It often makes the statement clear.
2. Name the output type. A count, a maximum or minimum, yes or no, an arrangement, a path? The type narrows the approach.
3. Read the constraints last, carefully. They decide the complexity you need (next section), and they reveal edge cases: can numbers be negative? can the array be empty? can the answer exceed the range of a 32-bit integer?

A rough rule of thumb: a typical judge can do somewhere around 10^7 to 10^8 simple operations per second in a fast language such as C++ or Java, and fewer in Python. So the size limit on the input tells you how fast your algorithm must be.

These boundaries are approximate; the time limit, the language and the constant factor matter. But the habit is powerful: read the constraints before choosing an approach. If n is up to 2 × 10^5, an O(n^2) solution will time out on the large tests, so do not spend 30 minutes perfecting it unless you mean it as your brute force.

Before trying the optimal solution, write the simplest correct one, even if it is slow. Three reasons:

1. Partial marks. Many platforms score each test case separately. A slow but correct solution often passes the small tests: perhaps 30 to 60 per cent of the marks, depending on how the tests are designed.
2. Understanding. Writing the brute force forces you to handle the input, output and edge cases correctly, which the optimal solution needs too.
3. Checking. You can compare your optimal solution with it on small inputs.

Then, if time allows and you know the better approach, optimise. If you do not know it, use the remaining time on edge cases and on other problems.

When a platform awards marks per passed test case, think in tiers:

Handling special cases explicitly, such as "if the array has one element, the answer is 0", is legitimate edge-case handling. It is different from printing memorised answers to particular test inputs, which is pointless and may be flagged.

Some platforms instead require all tests to pass, or weight hidden performance tests heavily (Codility, for example, separates correctness from performance in its scoring). Read the instructions; the brute-force-first habit still helps, because it gives you something correct to build on.

Before submitting, test with the platform's custom input:

• The examples from the problem.
• The smallest valid input (n = 0 or 1, an empty string, a single character).
• The largest input you can construct, to check time.
• All elements equal.
• Already sorted, and reverse sorted.
• Negative numbers and zero, if allowed.
• A case where the answer is "none" or 0.
• Values near the limit, to check overflow.

This takes a few minutes and catches a large share of hidden-test failures.

When you practise (not during a proctored test unless it is fully yours to use), there is a powerful habit: write a slow, obviously correct solution and a fast one, generate many small random inputs, and compare. The first mismatch shows you a failing input. Here is the technique for a simple problem: the largest sum of any k consecutive numbers.

# File: stress_test.py# Practice technique: check a fast solution against a slow, obviously correct one# on many small random inputs. Problem: the largest sum of any k consecutive numbers.import randomdef brute(nums, k):    """O(n*k): try every window. Slow but easy to trust."""    return max(sum(nums[i:i + k]) for i in range(len(nums) - k + 1))def fast_buggy(nums, k):    """O(n) sliding window with a bug: best starts at 0."""    window = sum(nums[:k])    best = 0    for i in range(k, len(nums)):        window += nums[i] - nums[i - k]        best = max(best, window)    return bestdef fast(nums, k):    """O(n) sliding window, fixed: best starts at the first window."""    window = sum(nums[:k])    best = window    for i in range(k, len(nums)):        window += nums[i] - nums[i - k]        best = max(best, window)    return bestdef stress(candidate, trials=500):    random.seed(7)    for _ in range(trials):        n = random.randint(1, 8)        k = random.randint(1, n)        nums = [random.randint(-10, 10) for _ in range(n)]        expected, got = brute(nums, k), candidate(nums, k)        if expected != got:            return f"mismatch for nums={nums}, k={k}: expected {expected}, got {got}"    return f"all {trials} random tests passed"print("buggy:", stress(fast_buggy))print("fixed:", stress(fast))

buggy: mismatch for nums=[2, 10, -9, -8, 7, -7], k=2: expected 12, got 1fixed: all 500 random tests passed

The buggy version passes many simple tests, but the stress test finds an input where it fails: the best window is the very first one (2 + 10 = 12), and best started at 0, so the first window was never counted. (Starting at 0 would also be wrong whenever every window sum is negative.) Small random inputs are used on purpose: when a mismatch appears, it is small enough to trace by hand.

The fixed seed makes the run repeatable, so the output above is the same every time.

After an assessment, write down the problems from memory as well as you can (many candidates do this to learn; do not share them where the employer's terms forbid it). Then, in practice:

I took a coding assessment. Here is a problem as I remember it, my approach,and how far I got. Do not give me the full solution.1. Was my approach correct? If not, which pattern fits, and why do the   constraints point to it?2. Which edge cases probably failed in the hidden tests?3. Give me one hint toward the optimal approach, then stop.[problem as you remember it, constraints, your code]

Then solve it yourself. Article 25 builds this into a full practice system.

• Opening problem one and never reading problem two.
• Choosing an approach before reading the constraints.
• Chasing the optimal solution with nothing submitted.
• Forgetting overflow with large values.
• Submitting without testing edge cases.
• Spending the last minutes starting a new approach instead of testing.

• Next: Pattern-First DSA Practice With AI as a Coach, Not a Crutch builds the problem-solving behind the strategy.
• For a step-by-step problem-solving method, see Problem Solving Fundamentals: From a Question to an Algorithm.
• For complexity in depth, see Time and Space Complexity Without the Confusion.