The following guest post is from our 2017 Topcoder Open blogger, gorbunov.
This article is targeted mostly at software programmers who have never participated in Marathon Match (MM) contests, as well as those who did, but were not satisfied with the results.
Why another kind of competition?
Let us start with a little comparison between Marathon Match events (MM), Algorithm competitions, and real projects.
First of all, MMs are generally considered to be programming competitions. They are more similar to what programmers do at work than their short-term brother – Algorithm competitions. Let us describe this in more detail. When working on everyday projects, a programmer operates with medium to large amounts of code. So does a MM competitor – a solution to a MM task might be as long as 5,000 lines of code, while during short-term competitions it is enough to be able to produce 20-300 lines of code per task. Thus, the ability to quickly find the necessary part of the code is crucial for marathoners. Programmers use version control at work, and so do top marathoners.
As opposed to short Algorithm competitions where you are supposed to produce the best possible and single correct answer, MMs focus on tasks that do not have a single good or correct algorithm. This allows competitors to get a fraction of points even by submitting some code that an Algorithm competitor might consider useless, for instance, the first permutation of numbers 1..N, or something. Sure, if you want to get some fun out of the task, you should proceed further and develop a better solution, but once you have submitted a fake/demo solution you may get a portion of good emotions that will stimulate you to go forward.
The main ideas behind solutions of MM tasks are rather ad-hoc, meaning thinking is more important than knowledge of all the existing algorithms. Same is usually true for job tasks. This point is very important, as it should be easier for a man from a side who has programming experience, to enter and get non-zero points in MM-like contest than in Algorithm sprint. You are free to learn on the go, acquiring missing knowledge in the process of solving the task. This approach will most probably fail in an SRM/Algorithm competition because of time pressure.
Marathon matches usually last for 2-3 weeks, while Algorithm competitions are 1.5 hours long. This means that a competitor typically has at least 2 weekends to work on the solution, in addition to evenings. If you do not have work nor study, then you are lucky and can compete 24/7, but I would not recommend doing that mainly because this kind of contest should be more fun than hard work.
Summing it up and answering the above question, MMs provide a way to compare you against your colleagues from around the world while solving a puzzle that nobody knows how to solve. They also greatly improve your programming and solution finding skills.
Things you should know
If you feel ready to participate, then here are some bullets you should know. They may be unusual to people from the industry.
- Competitors cannot collaborate and/or discuss a given task until MM is over. This includes forums, private chatting, messengers, etc. Forums should be used carefully and for clarification of statement. If you have something to say that may disclose your approach (not important how primitive it could be), it is better to contact the organizers by e-mail. If you do not have email address, ask for them. Once the match is over, feel free to discuss everything anywhere.
- Scoring function. Your solution will be compared to others using a precise formula specified in the task statement. Take care to understand how it works. Creating some sort of table containing values of scoring function and its parameters might help. You may even draw a plot based on this table.
- A full submission means your solution will be evaluated against rivals, but you will not get full feedback, just your total score and rank. Example submissions give full feedback, like scores on individual tests, program’s output, execution time and memory usage. It does not give you a full score and rand though. Important trick is that once you have submitted the test, you are considered a participant, even if you did no full submission. This implies that your rating will be re-calculated after match. Another important thing is that your latest full submission is counted towards the final score. All others, including test submits and previous full submits, even if they are better, are discarded.
- Time and memory limit. You cannot exceed them. If you do by accident or on purpose, you get a 0 score for that test. Reading it backwards, if you get a 0 provisional score, check if you do not exceed time and memory limits. Doing an example submit may help. Please do not post your solution to forums if you have a 0 score. If you have a strong feeling that there is something wrong with the TC validator, please contact admins directly and privately.
- Visualizer. This is your friend. Usually you get it for free and can use it to test your solution locally, thus avoiding the 30 minutes between the test submissions limit. Once you are at advanced stages of solution development, you may want to check its source code and understand how the testcases are generated. Sometimes this provides insight on how you could modify the solution to get better results (kind of reverse engineering). Note that time measurements you make locally may be irrelevant once you submit. Test submit is recommended to calibrate local-server time scale.
- Last but not least, all the code you submit must be written on your own. No copy-paste from the Internet resources, or anything. Also, please read through the rules just in case. There were occasions when people were banned because of not following or not knowing them.
Where to start
You can also subscribe to the MM newsletter, to do so open your profile by clicking on the handle on top-right, Settings, Email.
Hope this will help you on your marathoner’s way.