9 Tips That Helped Me Clear All HackerRank SQL Challenges in 2 Weeks | by Michael Li | Towards Data Science

Current projects at work require more SQL skills, so I took the time to brush up my SQL knowledge using the HackerRank coding challenges platform. It took me a bit more than two weeks (on and off between work, workout, and taking the kid to day school, etc.) to finish all the 58 SQL challenges on the site, and I gained quite some insights from the journey (and having quite some fun doing that!). This article could be read by anyone who wants to get into the data science world or prepare for your next SQL interview using a coding site like HackerRank or LeetCode, Even if you still don’t have any prior SQL knowledge. I did put a bit of code in there to show you straightforward examples. Most of the tips are about making full use of these SQL challenges so you can benefit the most from them, rather than teaching you how to crack the problems. So don’t worry if you don’t know squash about SQL or coding. Please sit down, relax, and let’s do this.
SQL is boring in that it does not boast clever algorithms or complicated data structures. There is nothing to brag about. It requires more rigid planning and step-by-step execution to close the gap between your tables and the final results. Yet, it is essential to every data analysis/data science professionals. It is how we get access to our gold mine🪙 (data). Today, people do most of their data exploration and manipulations using more powerful languages/modules or tools like Python/Pandas or Tableau. Yet, we still cannot live without SQL since we need to get the data out of those ‘dusted’ relational databases first.
SQL can be less boring, of course, when you are doing challenging coding problems on sites like HackerRank or LeetCode. Approaching it the right way, everyone with basic SQL knowledge could have some fun doing SQL coding challenges and upgrade their SQL skills while doing so. That’s what I will be talking about in the following sessions.
Obviously, you need to have some fundamental SQL knowledge to start the challenges, though you’ll learn much more along the way. Learning basic SQL is relatively easy these days since we have tons of resources online to help you out. Two good sources I used:
Mode: The SQL Tutorial for Data Analysis: It is very well-paced, from basic to advanced topics. It also comes with an online SQL environment that you can try in real-time with the databases already used in the tutorial — no need to resort to sqlfiddle, etc.
SQLZoo: In my opinion, more new learner-friendly. It holds your hands along the way from the most simple clauses like SELECT to the more complicated JOINS. If you’ve never learned SQL, you’ll feel more comfortable here. Facebook recruiters also recommend it.
Once you feel that you have gotten the hang of most commands, you can tackle the challenges. There is no need to over-study your basics. Doing all these challenges is a good way of practicing what you learned and learning new tricks along the way.
Looking at your data and taking notes along the way is halfway to solving the problem. Better yet, visualize your data in your mind or using a whiteboard (physical or digital) helps to put the query together. Our human thinks more efficiently when doing it visually. So whiteboard away, draw your tables, put in some sample data, and maybe draw lines to show relations. Some challenges are pretty complicated, and you have to put all pieces together in one big picture, either on a whiteboard or in your mind, to find the way out. It’s easier to do it on a whiteboard (unless you are Nikola Tesla, then you can solve problems using simply your brain).🤔
Another tip is to make good use of many small, thrown-away utility queries to gain familiarity with the data. Queries that won’t directly build data toward the end result, instead show you how your data looks, uncover valuable insights, and give you instant feedback on your ideas. You can start from: SELECT * FROM table LIMIT 10; to see how your table looks, then try aggregating on different columns and seeing if you can gain some insights.
SELECT *, COUNT(*) FROM table GROUP BY column;
Maybe organize data in a better way and put them in another intermediate table (CTE) to be used later.
WITH temp_table as ( SELECT xxx...)SELECT * FROM temp_table
The above code snippets are simple examples of what I meant by ‘thrown-away’ utility queries. Obviously, you can do much more, depending on what problems you are solving. This way of problem-solving is also used widely in real Data Scientist jobs and has a name: Exploratory Data Analysis. Why not start doing it now?
I can’t remember how many times I got stuck, wondering why my perfect code won’t work or why the problem just cannot be solved, and then find out I misread the question itself 😜. It was stupid, but you’ll be surprised how easy to fall for it when you’re in a rush of solving all your challenges within a short period (like when you are doing a certification test or in an interview).
So take it slow when reading the question. Don’t skip through seemingly minor statements. A well-designed challenge usually hides important clues in plain text, and carefully reading the question will uncover them. Get a firm understanding of the schemas, table relationships, and what the question is asking. The time you spent here will be compensated dearly later by avoiding horrible, stupid mistakes.
Sometimes slow is fast.
Once you have gained your basic SQL skills, understand the question clearly, and know your data in and out, now is the time to start your attack to the challenge by formulating a plan first. I can’t stress enough how important this is. If you only remember one tip from this article, remember this one, make a plan. It’s because the nature of a SQL challenge is complicated data manipulation and usually takes multiple aggregation/layers of abstraction to solve it. Thinking at a certain level of abstracting by planning things out makes it cognitively possible and prevents us from delving too deep to recall the big picture.
The usual way of thinking I use is to think out loud like this: The question is asking for data point A and B, I can get to A by aggregating these 3 columns, get to B by using window functions to print out an ordered list of column C. OK, so for A, we need to create the columns from scratch, which I’ll use inner join to put together. For B, the window function need to be partitioned by column D and ordered by column E, ....
You see, I start from the top level and gradually work my way down, all the way to the specific clause I pick. Talking it out allows it to be heard by myself and reinforces my memory of the problem and plan, thus help me think through it. Another benefit is: In an actual SQL interview, the recruiters usually expect you to think out loud, so they will know better your thinking process. Most of the time, showcasing the thought process when working on the problem is as important as solving it, if not more so. If you practice this through all the challenges, you’ll get very comfortable(and even a bit excited) doing it. Being comfortable with talking out loud will make you feel and look more confident to the interviewers.
Peeking the answer is nothing to be ashamed of when you are learning. Your goal is to practice your skills, not trying to pass a certification test. Sometimes you’ll find yourself stuck with one challenge for too long. Don’t overspend your time trying to tackle it. Instead, use the 15- minute rule:
“Take 15 minutes to solve the problem any way you can. However, if you don’t have an answer after 15 minutes, you must ask someone.”
One reason to apply the 15-minute-rule here is that you are still learning. And sometimes, a challenge will need to use some techniques or clauses that you don’t know yet. Like people say: You don’t know what you don’t know. Spending more time on it won’t help. Another reason is that problem solving sometimes needs you to step back, see the bigger picture again, and figure out whether you’re in a hole and need to get out and change course.
Developing your ability to switch abstraction levels freely will significantly help your coding/data analysis career.
After you get the hint from the Discussion Board and completed the challenge, stop a while and think about why you missed it in the first place? Any missing part in your knowledge? Blind spots of your thinking/approach? Again, take it slow here. You are learning. The contemplation time is when you will learn the MOST from these challenges by figuring out the weak spots in your knowledge and improve it accordingly.
Most algorithm/data structure coding challenges tend to be a bit ‘tricky,’ and rightfully so. Yet, for SQL, the problem to be solved in real life is more about simplifying complicated relationships than coming up with clever solutions to math problems. Overall, I find HackerRank’s SQL challenges to follow the real-world challenges mostly. However, occasionally you will still encounter problems that can be hard to find in real life, like the (in)famous challenge of Print Prime Numbers. It feels like someone put a Python coding challenge into a SQL form and forcing you to solve it. I might be biased here but ignore those kinds of challenges. You might as well do it in Python. Using SQL for what it is not designed to will help nothing except intelligent fun. Most of us don’t come to a site like HackerRank or LeetCode for that, do we?
Once you have cracked the challenge, resist the temptation to hit the juicy ‘Next Challenge’ button! I highly suggest you to reflect on your problem-solving process, ask high-quality questions to yourself:
What clauses did I use? Why did they work? Why did some of them not work? Any better alternatives? How did I approach the problem? How did I break it into smaller sub-problems? What intermediate data did I aggregate to get to the final results?
I know, sometimes in the excitement of having tackled a complex challenge, it’s hard to slow down and contemplate these tough questions, and it seems to slow us down, but trust me, this is the FASTER way to learn.
I’d say some of the ‘hard’ challenges could be pretty tricky. In that, you need to figure out some clever ways to put the data required together. I used to use 8 CTEs, two window functions, and multiple joins to get what I wanted. But the certification tests are more reasonable and closer to real-world problems. My experience is that the certification test requires more careful question reading, schema dissecting, and maybe white-boarding your tables than coming up with novel pivoting techniques. So even if you are stuck with some challenges, don’t let them discourage you! When you feel ready, take the certification test, you might still steam roller through it!
Now onto the coding part. I’ll list what I think helped me below:
An easy way to understand subquery and CTE(Common Table Expression) is to think of it as a function in other programming languages. If you use it in more than one place, why not put it into a function? Whereas subquery is like a lambda function, you write it on the go and throw it away after using it. They help make your code more readable and conceptually easier to digest, which has great value in solving complicated SQL challenges.
Aggregation is the primary way to distill raw data into something more meaningful, closer to what the question asks. GROUP BY helps to condense the data with SUM(), COUNT(), MIN/MAX(), or AVG(), whereas window functions do the aggregation function in the item level (Best for tackling ‘Top N’ kind of problems). Sometimes you’ll need many levels/steps of aggregations to get to where you want. Again, look at your data and challenge question, and carefully design your ‘aggregation map.’
JOIN vs. LEFT JOIN: Honestly, these two are the main JOINs you’ll ever need. Use JOIN when you want to return only rows having pairs on both tables, and use LEFT JOIN when you need all rows from the “left” table, no matter if they have pairs in the “right” table or not.
Order to write the query: The most natural way is to write the query as to how they execute: FROM > WHERE > GROUP BY > HAVING > SELECT > ORDER BY > LIMIT. Resist the urge to start from SELECT. Think like what the machine is thinking.
Work from both ends, your tables, and what the question asks to solve the problem. From the data/tables side: Ask yourself what it can build with the tables? What aggregation could further distill the data? From the end-result side: What data is required? What kind of table will help solve the problem? Imagine some middle-level tables that can help bridge the gap. Try to work on both sides and meet at the middle point. Again, think at different abstraction levels helps a lot.
Do your SQL Certification Test (both Basic and Intermediate) on HackerRank if you cracked all the challenges. You can do it!
SQL challenges are a bit different than their regular algorithm/data structure counterparts. It requires you to think in a more organized way, structure your code, and switch among different abstraction levels. Master these ‘slow’ skills, you will likely find yourself steam-rolling through the challenges much faster than you think, and most importantly, it will have you well prepared for that critical SQL interview!
I hope you find this article enjoyable to read and learned a thing or two from it. If you want to know more about what I think, practice, and write about data science, consider signing up to become a Medium member. It’s $5 a month, giving you unlimited access to stories on Medium. If you sign up using my link, I’ll earn a small commission.