How (NOT) To Cheat In Online Coding Rounds | AI Engineer Series

This chapter demystifies the inner workings of modern online assessment (OA) proctoring systems. It explains why naive plagiarism techniques—such as renaming variables, inserting dead code, or copying directly from Generative AI tools like ChatGPT and Gemini—fail to bypass automated checks, and explores the multi-layered risk-scoring algorithms used by top-tier tech platforms to flag academic dishonesty.

1. The Illusion of the "Perfect" Cheat

Many candidates participate in online coding assessments, copy solutions from external sources, pass all visible test cases, and yet find themselves rejected without explanation. This discrepancy arises from a fundamental misunderstanding of automated proctoring.

Candidates often assume they are safe if they avoid basic triggers:

• Keeping their eyes glued to the camera.
• Avoiding copy-paste keyboard shortcuts (manually typing out the code instead).
• Keeping mobile phones out of the camera's field of view.
• Ensuring absolute silence in the room.

Despite these precautions, modern automated proctoring systems analyze the submitted code itself, independent of physical behavior. These systems do not rely on a single metric; instead, they run multiple static, dynamic, and heuristic analyses to calculate a unified risk score.

2. MOSS (Measure Of Software Similarity) – The Gold Standard

Developed at Stanford University in 1994 (with roots tracing back to the 1980s), MOSS remains the foundational engine for code similarity detection in academia and industry.

Real-Life Analogy

Think of MOSS as a forensic handwriting expert. Even if you copy someone else's essay and change a few words or use different colored ink, the sentence structure, paragraph flow, and grammatical habits remain identical. MOSS strips away the "paint" (variable names, formatting) to inspect the underlying skeleton of the code.

MOSS is highly effective at catching naive plagiarism. It does not perform a simple character-by-character comparison; instead, it normalizes the source code before running similarity algorithms.

3. How MOSS Works – Step 1: Variable Abstraction

The first phase of MOSS is lexical analysis and abstraction. When a candidate copies code and attempts to disguise it by renaming variables or functions, MOSS completely neutralizes this effort.

The Naive Obfuscation Attempt

Consider an original program written by Pratyush to calculate the sum of an array, and an obfuscated copy written by Divya:

Pratyush's Original Code (C++)

int sumOfArray(int arr[], int n) {
    int sum = 0;
    for (int i = 0; i < n; i++) {
        sum += arr[i];
    }
    return sum;
}

Divya's Obfuscated Code (Renamed Variables)

int calculateTotal(int targetArray[], int size) {
    int totalValue = 0;
    for (int j = 0; j < size; j++) {
        totalValue += targetArray[j];
    }
    return totalValue;
}

The MOSS Abstraction Process

MOSS parses both codebases into abstract syntax tokens and replaces all user-defined identifiers (variables, function names, parameters) with a generic placeholder, such as ID.

After abstraction, both codes are mapped to the exact same structural representation:

FUNCTION ID ( ID [] , ID ) {
    ID = 0;
    FOR ( ID = 0 ; ID < ID ; ID++ ) {
        ID += ID [ ID ];
    }
    RETURN ID;
}

Because both token streams are identical, MOSS flags this as a 100% structural match. Renaming variables is entirely ineffective against modern proctoring engines.

4. How MOSS Works – Step 2: Tokenization, Hashing, and Fingerprinting

To catch candidates who insert "dead code" (useless loops, unused variables, or dummy print statements) to lower similarity scores, MOSS uses k-gram tokenization and document fingerprinting (specifically, the Winnowing algorithm).

The Tokenization Process

1. Token Stream Generation: The abstracted code is converted into a continuous stream of tokens.
2. K-Gram Splitting: The stream is divided into overlapping substrings of length $k$ (where $k$ is a pre-determined window size, typically between 5 and 9 tokens).
3. Hashing: Each $k$-gram is hashed into a numeric value.
4. Fingerprinting: A subset of these hashes is selected using a sliding window algorithm to form the unique "fingerprint" of the submission.

The Impact of Dead Code Insertion

If Divya copies Pratyush's code but inserts a useless loop in the middle:

// Divya's code with inserted dead code
int totalValue = 0;
for (int x = 0; x < 5; x++) {  // Dead Code
    int temp = x * 2;          // Dead Code
}                              // Dead Code
for (int j = 0; j < size; j++) {
    totalValue += targetArray[j];
}

MOSS compares the fingerprints of both submissions:

• Pratyush's Code matches 100% of Divya's core logic.
• Divya's Code matches 80% of Pratyush's code (due to the extra 20% of dead code).

Because the core logic matches, the system flags both candidates.

Note: Comments are completely stripped out during the preprocessing phase. Adding, removing, or modifying comments has zero impact on the similarity score.

5. Bypassing MOSS via Structural Refactoring

To bypass MOSS, a candidate must fundamentally alter the control flow and data structures of the program, rather than just changing variable names.

Structural Transformation Comparison

Example: Structural Shift (Iterative to Recursive)

If the original code uses an iterative loop:

int sum = 0;
for (int i = 0; i < n; i++) {
    sum += arr[i];
}

A structurally distinct recursive implementation that produces the same result but generates completely different MOSS tokens is:

int getSum(int arr[], int n) {
    if (n <= 0) return 0;
    return arr[n - 1] + getSum(arr, n - 1);
}

The Plagiarism Paradox: If a candidate possesses the technical skill required to read a solution, understand its control flow, and rewrite it using alternative data structures or recursion, they generally do not need to cheat in the first place.

6. Same Bug Detection (Logical Fingerprinting)

Even if a candidate successfully alters the structure of copied code to bypass MOSS, they often fall victim to Same Bug Detection.

When candidates copy code from a shared source (such as a WhatsApp group, Discord server, or a peer), they also inherit any logical flaws, edge-case failures, or optimization bugs present in the original code.

The Detection Mechanism

Online assessment platforms like HackerRank, CodeSignal, and LeetCode run submissions against a large suite of hidden test cases.

• If Candidate A and Candidate B both fail the exact same subset of obscure hidden test cases (e.g., failing test cases #20, #22, and #26 due to an integer overflow or an unhandled null pointer), the platform flags them for logical correlation.
• The probability of two independent, correct-seeking candidates writing structurally different code that fails on the exact same set of random edge cases is statistically negligible.

7. AI Plagiarism Detection – How Platforms Catch ChatGPT & Gemini

With the rise of Large Language Models (LLMs), candidates frequently copy prompts directly into ChatGPT or Gemini. Because these models generate code dynamically, MOSS cannot easily flag a submission if no other candidate submits the exact same code.

To counter this, modern platforms use two primary techniques: Pre-Generation Fingerprinting and LLM-as-a-Judge.

Technique 1: Pre-Generation Fingerprinting

Before an online assessment begins, the platform's engineering team feeds the test prompts into popular LLMs (GPT-4, Gemini, Claude) multiple times.

If a candidate's code matches one of these pre-generated AI templates, they are flagged for plagiarism.

Technique 2: LLM-as-a-Judge (Stylometry Analysis)

The platform sends the candidate's code to an LLM evaluator to determine the probability that the code was AI-generated. This evaluation is based on code stylometry:

8. Bypassing AI Detection (Prompt Engineering & Humanization)

To bypass AI detection, candidates must instruct the LLM to mimic human coding flaws. This is done by applying specific constraints to the prompt.

The "Humanized" Prompt Pattern

Instead of a simple prompt like "Write a C++ program to solve Two Sum," a bypass prompt forces the model to write imperfect code:

"Solve the following coding problem in C++. 
However, write it like a stressed college student under time pressure:
1. Use short, non-descriptive variable names (like 't', 'temp', 'a1', 'ans').
2. Do not include any comments.
3. Do not write perfectly formatted code; leave some inconsistent spacing.
4. Avoid advanced helper functions; use basic loops and standard arrays."

Output Comparison

• Standard AI Output (Highly Flagged):

  C++

  Copy

  int calculateArraySum(const std::vector<int>& inputNumbers) {
      int totalSum = 0;
      for (int number : inputNumbers) {
          totalSum += number;
      }
      return totalSum;
  }
  

• Humanized AI Output (Low Flag Risk):

  C++

  Copy

  int get_sum(int a[], int n) {
      int s=0;
      for(int i=0;i<n;i++){
          s += a[i];
      }
      return s;
  }
  

9. Multi-Factor Risk Scoring & Behavioral Proctoring

No single detection method is used to disqualify a candidate. Instead, modern proctoring platforms aggregate data from multiple vectors to calculate a unified Risk Score.

The overall risk score can be modeled as a weighted function of static, dynamic, and behavioral inputs:

Where:

• $S_{\text{MOSS}}$ is the structural similarity score against other candidates.
• $S_{\text{Bug}}$ is the logical correlation of failed test cases.
• $S_{\text{AI}}$ is the probability of AI generation.
• $B_{\text{Proctor}}$ represents behavioral flags (tab switching, copy-paste events, camera/audio anomalies).
• $w_1, w_2, w_3, w_4$ are weights assigned by the platform.

Risk Thresholds

• Low Risk (< 40%): Automatically passed to the next round.
• Medium Risk (40% - 70%): Flagged for manual review by a recruiter or technical lead.
• High Risk (> 70%): Automatically disqualified in high-volume hiring pipelines (e.g., campus placements with thousands of applicants), as manual review of every candidate is logistically impossible.

10. Complete Proctoring Flow Walkthrough

The following vertical workflow illustrates the path a code submission takes through a modern proctoring pipeline, from initial input to the final hiring decision:

Summary and Key Takeaways

• Variable Renaming is Obsolete: MOSS has neutralized variable and function renaming since the 1990s by abstracting all identifiers into generic tokens before comparison.
• Dead Code is Easily Detected: Inserting dummy loops, unused variables, or print statements does not hide plagiarism. MOSS uses sliding-window tokenization (k-grams) to match the core logic.
• Logical Fingerprints Exist: If you copy code, you inherit its bugs. Failing the exact same hidden test cases as another candidate is a strong indicator of plagiarism.
• AI Code is Highly Identifiable: Standard AI-generated code is characterized by perfect formatting, descriptive variable names, and clean structure. Proctoring systems flag these patterns using LLM-based classifiers.
• Pre-Generation Databases: Platforms query popular LLMs with the test questions before the exam, creating a database of AI solutions to run similarity checks against.
• Bypassing Requires Structural Rewriting: To bypass similarity checks, you must fundamentally change the program's structure (e.g., converting loops to recursion or swapping data structures) and instruct the AI to write with human-like imperfections.
• Decisions are Multi-Factor: Platforms combine code similarity, bug correlation, AI probability, and behavioral tracking into a single risk score. If this score exceeds a set threshold, the candidate is flagged or automatically rejected.