Blog post cover

2018-10-21 02:29 - Events

How we organized the ShaKer Coding Battle

Once again the INSAlgo student club partnered with the KerTeam to organize a giant Coding Battle for students and employees of the companies participating to the ShaKer fair. As the chairperson of INSAlgo, I managed a team of students for 2 months to prepare this event.

In this article I explain how we organized the event, and provide some stats and fun facts about the Coding Battle.

Context

The ShaKer

The ShaKer is a job fair to put together students and companies in the fields of IT and telecommunications. The idea is a kind of speed dating: students and engineers are matched depending on the keywords they specified, and have 3 meetings before they can freely talk during a buffet.

The Coding Battle happens the evening before, and contestants can participate online from all France and even abroad. Usually companies and some schools gather in hubs, as e.g Dailymotion and Dassault did:

Companies participate to the Coding Battle

The Coding Battle is made of 6 exercises with increasing difficulty, from a very simple coding exercise to a hard algorithm. The limited amount of time makes the challenge even harder (only 4 contestants managed to get all the points).

The INSAlgo Team

We were 4 students working on the project, with some help from Thomas Lacroix who organized the event last year. We’re all students at the Computer Science faculty at INSA de Lyon: Alexis Le Conte, Arthur Tondereau, Mohamed Challal, and me.

Having more experience of administration, web software development and Docker, I worked mostly on the platform, while the 3 others worked on finding and writing the problems, implementing solutions and test sets’ generators. The last problem was created by a researcher at LIRIS, Vasile-Marian Scuturici, who is also our coach for major competitions.

Here is the team during the contest, answering questions and administrating the platform:

The INSAlgo Team

Technical details

Plateform and infrastructure

For the platform, I worked with the free and open source Contest Management System (CMS). Its free license allowed me to modify the platform for our exact needs (you can check my fork). I then created a Docker image to be able to deploy the app easily on Amazon Web Services.

The modifications I made on the platform are the following:

  • Support for multilingual contests (multiple contest descriptions, task titles and statements, etc)
  • Support for authentication through the OpenID Connect protocol to authentify contestants with the KerTeam server
  • Improved the contest import system to allow more configuration
  • Improved user interface
  • Improved the scoring system (e.g to determine that the fastest contestant wins in case of ex aequo)
  • Added features to export data and allow data mining.

Concerning the infrastructure, here are the machines I used to host the Coding Battle:

  • Main machine (master): 8 vCPU, RAM 32 GiB
  • Web servers: 5 (4 vCPU, RAM 16 GiB) - 20 web servers
  • Evaluation: 4 (8 vCPU, RAM 32 GiB) - 32 workers
  • Database: PostgreSQL, duplicated deployment, 4 vCPU, RAM 32 GiB

Problems, solutions, tests

To help us create the problems, we used the tool Polygon from Codeforces. This tools allows to compare multiple solutions to a reference solution, generate test sets, validate the test sets, choose the bounds of the statement and the time and memory limits.

This tools provides a frame to create the contests, and saves us a lot of work comparing solutions and making benchmarks by hand. It helps us to verify our statements, solutions and test sets.

Some stats

Although exercises were all available at the start, most of the contestants tried them in order. Exercises A and B were solved by most of the contestants, C was the first blocking wall, and very few contestants had time to try the remaining exercises.

You can clearly see it on the chart of submissions over time below (on the left, total submissions each minute, on the right the percentages of submissions per exercice over time). You can see more submissions a few minutes after the start, and a few minutes before the end, because at the start everybody quickly solves the first exercise and tries to submit a solution, and at the end everybody hurries to submit a solution for the last exercise they are working on:

Submissions over time

Concerning the scores (on the left, the percentage of contestants with points for each exercise, on the right the scores), you see a good increasing difficulty with a gap between B and C:

Scores

Concerning the programming languages, contestants using C++ were the most successful, then Python, Java, C, and the least successful were C# and PHP, as shown on the chart below:

Languages per score

Fun facts

The day of the contest, when trying to deploy the platform, I discovered that my Amazon Web Services account was too young to rent all the servers I needed, so I called the technical support, I was quickly in contact with a guy in Washington DC who told me he would unlock my limits within 24 hours. I couldn’t wait so I used less machines but with more cores and memory.

During the contest, 10 minutes before the end, all the submissions stopped to compile or be evaluated. The problem wasn’t about CPU or memory, but the storage of the workers that got saturated with the temporary files of the programs to evaluate. We made an announcement to tell people that they should keep submitting, and I quickly cleared the memory of the machines and a few minutes later we were able to evaluate all submissions.

Conclusion

This project took me a lot of time and was a source of stress, I consider it almost as a miracle that it worked, given the number of things that could have failed. We worked for weeks on something that would last only 2 hours. 2 hours without a single failure, neither on the platform nor the problems and test sets.

Thanks to the team who worked with me on this project, it definitely was a very useful experience for us all!

Log in to post a comment.