Tips on How to Approach Coding Challenges

Have you ever felt overwhelmed looking at a coding problem or challenge? Have you spent too much time writing the same line of code and hoping that this time it will work? Or are you on the opposite end of the spectrum, planning until it’s time for dinner, and aw shucks!, now you don’t have time to attempt the problem? This post will give some practical advice on how to avoid both of these (terrible) outcomes. Trust me, I know a thing or two about not leaving your comfort zone and/or trying an incorrect solution until your battery runs out.

Many challenges and projects can be daunting at first. How can I solve a challenge where I don’t even know what some of the words in the question mean? How can I teach myself web scraping if I don’t even know what HTML is? The list goes on and on. Here are some things I’ve learned over my albeit short programming experience that made these problems far less scary and really helped me improve:

· Understand the question fully (or, take a deep breath)

This may seem silly, but you would be surprised how often this is overlooked. Many people rush into a problem with only a slight grasp of what the goal is in the first place. Knowing exactly what the question is saying can save a ton of effort in the long run. After all, what’s more frustrating, spending 30 extra seconds to understand the problem or spending 10 minutes solving the wrong problem?

Further, reflecting on the problem (viz: deep breath) can also do wonders. Going so far as verbally asking the screen/page for clarification can make the problem quiver in fear, too, which also helps. Knowing exactly what’s expected of you and not rushing into the problem can do wonders for your coding. It’s like the advice every outfielder if given: take a step back when there’s a fly ball, no matter how sure you are that the ball is going to land right where you’re standing. If you’re right, slightly less effort. Whoo! If you’re wrong, you’re an embarrassment that can’t even catch a simple fly ball. Boo! My advice: add a little extra effort so that you always catch the easy ones.

· Make a general plan

In my opinion, this is the most important thing you can do. Let me repeat: MAKING A GENERAL PLAN OF ATTACK IS THE MOST IMPORTANT THING YOU CAN DO AS A PROGRAMMER. I can not stress enough how much time and effort this will save you. Having these goalposts while you are writing your code will make it much easier to take the easiest intermediate steps to reaching your goal. To illustrate, here’s a paraphrase of a problem that competitive programmer Errichto was once given: you are given the individual scores of a tennis match in a series of lists and are asked to compute the winner of the match. For example, the first list may be [1, 0, 1, 1, 1], which means that player 1 won the set in had 4 points to their opponents one, thereby winning the game. Take a second to consider how you would go about solving this problem. When you’re ready scroll past the sad-because-you-planned-poorly puppy.

Distraction puppy.

For me, my first thought was to compute each game, find the winner of each set, and then use that to see who won the match. Difficult, but definitely doable. There is a MUCH easier way, though. Can you see what it is?

The answer is to look at who scored the last point *facepalm*. Duh! The person with the last point always wins, no matter what sport they’re playing.

Sometimes the simple solution is the best solution.

· Fill in the blanks

Going along with the previous tip, once you broke your proposed solution down into discrete parts, it’s easy to solve each problem individually. Ten simple problems are much easier to solve than one massive problem. It’s always easier to fill in the ____s than to solve everything at ___ (see bottom for solution).

· Debug one thing at a time

Your code won’t work your first time through. This is a fact of life. Just like the fact that dogs are better pets than cats. (Please direct all hate mail to itsjustaprankbro@gubboi.com). So the only thing you can control is how you deal with things that you expected to work, not working. The easiest case is a typo that your know-it-all interpreter will hopefully alert you to in plain(-ish) English. Other than that, your problem solving skills will really come in handy. It’s best to change one thing at a time until you get some leads on what the fundamental issue is. In other words, the goal is to rewrite the fewest lines of code as possible. If you re-write the entire code from scratch when there’s an issue, you’re probably debugging the wrong way. If none of the above, you can always explain your code to the most important person to any programmer: your rubber duck.

So there are a lot of tips here. How should you proceed with this information? My recommendation is to try implementing one of these ideas in your next coding session. Did you notice any difference in the quality of your code? Were you able to solve more problems? Did it take more time than usual? Heck, you can even make a data science project out it and do an analysis later (full disclosure: I’m in a data science bootcamp at the time of writing).

No matter what ideas you try, always remember to tailor it to your needs. Are you happy with taking risks and making mistakes? Code away and change your plan on the fly! Do you only like typing when your sure of yourself? Write out your general plan of attack with a pencil and write dummy code on paper. For lots of people, seeing your ideas and physically writing them out makes all the difference. Neither extreme on the planning/personality spectrum is correct so feel free to find your happy medium (pun intended).

Happy coding!

P.S.: More specific points about strategies of successful programmers in general can be found in this excellent PyCon talk by Raymond Hettinger. Check it out!

P.P.S.: Although not mentioned in this post, pair programming can be successful precisely because two extremely different personalities can balance each other out. This idea practically saved Google in its early days.

Answer Key to blanks: blank(s), once

Data Analyst | Data Engineer — Interests in language, sports, marketing and geographic visualizations