How the Testlify Judge Environment Works

Error Code Reference

How Your Code Is Evaluated

1. How does the judge determine whether my solution is correct?

Your code is evaluated automatically by a code-checker — not a human reviewer. 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 (for example, an unexpected prompt like "Enter the number") will cause the submission to fail.

• Use only standard input (stdin) and standard output (stdout) for reading and writing.
• Do not use command-line arguments, file I/O, or dialog boxes — these will result in a wrong submission.
• You can print results as you process input; you do not need to read all input first.

2. How do I test my program on my local machine?

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 described in the problem statement to verify correctness before submitting.

Time and Memory Limits

3. How does the time limit work?

Your program must process all test cases within the specified time limit — not one test case per second. For example, if the time 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 this. Regardless of the language used, all input files are always processed, even if an earlier file fails.

4. How is total execution time calculated?

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

5. How is memory usage measured?

Memory usage includes everything allocated in the stack, data segment, heap, and BSS. For Java, JavaScript, or Scala, runtime environment 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 your program to be terminated.

Common Errors Explained

6. Why doesn't my program compile?

• C/C++: Use a standards-compliant compiler. Remove non-standard headers like conio.h and avoid outdated compilers such as Turbo C++.
• Java: Ensure inner classes are declared static where required — non-static inner classes may cause compilation errors. Testlify plans to relax this constraint in a future update.
• Other languages: Read the compilation error message carefully for language-specific guidance.

7. Does TLE mean my code is correct but slow?

Not necessarily. TLE (Time Limit Exceeded) means execution was forcibly stopped before completing — this can indicate an inefficient algorithm, an infinite loop, or both. For example, a program that takes 2.001 seconds with a 2-second limit is still judged as TLE regardless of whether the logic is correct.

8. Why do I get Time Limit Exceeded?

The most common cause is an algorithm that is too slow for the given constraints. To resolve 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.

9. What does Wrong Answer mean?

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 to ensure you are interpreting the requirements correctly and handling all edge cases.

10. Why do I get runtime errors?

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

• SIGSEGV: Segmentation fault — 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 allocation 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.

To prevent runtime errors: validate all inputs, initialize variables before use, and always check array bounds.

Submissions and Support

11. Can I view other candidates' solutions?

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

12. Why is my submission queued?

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 on your part.

13. What should I do if my submission is not evaluated?

If your submission remains stuck or is not evaluated 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.