How the Testlify Judge Environment Works

Before you begin

The Testlify judge evaluates your code automatically — not a human reviewer. Before submitting, ensure your solution follows these requirements:

• Use only standard input (stdin) and standard output (stdout) for reading and writing data.
• Do not use command-line arguments, file I/O, or dialog boxes — these produce a wrong submission.
• Do not print prompts (for example, "Enter the number") — the judge compares your output exactly against the expected result.

Error Code Reference

How Your Code Is Evaluated

Correctness check

For each problem, the judge runs your program against one or more input files and compares the output to the expected result exactly. Even a single extra character will cause the submission to fail. You can print results as you process input — you do not need to read all input before writing output.

Testing locally before submitting

Simulate the judge environment using stream redirection on the command line:

./a.out < input > output

This reads from a file named input and writes to a file named output. Compare the result against the expected output in the problem statement before submitting.

Time and Memory Limits

How the time limit works

Your program must process all test cases within the specified time limit — not one test case per second. For example, if the limit is 1 second and there are 100 test cases in a single input file, all 100 must complete within 1 second total.

Languages that run slower (such as Java) receive a time multiplier to account for runtime overhead. All input files are always processed, even if an earlier file fails.

How execution time is calculated

The execution time shown is the sum of time spent processing all input files. If your program exceeds the limit for any single input file, it is terminated immediately. Total execution time is always ≤ time limit × number of input files.

How memory usage is measured

Memory usage includes everything allocated in the stack, data segment, heap, and BSS. For Java, JavaScript, or Scala, runtime initialization adds overhead to the reported figure. Testlify generally does not enforce strict memory limits for these languages, but extreme memory usage may still cause termination.

Common Errors Explained

Compilation Error (CE)

• C/C++: Use a standards-compliant compiler. Remove non-standard headers like conio.h and avoid outdated compilers such as Turbo C++.
• Java: Declare inner classes as static where required — non-static inner classes may cause compilation errors.
• Other languages: Read the compilation error message carefully for language-specific guidance.

Time Limit Exceeded (TLE)

TLE means execution was forcibly stopped before completing. This can indicate an inefficient algorithm, an infinite loop, or both — it does not confirm the logic is correct. To fix TLE:

• Choose a more efficient algorithm — avoid unnecessary nested loops for high-constraint problems.
• Use faster I/O:
  • In Java, use BufferedReader and BufferedWriter instead of Scanner and System.out.println.
  • In C++, use scanf and printf instead of cin and cout.
• Account for server speed: Testlify's evaluation servers may run slower than your local machine. Solutions that pass locally by a narrow margin may still fail on the judge.

Wrong Answer (WA)

Your program ran successfully but produced an incorrect result. Passing the sample cases does not guarantee a correct solution — the judge uses additional hidden test cases. Re-read the problem statement carefully and verify that your solution handles all edge cases.

Runtime Errors (SIGSEGV, SIGFPE, SIGABRT, NZEC, MLE)

A runtime error occurs when your program crashes during execution. Common causes:

• SIGSEGV: Invalid memory access, such as reading an array out of bounds.
• SIGFPE: Division by zero or an invalid floating-point operation.
• SIGABRT: Program aborted — typically due to insufficient memory or a manual abort call.
• NZEC: Non-zero exit code — often caused by uncaught exceptions or a missing return 0 in C/C++.
• MLE: Memory Limit Exceeded — caused by overly large arrays or inefficient data structures.

Tip: Validate all inputs, initialize variables before use, and always check array bounds to prevent runtime errors.

Submissions and Support

Submission confidentiality

Testlify maintains full confidentiality of all submissions. Other candidates cannot view your code, and you cannot view theirs.

Queued or unevaluated submissions

High server traffic may cause brief processing delays. If the system is under maintenance, queued submissions are evaluated automatically once service resumes — no action is required. If your submission remains stuck after a reasonable wait, contact Testlify support at support@testlify.com.

Comments and Questions

For questions about test data or problem specifications, use the comment section on the problem's page. Do not share source code or post off-topic messages in comments.

Need help? Contact support.