The grading bottleneck
Programming assignments are slow to grade well. A correct submission may use a different structure than the instructor expected, while an incorrect one may pass a few visible examples. I built an automated Java and Python grading engine to make evaluation faster and more consistent without reducing a student to one score. The system compiles or interprets a submission, runs controlled tests, captures results, and generates a detailed pass-and-fail report.
A hybrid architecture
Java provided the custom test harness, while Python handled orchestration across submissions. That split let each language do what it was good at. The harness focused on assertions and expected behavior. The orchestration layer discovered files, prepared an execution job, enforced limits, collected output, and assembled the final report. Keeping those responsibilities separate made it easier to add test cases without rewriting the workflow.
Treating submissions as untrusted
Student code is still arbitrary code. It can loop forever, consume memory, write files, or behave unexpectedly without malicious intent. I designed the execution path around isolation, time limits, and controlled inputs. Output also needs limits because one runaway print statement can overwhelm a grader. Secure execution is not an optional enhancement for an autograder. It is the condition that makes automation safe enough to use.
Feedback matters more than the number
The most useful output is not 7 out of 10. It is a clear explanation of which behavior failed and what the system observed. I kept reports specific without exposing hidden test answers. Building the engine showed me that educational automation needs restraint. The system should remove repetitive work and make grading more consistent, while instructors still decide how edge cases, partial credit, and academic context should be handled.