This is a copy of a Quora answer I wrote to “How many tasks should be completed to win Google Code-in?”
Hello.
I was a Grand Prize Winner back in 2015, so I think I can help you with this.
The question by itself is flawed, but I will try to answer what you were getting at. I assume you wanted to know “How to win Google Code-in”.
The judging mechanism in GCI is a very subjective mechanism. Even if you did more tasks than someone else, there is a good chance you might not win.
In general there are some principles that seem to hold, in my 3 years of GCI experience
Code tasks are more important than other tasks, given you’re actually contributing to a project and not doing a “learning task”. In recent years I’ve noticed there are some tasks that goes like “Learn node.js and make a chat server” or “Implement a unigram tagger”. These tasks might not involved actual contribution to a project but are intended to make you capable enough to eventually be able to contribute fully to the projects. These tasks don’t really hold much weight in my opinion. They’re like better versions of beginner tasks.
Mentors should remember you and your contributions. The best way to ensure this is to truly do good work. All other prescriptions will fail. Your work should make an impact to the community, or at least make more impact than your competitors.
Quality is greater than quantity, but only to an extent.
You will often see this phrase thrown about in IRC logs and mailing lists discussing GCI: “Quality > Quantity”. That is true, but it is not complete. It should say, “Quality > Quantity but only when you quality is clearly visible”
First we must understand what is meant by quality here. From my observations it seems to be a mix of something like code quality, community behaviour (how chatty you are, how helpful, can you really collaborate smoothly?, etc), impact of your work, whether you are willing to contribute long term or not, etc. This is a great ideal to keep and Google has done a very good job of emphasising this. This encourages proper contribution and is an attempt to prevent “over-gamification” of GCI.
However, it is difficult to weight these factors properly and mentors often have different perspectives of these factors. To one mentor, impact might mean more than long term dedication. To some, code quality is more important. After averaging these out, eventually we are left with another random weighting of these factors. We can know that all of these matter, more or less, but we cannot know what matter more. Sometimes mentors even struggle to distinguish between two participants qualitatively, because they’re contributing to different parts of the organization. This is what happened with me once, and finally quantity has to be taken into account. Quantity is the tie breaker when it is hard to perceive quality.
So what is a good strategy. Alas, it’s to contribute in good will and have fun while doing it. Did you expect a prescription? “Do this, do that, and you’ll win”? Prescriptions are not strong enough for these things :)
Did you expect a mathematical checkmate? I did too. Turns out ethics works. :)
Anyway, play the game for the fun of it. Don’t aim to win and struggle for it endlessly. Life is long.
