The OA Landscape: Platforms, Formats, Proctoring and Rules

Off-campus candidates often imagine that the interview is the hard part. For many, the search stops earlier: at a timed online assessment taken alone, at home, with a clock running and an unfamiliar editor. An assessment does not care how good your project is. It measures whether you can solve unseen problems under time pressure in a particular format.

The good news is that assessments are the most predictable stage of hiring. The formats repeat, the platforms publish practice areas, and preparation shows up directly in your score. This article covers the landscape; the next three cover strategy, practice and company-specific preparation.

• The common formats of online assessments for freshers.
• The main platforms, and how their editors and scoring differ.
• What proctoring usually monitors.
• Why the integrity rules matter, and how to prepare within them.
• A set-up checklist for the day of the test.

Read the invitation email carefully: it often names the sections, the duration and the platform. If it does not, recent candidate reports usually do (article 26).

• Data analyst: SQL, spreadsheet tasks, statistics questions and sometimes a short case.
• QA: testing concepts, writing test cases for a described feature, sometimes automation code.
• Support: troubleshooting scenarios, Linux and networking questions, written communication.

Companies run assessments on specialised platforms. Common ones include HackerRank, HackerEarth, Codility, CodeSignal, Mercer Mettl, SHL (which includes AMCAT), iMocha and others, plus some companies' own systems. Which company uses which changes over time, so check your invitation rather than assuming.

What differs between platforms, and why it matters:

Assessment platforms offer employers integrity features, and employers choose which to switch on. HackerRank's own documentation, for example, describes copy-and-paste tracking and tab-switch tracking (recorded in the candidate's report), optional modes that enforce full-screen and block copy-paste or multiple monitors, optional webcam snapshots and image analysis, and plagiarism detection that compares submissions and looks at how code evolves. Other platforms have similar features.

Commonly monitored, depending on settings:

• Switching away from the test tab or window.
• Pasting text into the editor.
• Webcam images, sometimes checked automatically for other people or devices.
• Whether your code closely matches other submissions or known sources, or looks generated.
• Full-screen exits and multiple monitors.

You will not know exactly which features a particular test uses. The instructions usually tell you what is required (camera, full screen) and what is not allowed.

Assessment instructions typically forbid outside help: other people, searching the web, AI assistants and sometimes notes. Some tests explicitly allow documentation or a language reference; a few allow anything. The instructions for your test are the rule.

Beyond the risk, there is a practical point: the assessment is a filter for the job itself. Passing it with help puts you into interviews and work you are not ready for, which is a worse outcome than failing honestly and practising.

Everything that genuinely helps is allowed before the test:

• Learn patterns until you recognise them (article 25).
• Memorise templates for the patterns you use most, so you can write them quickly without notes.
• Practise under timed conditions on the actual platform.
• Learn your language's standard library well enough to need no reference.
• Use rough paper if the instructions allow it; many tests do, and thinking on paper is not monitored the way the screen is. If the instructions say no paper, follow them.

If you have a disability or a condition that affects timed tests, ask the employer for an accommodation before the test. Many have a process for it.

The day before:

• Read the full instructions: duration, sections, allowed resources, camera and screen requirements, deadline.
• Run the platform's system or compatibility check if it offers one.
• Use a laptop or computer that is charged or plugged in, with the browser updated and unnecessary extensions disabled (some extensions interfere with proctoring).
• Have a stable internet connection, and a backup (a phone hotspot) in case it drops.
• Check the webcam and microphone if required.
• Choose a quiet room with nobody else in camera view, and tell your family you cannot be disturbed.
• Keep your identity document ready if the test asks for it.
• Pick your language and check its version on the platform.
• Close messaging apps and turn off notifications.

During the test:

• Stay in the test window. If the connection drops, note the time, reconnect quickly and, if the platform allows, contact its support.
• Read every question's input format and constraints before coding (article 24).
• Keep an eye on the timer for each section; some sections lock when their time ends.

If something goes wrong that is not your fault (a platform crash, a power cut), email the recruiter or the address in the invitation promptly with the details and the time. Some employers allow a retake.

For services companies and many large-intake drives, aptitude carries heavy weight. Topics typically include percentages, ratios, time and work, time and distance, profit and loss, probability, permutations, number series, data interpretation, logical puzzles, coding-decoding, and reading comprehension and grammar. Article 26 covers how to prepare for these alongside coding. The key point here is that aptitude is a timed skill: accuracy at speed comes only from regular timed practice.

Karthik receives an assessment link: 90 minutes, two coding problems and 20 multiple-choice questions, on a platform he has never used, deadline in five days.

1. He reads the instructions: camera on, full screen, no external resources; rough paper allowed.
2. He spends an hour in the platform's practice area: reading input, using custom input, checking the Java version.
3. He finds that the editor's autocomplete is limited, so he practises writing his usual input-reading code from memory.
4. On the day, he runs the system check, plugs in his laptop, closes everything else and puts a notebook and pen beside him.
5. During the test, his connection drops for a minute. He reconnects; the timer kept running, but his code was saved.

He solves one problem fully and passes most test cases of the second (article 24 explains why that matters). Nothing technical cost him marks.

• Practising only on one site and meeting an unfamiliar editor in the real test.
• Ignoring input format, and losing minutes to reading input incorrectly.
• Not reading the rules, and doing something that gets flagged.
• Using AI or notes during the test because "everyone does it".
• Starting late before a deadline, then hitting technical problems with no time left.

• Next: OA Strategy: Constraints, Time, Brute Force and Partial Scoring turns preparation into points.
• For a full placement preparation overview, including aptitude, see Indian Fresher Placement and Coding Interview Preparation.
• For data structures and algorithms from the ground up, see DSA From Zero to Job-Ready: A Practical Guide with Java.