We have all had the time when we open a programming packet to glance over the problem set before choosing one to start on first. This can be the most crucial stage in any competition as it is essential for getting the easier issues out of the way and setting the pace for the rest of the competition. It is crucial to start off your competition on a high note so that you can roll through the rest of the ‘easy’ problems quickly.
In a standard UIL programming contest, you are given two hours to solve twelve coding problems of varying difficulty. These can range from advanced topics such as relational objects to basic applications like printing out five simple lines of code. There are typically two easy problems, three to four advanced problems, and the rest can be classified as medium difficulty. Points are points when it comes down to scoring so there is no reason to head straight for the hardest problems when you have seven or eight easier problems. This is one of the greatest roadblocks for smart teams. The members feel that they can handle these harder topics making them ignore the easier questions and consequently losing out on easy points that could have been gained in a lesser amount of time.
So how do you find the easy problems?
The first step in any contest should be to find the easiest two problems and give them to your weakest member, so the other two can rank the rest of the packet based on relative difficulty. We like to assign each problem a rank from one to three with the occasional rank of ‘impossible’. Impossible questions are ones that we could not solve given a week and a lethal dose of caffeine. From these rankings, we are able to assess the packet from a different point of view. No longer are the problems numbered one through twelve, now they are ranked in piles of ones, twos, and threes.
Attacking the ones )
The first stack that should be solved is the ones. These are questions that are basic String methods or manipulation of loops. Your goal should be to spend around ten minutes on each of these problems. A common strategy used by my team is to have two members work on these problems while the other member starts to delve into the more difficult material.
Ex: Problems that have no input and just print output.
Tackling the twos )
Once you have tackled the basic ones, you move on to the two. These are problems that require critical thinking to crack but end up having a simple solution in the end. Looking at a problem at face value can make even the most simple questions appear to be hard. You must be able to look further into the problem to find what it is truly asking for as there is almost always a way to either brute force the answer or get it very easily from the input with little data manipulation.
If you can brute force a problem there is no need to solve it gracefully. UIL is not a test of the ability to code efficiently, it is a test of sheer will to find the most brutish way to solve a problem. This was the greatest realization that helped to take my team to state in 2022. We no longer looked for the intended solution, but the solution that was meant to be destroyed. The solution that they fully intended no one to use since it is so inefficient and crude.
Ex: A few years back we were posed with the question of factoring an expression of degree one to four. At first glance, this seemed like it would take four methods, one for each degree of expression; however, given that the solution was guaranteed to be an integer of range [-1000,1000] there was a much simpler solution. Try every possible solution. I started a for loop at the value of -1000 and ended at 1000. I then plugged this value in for each x in the expression ensuring to raise it to the respective exponent at each occurrence. Using this over-the-top brute force approach I was able to solve a somewhat complex problem in five minutes.
Trudging thru the threes )
This is where the competition starts to discern the good from the bad, the strong from the weak. If you are able to take on all of the basic problems and still have time left for the more difficult questions then you are either incredibly gifted at computer science, or a quick typer good at brute-forcing even the most difficult questions. But now that you are here, how do you go further. There are very distinct three hardest questions in every UIL packet. One of which can be discarded as fairly impractical to be solved with the leftover time of your two hours. Many of these questions require the usage of objects, map navigation, or intense recursion methods.
These problems may seem very difficult at face value, but they are stills solvable nonetheless. An example of one of these hard questions that were easily simplified can be found in my other article here. The trick is to not get too caught up in the small details and stay focussed on the deeper question within the question. There is a lot of fluff in many of these questions that you must look past to find the solution hidden deeper within.
I will be putting out articles on many questions that fall into each rank in the future so that you may refer to each of them to get a better understanding of each rank. However, you must decide on these rankings for yourself. If you are new to coding competitions there are things that some may deem easy that you feel are a little out of your reach currently. In the same vein, there are those who are so advanced that they are able to breeze through the entire packet without having to use their brain. The most important thing to remember is that difficulty is subjective. You have to find the questions that you think are easiest. Having the conversation with your team on how you would like to approach each packet based on your strengths and weaknesses can be the biggest step to becoming a largely successful programming team.