Three lessons from my first coding competition.
Learn from failure. Then, try again.
A fortnight ago, I participated in my first coding competition — Kotlin Heroes 4 presented by JetBrains and Codeforces. I’d like to say I was aiming for first place and the prize money, but I just thought it was a neat way to learn and practice Kotlin.
And I wanted a cool shirt.
Spoiler: I didn’t get a shirt.
A week before the competition, there was a practice round, which lasted up ’til an hour before the actual competition. I solved the 5 practice problems without major issue — most of my struggles revolved around figuring out the corresponding method or syntax in Kotlin.
Come time for the start of the competition, I was pumped. I thought I had a shirt in the bag. After all, top 50: how hard could it be?
Answer: very.
I placed 448 of 1365. I solved all of two problems before I got stuck on the third (there were a total of 9 questions). My solution kept exceeding the time limit (2 seconds per test), and I spent the second half of the competition trying to optimize it, to no avail.
The allotted two and a half hours flew by, and after assessing my progress, I decided to do a retrospective. I came up with three lessons. Without further ado, here they are:
- Simplify.
- Be practical, not elegant.
- Solve only what’s asked, and nothing more.
Simplify.
The third problem — the one I got stuck on — involved books and bookcases. The idea was to figure out the minimum possible time to sort the bookcase based on the conditions given. Sorting the bookcase could be done through two actions: removing an entire shelf of books, and redistributing the books equally.
Through the course of the competition, I kept the bookcase sorted in the exact order it was given in — even replacing shelves with 0 when performing the action 1. In hindsight, this was not only unnecessary, but probably the cause for my solution timing out.
What I should’ve done was a) sort the shelves in the beginning, because there was no requirement to keep the shelves in order — this would have significantly reduced the time it took to find and remove the largest shelf; and b) completely remove empty shelves, because there was no requirement to find the end state of the bookcase.
Keep it simple. It’ll save time and effort.
Be practical, not elegant.
I tend towards perfectionism. This means I’m constantly fighting a battle in my head between making something better and writing more functionality. Throughout the competition, I kept going back to lines that worked perfectly just to get them just right. I probably wasted a good amount of time doing so.
When competing, every second counts — you are penalized based on time and/or number of submissions in front of you. In coding competitions, no one really cares how atrocious your code looks. You could have unused lines, your functions may have an extra argument, or there may even be a more elegant way of writing it. Forget all that.
As long as it solves the problem correctly, you get credit for it.
Solve only what’s asked, and nothing more.
Back to the bookshelf problem. The problem didn’t ask about the state of the bookcase, or of any of the shelves. It only asked for the minimum time to “sort” it according to some set of conditions. Sort is in quotes here because it doesn’t actually matter that the bookcase is sorted properly. As long as the time taken is tracked, shortcuts can be made in the process.
I mentioned two shortcuts in the first point — sorting the shelves and removing empty shelves to reduce search time. Another shortcut is to avoid performing the action altogether. Due to the way the problem is structured, you never need to actually perform action 2, since it will always be the last action, if performed. Therefore, to save time, you can simply add the time cost of action 2, then output the total time taken.
Don’t solve for other parameters if they aren’t needed. It creates more potential for error, and uses up precious time.
Thanks for your time, and I hope these pointers help you in your next (or first) competition!
