A reviewer opening your HackerRank candidate report sees far more than a score. They get your total against the time allotted, a per-question breakdown with the minutes you spent on each, your full source code in the language you chose, and a row for every hidden test case marked pass or fail with its runtime and memory. If proctoring was switched on, they also get a timestamped log of every time the test window lost focus, a count of paste events with the pasted lines quoted back, and up to two plagiarism flag categories. Almost none of that is visible to you while you take the test.
The order a reviewer clicks through it
The report is one page per candidate per test, shareable by link with hiring managers. Few reviewers read it top to bottom. The usual path is a triage pass, then a deep dive on whatever looked odd.
The header band
Name, email, test name, total score as points earned over points available, time taken against time allotted, submission timestamp, and completion status. Many configurations also show how the score sits against other candidates who took the same assessment.
The question scorecard
Every question in order with its type (coding, multiple choice, approximate solution, subjective), its score, and the time spent on it. Questions opened but never attempted are marked as such, which is its own signal.
The per-question deep dive
Expanding a coding question reveals the submitted source, the language, each submission attempt with its timestamp and score, compiler output for failed runs, and the full test-case grid including the hidden cases you never saw results for.
The activity and proctoring panel
Focus-loss events, copy-paste events, and, where enabled, webcam snapshots and full-screen exit records. Most reviewers open this only when something above it already looked strange.
Inside one coding question, field by field
Candidates underestimate this part. During the test, a failed hidden case tells you almost nothing. In the report, the reviewer sees the whole grid.
| Field | What it literally contains | What a reviewer reads into it |
|---|---|---|
| Test case rows | One row per case, sample and hidden, each marked Success, Wrong Answer, Terminated due to timeout, or Runtime Error, with points awarded, execution time and memory used | Whether you failed on logic or on complexity. Passing everything except the large cases is a Big-O story, not a correctness story, and that difference often decides reject versus follow-up |
| Submitted source | The final code exactly as it stood, plus the language you selected | Naming, structure, comments, dead code, leftover debug prints. Reviewers form an opinion here faster than from the score |
| Submission attempts | Each submission with a timestamp and the score it earned | The shape of your debugging. Three failed submissions then a pass looks like work. One submission at full marks looks like either fluency or a prepared answer |
| Compiler output | Build errors and stderr from failing runs | Whether a zero means the approach was wrong or a semicolon was missed under time pressure. Those are treated very differently |
| Time spent | Minutes attributed to that question | Read against the score. A perfect score in three minutes on a hard problem is the single most common trigger for opening the proctoring panel |
The activity log: pastes and focus loss
Two logs sit under the proctoring panel, and they behave differently from how most candidates imagine.
Paste events. When copy-paste tracking is enabled, the editor records each paste into the code area with a timestamp. In most configurations the report does not merely count them, it quotes the pasted content back to the reviewer. So a recruiter sees that at 14:22:07 you pasted eleven lines, and reads those eleven lines. Content matters more than count here. Pasting a helper you wrote earlier in the same editor is unremarkable. Pasting a complete, correct, stylistically foreign solution ninety seconds before you submit is what gets escalated.
Focus loss. The focus log records each time the assessment window stopped being the active window, with a timestamp per event and a total time away. Be precise about the boundary: it captures that the window lost focus and for how long, not what you switched to. HackerRank cannot see your other tabs, your second monitor, or your phone. Fourteen events totalling six minutes is a behaviour pattern, and the innocent explanations are real ones, a notification, a break, the statement open in a second window. What reads badly is one long absence immediately before a clean submission.
The two flag categories, and what each one proves
Plagiarism detection surfaces flags in two different families. They get confused constantly, including by the people reading the report, and they carry very different weight.
| Code Similarity | Coding Patterns | |
|---|---|---|
| What it compares | Your submission against other candidates' submissions and against known public solutions | How the code arrived in the editor: insertion size, editing rhythm, whether the solution grew or landed whole |
| What it actually proves | That your code resembles other code | That your code was not composed incrementally inside that editor |
| What it does not prove | Copying. Standard solutions converge. Two candidates writing the canonical two-pointer answer look alike because there is one good answer | Cheating. Drafting in your own IDE and pasting it in triggers it. So does having genuinely memorised a classic problem |
| Strongest against | Verbatim lifts, especially with preserved variable names, unusual formatting, or comments carried over from the source | A full solution appearing in a single event with no failed compile, no refactor, no exploratory print statement |
| Weakest against | Easy and medium problems where the optimal answer is short and standard | Fast, confident, experienced candidates, who look identical to prepared ones |
Both are presented as signals to investigate rather than verdicts. The usual consequence is not a silent reject but a request to walk through your solution live, a conversation you win comfortably if the code is genuinely yours. If it is not, that is exactly where it comes apart.
The report is evidence about process, not only about outcome. A reviewer who trusts the process stops reading after the scorecard. That is the outcome worth engineering for.
Where OfferPilot is the wrong tool for this
Code Copilot is a Windows 10 and 11 desktop overlay that reads a problem off your screen and returns an optimal solution with intuition, a dry run and Big-O complexity. Its overlay is excluded from screen capture at the operating-system level, so it stays out of Zoom, Teams, Meet, OBS and screenshots. That is a narrow guarantee, and here is where it stops.
- It does not touch any field described above. Capture exclusion hides pixels from a screen-share stream. It has no effect on the paste log, the focus log, submission timestamps, or either flag category. If text arrives in the editor by paste, the report records that paste and quotes it, wherever the text came from.
- It does not address proctoring that is not screen capture. Webcam monitoring, a lockdown browser, an invigilator in the room, eye tracking, or a second-device camera all sit outside what capture exclusion does. If your assessment is webcam-proctored or locked down, treat the tool as unavailable and prepare instead.
- It is Windows only. No macOS, no Linux, no mobile, no browser extension. If you assess on a Mac, this is not a decision you need to make.
The honest use is before the test window opens. Working timed problems with something that shows the intuition and the complexity analysis, rather than just an answer, is how the report ends up reading like fluency instead of retrieval. Rehearsing against the company question banks and building a role-specific set with the Q&A generator serves the same end for the interview that follows.
What follows from all this
Type your solution in the editor rather than composing elsewhere and pasting it across, because the paste log is quoted verbatim. Submit early and often, since a visible progression from failing to passing is the strongest evidence of authorship in the whole report. Read the constraints first, because the hidden grid is where an O(n squared) answer that cleared every sample falls over. And leave the tab alone, not because switching is forbidden, but so the reviewer never has to weigh it. None of this is about avoiding detection. It is about making the report an accurate record of work you did, which is the only version that survives the follow-up conversation.