20+ Years of Marathon Match: Jaco Cronje on Testing Problems That Actually Hold Up

At Topcoder, few members have shaped the Marathon Match experience as consistently as Jaco Cronje [JacoCronje]. Jaco took part in the very first Marathon Match back in the early 2000s and has stayed close to the format ever since - first as a competitor, then as a writer, and today he's mostly testing - though he still writes problems from time to time - making sure every problem that goes live is fair, fun, and genuinely challenging.

Over the years he's helped write and test some of the community's most memorable problems, catching the bugs and edge cases that would otherwise slip through. He's also pushed for the kind of creative, well-balanced design that keeps Marathon Match interesting even as AI changes how problems get solved. We're grateful for the care and craft he brings to every round - here's Jaco, in his own words.

1. Could you tell new people what you do at Topcoder?

I've been involved with Topcoder since the early 2000s and took part in the very first Marathon Match. I participated for many years before switching to writing and testing Marathon Match problems. Lately, I'm mostly involved in testing problems before they launch, with the goal of creating great and fun challenges for the community.

2. What does "testing a problem" actually involve before it goes live?

A lot of things need to be checked. The tester code needs to be checked for bugs and to make sure it works correctly. Test case generation should work reliably and not crash when generating input data for any seed. Any risks that could break the scoring need to be identified. The problem should not be too similar to anything we've had before and should be as unique as possible. The example solutions need to be verified.

I would also write solutions for the problem myself and see how easy it would be to solve, from basic greedy solutions to more complex approaches. I would also try to break the tester by writing solutions that make illegal moves, crash, or time out. The problem statement gets reviewed, and iterative review and improvement cycles happen between the problem tester and writer. Testing the problem also involves coming up with new ideas that could improve the problem and suggestions for improving the visualization. The writer and tester then collaborate on these ideas. The tester also determines the difficulty level of the problem and proposes how the difficulty can be adjusted if needed.

3. Any example where testing caught something that would've been a real problem?

Probably almost everything I caught would have been a real problem. Things like the tester crashing on a few seeds, invalid input being accepted, or discovering that the initial problem was simply too easy to solve almost perfectly.

4. What makes a problem "good" vs. just technically correct?
A good problem should look like fun to solve, with a nice, attractive visualizer. The problem should be easy to understand and not be confusing. It should be easy to write a solution that scores some points, but difficult to write a solution that scores optimally.

There should be a diverse number of ways to try to solve the problem, keeping contestants thinking and experimenting throughout the whole contest period.

5. What's the part you like the most about testing?

Coming up with new ideas on how to improve the problem after playing around with it and trying to solve it as well as possible. AI has changed things a lot lately, and it is fun to quickly try different approaches by letting AI loose on different solving strategies.

6. What do you do in your free time?

I love going for a hike or a run outdoors. I have a greenhouse and like planting and growing my own vegetables and spices, especially chillies. Otherwise, I spend my free time reading and playing around with anything related to computer vision, AI, robotics, or health tech.

Jaco on a hiking trip to Hell's Gate, Kenya

7. You've written problems too - does that change how you test other people's?

It definitely helps to have the experience of having participated in hundreds of marathon matches over the years. I still apply the same thinking when testing a problem as I would when writing one. I try to find both the positives and negatives in the problem and look for ways to improve it, even while testing.

8. What's the hardest part of writing a good problem - coming up with the idea, or getting the difficulty right?

Firstly, coming up with a unique idea that hasn't been used before. Then, balancing the fun factor with the difficulty and depth of the problem.

I think today we have an additional challenge when creating good problems: coding agents should not be able to solve the problem too easily. We need to design problems where the human factor - creativity, intuition, and ideas - can still beat the models.

9. What's your favorite problem from all you've tested/wrote and why?

Probably somewhere between the 2016 TCO Marathon - Final Round (XplosionMan) and Marathon Match 123 (Jewels). Both were games, and I really enjoyed creating the visualizations and seeing how different solutions would perform while playing games that we as humans enjoy playing. Both were also fun to play manually.

It was especially great to see Psyho having fun with XplosionMan during the 2016 onsite finals, and to receive positive feedback from the legend himself afterwards.