How to Pass the Software Engineering Online Assessment: A Step-by-Step Guide

Published June 1, 2026 · Finch Team

Updated October 9, 2026

If you're applying to software engineering roles at big companies, you'll hit an online assessment (OA) before you ever talk to a recruiter. Amazon, Google, Microsoft, Meta, Bloomberg, Citadel: they all screen at scale using them. The OA is your first real hurdle, and a lot of students treat it like a casual warm-up. That's a mistake.

This post covers what to expect, how to prep, and the specific things that trip people up in OAs that wouldn't trip them up in a more casual LeetCode session.

What an Online Assessment Actually Is

An OA is a timed coding test, usually administered through HackerRank, CodeSignal, or a company's own platform. You get 1-3 problems, typically 45-90 minutes total, and a pass/fail threshold gets applied automatically before any human reviews your submission.

Most OAs have 2 problems. The first is usually medium difficulty. The second is harder, often a medium-hard or hard that tests whether you can go beyond brute force. Some assessments add a third shorter problem or an MCQ section on CS fundamentals.

Companies vary significantly in format:

Amazon: 2 coding problems + a behavioral component called the Work Style Assessment. Time is usually 105 minutes total. Failing the behavioral section can disqualify you even if your code is correct.

Google: CodeSignal's GCA (General Coding Assessment), 4 problems in 70 minutes. Scored 300-850. A score of roughly 835 typically clears the automated bar.

Microsoft: 3 problems on Codility or a proprietary platform, typically at medium difficulty.

Bloomberg: HackerRank, 3 problems at low-to-medium difficulty with a tight time window.

Read the specific instructions for every OA you take. The format matters.

The Preparation Gap Most Students Have

Here's the thing: most students prep for OAs by doing LeetCode problems at their own pace, with no timer, able to look things up when they get stuck. That's useful but it's not actually training for the OA.

The OA is timed. You can't Google anything. If you blank on the syntax for sorting with a custom comparator, you lose 5 minutes at minimum. If you can't reconstruct a BFS from memory, you might not finish the problem at all.

The real prep gap is speed under pressure without reference material. You need to write your core data structure operations from memory, quickly and cleanly.

What to Practice (and in What Order)

Don't try to cover every topic. OAs are more predictable than on-site loops. The most common patterns, roughly by frequency:

Arrays and Hash Maps

Two-sum variants, frequency counting, sliding window, and prefix sums show up constantly. If you can't write a sliding window solution in under 10 minutes from scratch, practice until you can. These patterns appear in the majority of medium OA problems.

Trees and Graphs

BFS, DFS, level-order traversal, connected components, and shortest path (Dijkstra's or BFS on unweighted graphs). Know how to represent a graph from an edge list. Know how to detect cycles. Trees and graphs appear in roughly half of all medium OA problems.

Strings

Most string problems are array problems in disguise: find the longest substring, count character frequencies, detect anagrams. The key skill is recognizing that and applying the right pattern quickly.

Sorting and Greedy

Know your sort functions cold. Know when a greedy approach works: interval scheduling, minimum cost assignments, maximum non-overlapping intervals. Greedy problems are fast to solve if you recognize the pattern and frustrating if you don't.

Dynamic Programming (lighter coverage)

DP shows up on OAs but usually at a basic level: 1D DP like house robber, coin change, or longest increasing subsequence. Full 2D DP mastery isn't necessary for most OAs. Know the 1D patterns well.

The OA Environment Setup

This sounds obvious, but a surprising number of students mess it up.

Take it in a quiet place. If you're in a dorm common room with people walking through, you're giving yourself a disadvantage. The OA requires sustained focus. Treat it like a real exam.

Stable internet. OA platforms time out. Losing your connection mid-problem is genuinely catastrophic. Use a wired connection if you can. At minimum, make sure your WiFi is reliable before you start the timer.

One screen, no notes browser-side. Most OAs technically allow internet access, but looking things up mid-problem almost always costs more time than it saves. The only exception is checking a specific built-in method signature. Everything else should be in your head before you start.

Read the entire problem before writing any code. Constraints contain hints. If n <= 10^5, you need O(n log n) or better. If n <= 10^3, O(n^2) is probably fine. If the problem says "minimum cost" with repeated subproblems, that's a DP signal. These clues are free if you read for them.

How to Approach Each Problem

Here's a process that holds up under OA time pressure:

Step 1: Read the full problem and all examples (3-5 minutes). Don't start coding yet. Make sure you understand the input format, output format, and what edge cases are in the examples.

Step 2: Write the brute force in pseudocode (2-3 minutes). Even if you know you'll need something better, writing the brute force forces you to understand the problem structure. The optimized solution often falls out of the brute force naturally.

Step 3: Identify the bottleneck in your brute force. Is it a nested loop you can collapse with a hash map? A repeated subcomputation you can memoize? A search you can binary search instead?

Step 4: Write the optimized solution and trace through the examples (10-15 minutes). Don't submit before manually tracing through at least one example. A lot of bugs surface at this stage that would otherwise cost you 5-10 minutes of failed test runs.

Step 5: Handle edge cases explicitly. Empty input? Single-element array? Integer overflow for large n? Check the constraints. If n >= 1, you don't need to handle n = 0. If n can be up to 10^9, check for overflow.

Step 6: Submit with 5-10 minutes to spare if possible. Some OAs show partial results. Use leftover time to debug specific failing test cases.

The Behavioral Section (Amazon)

Amazon's OA includes a Work Style Assessment: a series of Likert-scale and forced-choice questions designed to evaluate alignment with Leadership Principles. Some candidates who ace the coding section fail to advance because of this section.

Don't rush through it. Don't pick the extreme option on every question. It reads as gaming the test. Answer honestly, and be aware that Amazon heavily weights ownership, customer focus, and bias for action.

Timed Practice Is the Only Practice That Counts

The week before an OA, shift your practice to timed mock tests. Set a 90-minute timer. Open two medium LeetCode problems. Code them with no reference material, submit, and see what happens.

This is uncomfortable the first time. That's the point. Finding out that you freeze when the timer is running (at home, in practice) is much better than finding that out in the real OA.

After each mock, review what specifically slowed you down. If you spent 8 minutes on a BFS template you should know cold, that's the thing to drill: not graphs in general, but that specific implementation. Fix the slow spots precisely.

Connecting Prep to Applications

Passing an OA gets you to a phone screen or on-site, not a job offer. It's one gate among several, which means running applications in parallel matters: passing one OA doesn't get you far if you only have two companies in the pipeline.

Keeping applications going while you prep is easier with Finch. Each week it picks the 3 internships or new-grad roles that fit your major best. On desktop Chrome, the Finch for Chrome extension fills the application form for you. That leaves more of your limited prep time for actual OA practice.