The Timed Online Assessment Run, From Invite Link to Confirmed Submission

A timed online assessment is a single-sitting screen you run against a clock, often with a webcam and a locked-down browser watching. This guide is for candidates who have an invite link in hand and need to sit one start to finish. It gives you a run-the-sitting procedure keyed to what the clock and the proctor actually enforce: the window, the integrity mode, per-question budgets, disconnect recovery, and the explicit submit that registers your attempt.

This is not a study plan and not a guide to the untimed take-home. Those are different jobs with different mechanics. The take-home forgives a slow environment and a late submit; the timed screen does not. Here the mistakes that cost you are logistical, not algorithmic, and every one of them is avoidable if you know the mechanism before you click start.

Why the timed screen is run at volume, and what that means for you

The timed proctored screen exists because the candidate pool is enormous and front-loaded at entry level, so companies cannot review every applicant live. In Refolk's index of professional profiles there are 349,782 entry-level software engineers in the United States and 559,807 in India, roughly 1.60 times the US figure. Against pools that size, the screen is an automated pre-interview filter, not a conversation.

That framing matters for how you sit it. The system is enforcing rules mechanically, not judging your intent. A tab flag, a paste event, a webcam anomaly, a broken draft at the buzzer - each is a data point in a report, applied at scale. Your job is to give the machine nothing to flag and to make sure your best work is the thing that gets scored.

The screen is also disproportionately an early-career gate. In Refolk's index, US entry-level engineers outnumber senior engineers 1.91 to 1, which matches the timed screen's position as a filter that sits before any human interview. The higher you are in seniority, the more likely the process front-loads a conversation instead. If you are early-career, expect the clock and the proctor, and prepare for both.

What the invite specifies, and what to confirm before the clock

The invitation page is authoritative, and reading it fully is the single highest-leverage thing you do before test day. It tells you the scheduled window, the duration, the number of questions, the proctoring mode, and the rules. Do not assume a default from a test you sat elsewhere, because companies configure their own.

You can take the test only during the time window in the invitation email. If no time is specified, the hiring company has not set a deadline, but take it as soon as possible anyway. Start outside that window and you get a hard lockout: on HackerRank the message "Test is No Longer Available" appears when the link has expired, is outside the scheduled window, or the test was deleted.

Confirm these five things before you commit to a start time:

• Start and expiry date-time, so you know your latest safe start.
• Duration, so you can build a per-question budget.
• Question count, which drives that same budget.
• Proctoring mode, which tells you whether a webcam or desktop app is required.
• Required browser or app, so you install nothing at the buzzer.

There is one more pre-start gate on HackerRank Proctor Mode: before you begin, you review and acknowledge a list of prohibited actions, such as switching tabs or using external tools, and you must give consent to proceed. Read that list. It is the enforcement contract for the session you are about to sit.

The integrity modes, and what each one flags

Integrity mode, not platform, sets the rules. Employers toggle features per test, so two candidates at one company can face different enforcement. On HackerRank, copy-paste tracking is on by default while tab proctoring is off by default, which means you cannot assume any single behavior from the platform name alone. Read the acknowledged rules list and treat it as binding.

HackerRank runs a tiered model, where each tier inherits everything below it and adds more.

Secure Mode runs tests in a controlled browser, enforces full-screen, blocks copy and paste, prevents multiple monitors, and alerts on tab switch. Proctor Mode adds AI-powered screenshot analysis, plagiarism detection, and webcam anomaly detection; it captures screenshots every 15 seconds and can rise to every five seconds around a suspected violation. Desktop App Mode adds operating-system-level lockdown and requires you to install the native HackerRank Desktop App. CodeSignal layers on identity checks that can include a face image and photo ID, and it explicitly bans AI use, including for syntax searches.

The table below is the practical version: what each tier adds, and what candidate behavior starts to flag under it.

Two numbers are worth committing to memory. HackerRank plagiarism flagging starts at a 75% code-similarity match, so heavily reused boilerplate can trip it. And Tab Proctoring records both how often and for how long you leave the window, surfacing in the candidate Summary Report and the CSV report. A flag here is a review signal, not an automatic rejection, but it puts a human on your attempt, which is exactly what you want to avoid.

The pre-check that keeps the test from refusing to start

The environment check is a gate, not a formality. HackerRank does not begin the test until all requirements are met: network stability, a supported operating system, and a supported browser. If a requirement is not met - a blocked webcam, multiple monitors detected, an unsupported browser - the test may not start at all, or it may start flagged for integrity concerns.

Run this pre-check before test day, and again minutes before you start:

• Use the latest Google Chrome, Edge, Safari, or Firefox. An outdated or unsupported browser can block the start.
• Physically disconnect any second monitor. Detection can block the start or flag you even when the second screen is idle.
• Grant the in-browser camera and microphone prompt. A webcam that works elsewhere can still error inside the proctored app; if it does, restart the machine and retry on latest Chrome or Firefox.
• Confirm a stable network. HackerRank Desktop App Mode lists a 5 Mbps per-candidate minimum and recommends 10 Mbps; the Windows install needs no admin access.
• If a desktop app is required, install it before test day and save your open work before the app closes anything.

Time-zone or clock drift on your machine is not documented as a lockout trigger, so I will not tell you it is one. What is enforced is the scheduled window from the invitation, measured on the platform's clock. If you are unsure how close you are to expiry, treat the earlier estimate as true and start with margin.

Building the resume and cover letter that got you this invite is its own job, and one where Refolk writes from your own history and tailors to each posting so you spend your energy on the sitting, not the paperwork.

How scoring and submission actually work

Your score comes from hidden test cases and an explicit submit, not from how the code reads. On Codility, every task is scored by test cases: each task has at least six, often more, and your task score is the percentage of assessed cases your solution passes. By default all tasks carry equal weight, so a two-task test caps each task at 50%; weighted scoring is optional and, once a session exists, cannot be disabled.

This math has a clear consequence. A finished-but-slow solution that passes most cases can outscore an elegant half-finished one that passes none, because the half-finished attempt banks zero. Correctness banked early beats polish attempted late.

Correctness banked early beats polish attempted late, because the elegant half-finished solution scores zero.

Submission is explicit, and the two major platforms differ in what "time ran out" means. On CodeSignal you must submit via the green button in the IDE to receive a score; you can answer questions in any order and switch between them freely, and the menu bar has a History tab where you can restore a previous solution. On Codility, only a compilable editor state is graded, so a broken draft when the clock hits zero may score nothing.

Note the History behavior, because it doubles as your disconnect insurance. On CodeSignal a refresh may delete your current code, but code you previously executed can be recovered from the History tab. Running your code is therefore a save action, not just a test.

The per-question budget, derived not published

No platform publishes a canonical per-question time budget, so treat any single number you see elsewhere with suspicion. What you can do is derive a budget from the total the invitation page states, then adjust for difficulty. The variation across formats is nearly 3x, which is exactly why importing a fixed rule from another test misfires.

The counts and totals come from CodeSignal's General Coding Assessment structure documentation and from published Codility examples; the minutes-per-question figures are computed by division. Use them as a starting split, then rebalance during your scan: give the two easiest questions less than their share so the hard one gets a little more, and keep a two-to-five-minute buffer for the final submit.

There is a genuine disagreement worth naming. Some prep guides advise strict question order, starting at question one. CodeSignal's own documentation and most practitioner sources favor scanning all questions first and starting with the clearest, not necessarily the first. I side with the scanners: on a screen where each task banks independently, opening with the question you can definitely finish protects your floor.

The run-the-sitting procedure

This is the procedure end to end. Each step names who does it, roughly how long it takes, and what done looks like. Run it in order.

One expansion on the setup step, because it is where nervous candidates burn time they did not need to spend. On CodeSignal the setup clock does not begin until setup is complete, so that stage is free. Use it to fix camera, permission, identity, or browser problems before the countdown ever starts, rather than rushing into the assessment with an unresolved warning.

How this goes wrong, and how to catch each one

Most failed sittings fail on logistics, not on the algorithm. These are the failure modes to guard against, each with the check that catches it.

• Blind time-out submit. Believing "time out means submitted and scored" everywhere. On CodeSignal running out submits the attempt as-left, but on Codility only a compilable editor state is graded. Check: leave working, submitted code before the last minute, not a broken draft.
• Refresh wipes current code. A reconnect refresh can delete unsaved editor content, and assuming autosave is false comfort. Check: run or execute your code periodically so History can restore it.
• Accidental tab flag. A two-second alt-tab logs the same as a long absence in the raw event, so a harmless glance can read as cheating. Check: keep everything you need inside the window, and remember a flag is a review signal, not an automatic rejection.
• Wrong invite link. Two links for one role can carry different expiry dates, and starting the shorter-window one late locks you out. Check: confirm with the recruiter which link they intend.
• Second monitor still plugged in. Multiple-monitor detection can block the start or flag you even if the second screen is idle. Check: physically disconnect before the system check.
• Webcam works but errors in-app. The camera functions elsewhere yet the proctor still errors. Check: restart the machine, use latest Chrome or Firefox, and grant the in-browser prompt before starting.
• Cooldown lockout on retake. Assuming you can immediately redo a botched CodeSignal GCA. The rolling-window cooldown blocks it until an old attempt expires. Check: read the cooldown rule before requesting a redo.

The disconnect case deserves a rehearsed response, because panic is the real cost. The clock does not stop for a disconnect on CodeSignal, so every second spent flailing is a second gone.

The pre-start and post-submit checklist

Run this immediately before you click start, and again in the last five minutes before the clock expires. It is the difference between a scored attempt and a wasted invite.

Subject: Connection issue during timed assessment - [Your Name], [Role]

I lost connection during my timed assessment at approximately [time, with time zone].
I refreshed to reconnect and restarted my network per the documented steps; the countdown did not pause.
Assessment: [platform and test name]. Invite link: [paste link].
Current status: [reconnected / still disconnected]. Code recovered from History: [yes / no].
Please advise on how my attempt is being handled. I am copying my recruiting contact so both sides have the same timeline.

Keeping this current and confirming your attempt landed

The mechanics above are the durable parts: the window is enforced, the integrity mode is set per test, scoring runs on hidden cases, and submission is explicit. What changes is the specific configuration on any given invite, which is why the invitation page is your source of truth every single time. Re-read it for each new screen rather than reusing last month's assumptions.

Confirming your attempt registered is the last thing you owe yourself. A submission confirmation on screen is the primary signal. If your process gave you a recruiter contact, a short note that your attempt is submitted closes the loop and creates a record. And if anything went wrong mid-sitting, the escalation email above, sent with timestamps, is what protects you when the report is reviewed.

If you want a reality check before your own sitting, find people who have recently taken the same assessment and ask what the invite specified and how the proctor behaved. The configuration you face is set by the employer, and the people who just went through it are the closest thing to documentation of the version you are about to see.