An online coding assessment often stands between your application and the first human interview. You must solve unfamiliar algorithmic problems inside a restrictive browser window while a countdown ticks and a proctoring system records your screen. Passing this round requires more than data structures knowledge; it requires a strategy for securing partial credit and managing time across multiple questions.
The structure of a proctored assessment
A proctored coding assessment forces you to write executable logic outside your normal development environment. You receive a link to a browser-based text editor presenting one or more algorithmic problems alongside a strict countdown timer. The clock starts the moment you begin and does not pause if you lose your internet connection or step away.
This environment is intentionally stripped down. You usually cannot use your preferred local setup, meaning you lose access to rich autocompletion, integrated debuggers, and familiar keyboard shortcuts. The browser editor may offer basic syntax highlighting and rudimentary indentation, but it will not automatically import libraries or flag variable name typos before execution.
You are expected to read a problem description, understand the input and output constraints, and write a function that returns the exact required format. The interface typically provides a "Run" button to execute your code against a few visible sample test cases. However, passing these visible cases only proves your code compiles and handles basic inputs correctly. The true evaluation happens when you submit your solution and the platform tests it against a hidden suite of inputs.
Because you cannot rely on an integrated debugger to step through your logic line by line, you must build the habit of mentally tracing your variables. You have to catch your own infinite loops, out-of-bounds errors, and type mismatches by reading the code, rather than waiting for an error trace to point out the exact line.
How automated grading allocates credit
A common misconception is that coding assessments are graded on a pass-or-fail basis for each problem. In reality, scoring is rarely all-or-nothing. The automated grader evaluates your submitted code by running it against dozens of hidden test cases, allocating points for every test your code passes within a specific time limit.
These hidden test cases are divided into three broad categories. The first category tests basic correctness, verifying that your logic solves the core problem for standard inputs. The second category targets edge cases. The system will pass empty arrays, negative integers, null values, or inputs of length one to see if your code crashes or returns an incorrect default value. Handling these edge cases correctly secures a significant fraction of the available points.
The final category evaluates runtime complexity. The grader feeds your function massive inputs, such as arrays with hundreds of thousands of elements, and enforces a strict execution time limit. If your logic is correct but inefficient, the system will terminate the execution and throw a time-limit error for those specific massive inputs.
Crucially, a slow but accurate solution still earns partial points for the correctness and edge-case tests it managed to pass. Securing three-quarters of the points for a problem because you wrote a reliable, well-structured brute-force solution is vastly superior to earning zero points because an overly complex, unfinished solution failed to compile.
What proctoring software monitors
Proctoring software exists to verify that the person taking the test is the candidate who applied, and that they wrote the code without unauthorised assistance. The software typically requires screen recording, webcam monitoring, and sometimes a strict browser lockdown that prevents you from opening other applications. It is normal to feel anxious about being recorded, but understanding what the software actually flags can help you focus on the code.
The system is primarily looking for specific digital events, not normal human behaviour. It flags focus-loss events, which occur when you click outside the assessment window or switch to another browser tab. It flags large, sudden clipboard paste events, particularly if the pasted text contains formatted code from an external source. It also monitors the webcam feed for the presence of a second person in the frame, or for the candidate disappearing entirely from the camera view.
The software does not fail you for normal physical movements while thinking. Looking away from the screen, staring at the ceiling, resting your chin on your hand, or stretching slightly will not trigger an automatic rejection. If you are accustomed to muttering logic to yourself as you type, do so quietly, as continuous loud speech might trigger an audio flag for review.
When a proctoring system flags an event, it rarely issues an immediate automatic failure. Instead, it generates a timestamped flag for a human reviewer to check later. If you accidentally trigger a keyboard shortcut that opens another window, immediately close it and return to the assessment. A human reviewer will see a two-second distraction, not an attempt to cheat.
Time management across multiple problems
When an assessment includes multiple problems, the timer applies to the entire session, not individual questions. You might have ninety minutes to solve three problems of varying difficulty. A common mistake is to attempt the problems in order, spending an hour trying to perfect the first difficult problem and leaving no time to even read the final two.
Your first action upon starting the timer should be reading all the problems to triage their difficulty before writing any code. Classify each problem as easy, medium, or hard based on your immediate recognition of the required algorithms. Plan to tackle the easiest problems first to secure guaranteed points quickly. This builds your confidence and ensures you do not miss out on simple marks because you ran out of time.
There is a massive strategic advantage to writing brute-force solutions for partial credit on all problems rather than spending all the time perfecting just one. If you have three questions, writing a simple, functional solution for each might earn you a large proportion of the total marks. Spending your entire time allocation perfecting an optimal solution for the first question, while leaving the other two blank, yields a much lower final score.
Once you have a working solution for every problem, you can use the remaining time to revisit your code and optimise the most promising answers. If you run out of time while trying to refactor a brute-force solution into an optimal one, you at least have the initial points secured. Always keep a copy of your working brute-force code commented out or saved in a local scratchpad so you can revert to it if your optimisation attempt breaks the logic.
A worked example: Securing partial credit
To understand how automated grading applies partial credit based on time complexity, consider a classic problem: finding whether any two numbers in an array add up to a specific target.
If you are under time pressure and cannot immediately recall the optimal approach, you should quickly write a brute-force solution. This involves comparing every single number against every other number using a nested loop.
def has_pair_with_sum_basic(numbers, target):
# A brute-force approach comparing all possible pairs
for i in range(len(numbers)):
for j in range(i + 1, len(numbers)):
if numbers[i] + numbers[j] == target:
return True
return False
This code works perfectly for small inputs. It will pass the visible test cases and the hidden edge cases, earning you partial credit for correctness. However, its time complexity is O(N^2). If the automated grader provides an array of fifty thousand elements, this logic requires hundreds of millions of operations. The test will time out, and you will lose the performance points.
Instead of staring at a blank screen hoping the optimal approach comes to you, submitting the code above secures a baseline score. Once those points are banked, you can work on the optimised version. An optimal approach uses a hash set to track numbers you have already seen, reducing the time complexity to O(N) because it only requires a single pass through the array.
def has_pair_with_sum_optimal(numbers, target):
# An optimised approach using a set for O(1) lookups
seen_numbers = set()
for number in numbers:
difference = target - number
# If the difference is in the set, a pair is found
if difference in seen_numbers:
return True
seen_numbers.add(number)
return False
This optimised hash set solution earns full credit on both correctness and complexity. It processes massive arrays in a fraction of a second. However, securing this full score is only valuable if you actually complete the code.
If you attempt the optimal solution first but get confused by the data structure syntax and fail to produce executable code before the timer ends, you score zero. Submitting the brute-force attempt is a far better fallback than submitting an incomplete optimal attempt. Always secure the correctness points first, then chase the complexity points if time allows.
A worked example: Catching edge cases without a debugger
Securing correctness points requires your code to survive the automated edge-case testing. Without an integrated debugger, you must manually anticipate what happens when the input breaks typical assumptions. Consider a problem asking you to find the maximum possible profit from buying and selling an asset, given an array of historical prices.
A candidate might write a solution that tracks the lowest price seen so far and calculates the potential profit against every subsequent price.
def calculate_maximum_profit(prices):
max_profit = 0
min_price = prices[0]
for price in prices:
current_profit = price - min_price
if current_profit > max_profit:
max_profit = current_profit
if price < min_price:
min_price = price
return max_profit
If the candidate tests this logic by pressing the "Run" button against a standard array like [7, 1, 5, 3, 6, 4], it returns the correct answer and looks perfectly functional. But submitting this immediately leaves points on the table.
The automated grader will throw an empty array [] at this function. Because the logic blindly accesses prices[0] on the second line, it will trigger an IndexError, crashing the execution. The grader might also pass an array of length one, where buying and selling is impossible. To secure the edge-case points, you must manually trace the logic with extreme inputs and add explicit guardrails.
def calculate_maximum_profit_safe(prices):
# Guardrail against empty arrays and arrays of length 1
if not prices or len(prices) < 2:
return 0
max_profit = 0
min_price = prices[0]
for price in prices:
current_profit = price - min_price
if current_profit > max_profit:
max_profit = current_profit
if price < min_price:
min_price = price
return max_profit
Adding those two lines at the top of the function ensures the logic gracefully handles empty and invalid inputs. You must build the habit of defensively checking array lengths, null variables, and negative boundaries before letting your main algorithmic logic take over. Catching these edge cases manually is the only way to maximise your correctness score in a restricted browser environment.
How to practise for an assessment
Standard coding practice often builds bad habits for proctored assessments. When you practise in a full development environment, you rely the tools to catch syntax errors as you type, and you use the debugger to inspect variables when your logic fails. To prepare effectively, you must simulate the real environment by coding without a debugger or standard shortcuts.
Force yourself to practise in a plain text editor, or use platforms that restrict autocompletion. When you write a solution, do not run the code immediately to see if it works. Instead, manually trace your logic with a sample input on a piece of paper. Track the value of every variable as your loops execute. This mental execution is exactly what you will have to do during the real assessment when the hidden test cases fail and you have no debugger to tell you why.
You must also strictly time your practice sessions to build tolerance for the ticking clock. Give yourself forty-five minutes to solve two unseen problems. Do not pause the timer to look up syntax. If you forget how to initialise a specific data structure, you must find an alternative workaround using the tools you do remember, exactly as you would in a live test.
To simulate the exact constraints of this format, Vrenic offers proctored coding assessments on the Premium plan. You receive an AI-generated problem, and your code runs against test cases directly in your browser. It is graded on correctness, complexity, code quality and approach, giving you a clear picture of how your time management and partial-credit strategies hold up under pressure. Visit the features page to learn how the different grading dimensions work.
Once you pass the coding round, you will likely face an architecture discussion next. Read System Design Interviews: What They Actually Grade, and How to Practise the Round to understand how expectations shift when you leave the code editor behind.
Before your next coding assessment
Before you click the link to start your assessment, run through a final preparation checklist to ensure a smooth technical experience and a focused mindset.
- Clear your workspace of secondary devices. Turn your phone off and place it out of sight to avoid any suspicion from the webcam recording.
- Close all background applications on your machine. Shut down messaging apps, notification centres, and any software that might trigger a screen pop-up or a clipboard event during the test.
- Ensure your laptop is plugged into power and your internet connection is stable. A dropped connection often eats into your total allotted time while you attempt to reconnect.
- Commit to the core strategy: read all the problems before typing, secure partial points with brute-force solutions first, and only optimise when you have banked a baseline score across the board.