Correct is not the same as working
A large share of submissions run fine on the example input and fall over on the second one. Reviewing forces you to read for the input nobody tried.
Track record
Jun 2025 – Aug 2026 · Remote
Software Engineering Consultant & SME
Fourteen months reviewing systems-level software at volume, and writing down what separates the correct implementations from the ones that merely run. Plus a head-to-head benchmark of what the coding agents actually produce.
- Role
- Consultant & SME
- Period
- Jun 2025 - Aug 2026
- Basis
- Remote
- Reviewed
- 150+ solutions
- Domains
- C++ · Python · Linux
01The platform
EcademicTube Pvt Ltd runs an online academic support platform - tutoring, study help and assignment support for university students, with subject matter experts behind it. Their coverage spans engineering across mechanical, civil, electrical, chemical, instrumentation and computer science, alongside maths, physics and the business subjects, aligned to a stated 1000+ universities.
I came in on the engineering side as a subject matter expert: the person who reads a submitted solution and decides whether it is actually correct, and if not, where exactly it went wrong and why.
Platform description is from ecademictube.com. The work below is mine.
02What I did
Fourteen months of reading other people’s systems code closely enough to say something useful about it. The volume is the part that changed how I work - after a hundred solutions you stop reading line by line and start recognising shapes.
- Reviewed 150+ engineering solutions in C++, Python and Linux systems - correctness, edge cases, performance bottlenecks and implementation quality against professional standards.
- Assessed systems code for concurrency defects. Race conditions, memory-management faults and architectural tradeoffs across operating systems, networking and infrastructure code.
- Benchmarked coding-agent output from Claude Code, Gemini CLI, Cursor, GitHub Copilot and Codex, to quantify differences in correctness and scalability on complex systems tasks.
- Authored technical documentation on Linux programming patterns, concurrency debugging workflows and systems-level problem solving.
- Reviewed and annotated embedded code in MATLAB, Verilog and Embedded C for functional and logical correctness.
03What 150 reviews teaches you
The same defects come back. Not the same code - the same shapes, in different code, from different people, over and over. That repetition is the whole value of reviewing at volume, and it is not something you get from writing your own code.
Concurrency bugs hide in the happy path
Races almost never show up in the case the author tested. You find them by reading the interleavings, not by running the program.
Ownership is where memory goes wrong
Most memory defects I flagged were not leaks as such. They were two pieces of code disagreeing about who was responsible for freeing something.
Architecture cost is invisible early
The choice that makes a small program simple is often the one that makes the large version impossible. That is the hardest thing to flag without sounding pedantic.
It also changed how I write. Smaller surfaces, explicit failure paths, and comments that explain the constraint rather than restate the syntax - all of that is a reaction to reading code where those things were missing.
04Benchmarking the agents
Part of the brief was comparing what coding agents produce on the same systems tasks. The interesting question was never which one feels quicker. It was which one still holds up when the task has concurrency, memory ownership or protocol state in it. And that only shows in correctness and scalability numbers, not in the first impression.
- Five agents run against the same systems tasks under the same conditions.
- Judged on correctness first, then on how the solution behaves as the input grows.
- Failures characterised rather than just counted - a wrong answer and a subtly racy answer are not the same defect.
05Where it led
This is the role that turned reviewing from an opinion into a measurement discipline, and it is a direct line into the evaluation work I do now. Designing problems to break a model is the same skill as spotting where a submission will break, pointed in the other direction.