In case you missed them, here are the previous posts in this series:
- Ask John: Competition Teams – Part One – How to get started
- Ask John: Competition Teams – Part Two – Resources to use
- Ask John: Competition Teams – Part Three – Practice, Practice, Practice!
My team has little or no contest experience, and I need help preparing them for the big day. What are some good suggestions you might have that would help us out?
Congratulations! You have taken a bold step in getting this far, starting a team, finding good resources, and putting in some valuable practice time. Now it is time to get your feet wet!
Going to a computer science competition can be a bit intimidating, because almost every time you go, there is at least one team, and sometimes many more, that have done this before, and are perhaps better prepared and more experienced than you and your team. Get used to that feeling, and be OK with it. The most important thing about practice contests is to gain experience so that the next time, you will be higher up on the experience ladder. The goal is to eventually walk into the contest room, so confident that YOU are now the top dog!
Crystal Riley, my former student, was involved with competitions all four years of her high school career, went to many contests, was very successful as a team leader, and has these suggestions.
As far as team strategies go, there is no catch-all technique that works the best for all teams. It really depends on how your students interact with each other and their individual strengths and weaknesses. I’ve seen some teams do really well by having one really strong coder to solve all the really difficult problems, and two quick typers to crank out the easier problems while the other is thinking. I’ve seen other teams use a timer to give each student exactly 10 minutes at a time at the machine. Sometimes the winning team is one that writes pseudo-code together for every problem then takes turns typing up their solutions when they figure it out as a team. These are some paradigms to try with your growing team, but don’t push your students to work together in a way that works against their groove.
Here are some suggestions based on my experiences over the years.
- The most important thing before you leave for the contest is to make sure you have all of your equipment. This includes the computer components, connection wires, power strip, printer, paper, extra printer cartridges, and an extension cord. Also make sure that you have administrative privileges on your computer, especially if the contest you go to requires using a network submission process which may require changing some internal settings.
- When you arrive, there will be a registration and setup process, and the first thing to do is to find your assigned team location and get set up. The most important thing is to get up and running, making sure all systems are go. This includes the computer working, able to print, and able to type in, compile, and execute a program. Have some simple problems ready for your team to practice on while they are waiting for the contest to begin.
- Do your best to instill a serious mind set with your students. They will see other team members perhaps sitting around and playing games on their systems while they wait. Discourage this. Remind them that they are there to compete, and that this is not play time. Afterwards perhaps you can reward their efforts with some fun, like a mall crawl, or a game of miniature golf somewhere on the way home. This will go a long way to building camaraderie and team spirit, and make them look forward to the next time.
Before the contest begins, instructions are usually given by the contest leader, and then the packet is distributed. When the contest begins, here is a list of suggestions for what the team might do to have a successful effort:
- Appoint a team captain whom the other two respect, and who can command authority. This person will make the hard decisions throughout the contest time, and the other two must be willing to follow those decisions, whether or not they agree. This includes making someone get off the keyboard when it is time, including him or herself! This requires some serious self-discipline!
- Have one designated person be the keyboard starter. As soon as the contest begins, that person types in a basic program shell as quickly as possible. Some contests may allow you to keep the practice problem open as the beginning shell, but others may not and require the team to start from scratch.
- The other team members rip open the packet and find an easy problem, hand it to the keyboard starter, who will then solve it and type it in.
- The other team members then look at and do a quick analysis of EVERY SINGLE PROBLEM in the packet BEFORE starting to work. This will avoid the possibility of overlooking an easy problem buried towards the back of the packet.
- Establish some kind of priority order for working through the problem set. This might include dividing the packet into three stacks, one for each person, based on the strengths and abilities of that person. Another way would be to find the easiest problems and put them on top, and the harder ones on the bottom.
- Establish a time limit for each person to stay on the keyboard. Each team member must agree to this, and stick with it. It could be a set number of minutes, like 10 or 15, or it could be when one of the other team members has a solution ready to type in. When the call to “switch” comes, the person on the keyboard MUST print out their current source code, along with any output they may have, and then continue working on the problem offline, or start on another one.
- Remember to use the keyboard as efficiently as possible. Aside from basic syntax debugging, caused by missing semicolons or other common compile time errors, DO NOT DEBUG FROM THE KEYBOARD! If the logic of the solution is just not working, print out, get off, and debug offline from the printouts.
- Every team member must pledge to “give up” on a problem if it is just not working. This is hard to do, but is essential to using the time wisely. Set it aside and find another problem to work on, and if there is time, come back to the other one later on.
Building a successful contest team takes time, effort, and funding. You need the support from your administration to pay for the travel and registration fees required to attend practice contests. You may even have to do some fund-raising at your school or in your local community to generate funds.
It also takes a huge commitment from you, recruiting students, convincing them to practice, providing materials and coaching, dealing with team personality issues, giving up personal time on the weekends, the list goes on and on. The good news is that once you have established a winning program, the students will start to assume some of these roles, and eventually you almost have a self-perpetuating contest machine.
Finally, keep things in perspective. The idea behind competition is to help the students develop and sharpen their skills, not just to win contests. Sure, trophies and medals are nice, but are NOT the main goal. Accolades are temporary. What the students learn is what will last. Make the whole experience a good one for your students, one they will look back on with pride and fond memories.
As always, thanks for all you do for your students, and for our future technology leaders!
About Ask John
As he always emphasizes in his classes, courses, and workshops, there is no such thing as a silly question, except for the one you do not ask. John Owen has taught high school Computer Science very successfully for many years, and has a team of CS colleagues who are ready and willing to lend their expertise, experience, and wisdom to help you become a better computer science teacher. This blog is for you! Ask your questions, and he will do his best to give you sound advice that will get you back on track with whatever issues you encounter, and for which you seek answers.
Have a Question?
CS Teachers are encouraged to submit their questions about teaching CS or other aspects of CS education. Send your question to firstname.lastname@example.org and we’ll be sure to let you know if your question is featured in the Ask John column of the WeTeach_CS Blog.