Back-end Engineering Articles

I write and talk about backend stuff like Ruby, Ruby On Rails, Databases, Testing, Architecture / Infrastructure / System Design, Cloud, DevOps, Backgroud Jobs, and more...

Twitter:
@daniel_moralesp

2019-07-19

Framework to Solve Coding Challenges with Ruby

Now we have a lot of knowledge to put into practice. So far, we've seen these articles about Ruby and Data Structures. 

Articles about Ruby


Articles about Data Structures


It's essential to have the basics of Ruby and Data Structures before doing coding challenges because it can be tricky if you don't do that. All the articles listed are in order, which is crucial if you don't know where to start or what's steps to follow to have all of these concepts.

How to solve coding challenges

One of the first reactions when you're trying to solve coding challenges, is to go directly to the code. However, that strategy can be complex because if you don't have the problem evident in your mind, you'll be trying to solve it blindly, and it will become tough to solve the given challenge. 

So I have a list of steps (that works as a framework) to solve coding challenges, and you should follow it if you want to ace and approach the coding challenges the right way.

Step #1- Use an online stopwatch

Use an online stopwatch, not as a way to pressure yourself but to measure the time it takes you to solve the problem. This could be the best measure of your enhancement over the weeks because you'll see that you can solve problems in less time. Or suddenly, you can solve more complex issues in the same amount of time. 

I know that using a stopwatch can be a source of anxiety, stress, or pressure. But this is not the goal here. The goal is for you to know yourself. For example: if the first problem takes you 2 hours to go through the whole process, that's ok. You are competing with yourself. There are more significant and complex problems to solve; sometimes, it will take you 3 hours, or you don't have any solution. Stopwatch helps you to develop your brain muscles and self-discipline. That's the real goal. 

You just need to type "stopwatch" in Google to find it. When should you start the stopwatch counting? Right before you start reading the problem. You should measure your entire process of solving coding challenges: from reading to solving the problem. 

Step #2- Read the problem carefully

Reading comprehension is an excellent skill to have here. However, you also need to know about the basics of Ruby and the data structures because once you start reading, you can start thinking about the different ways to solve the challenge. Try to find hidden keywords in the problem because there could be signals to start and finish the solution.

Step #3- Never try to see the result until you try it yourself. 

This is one of the most critical steps. You have to keep yourself away from the solution. You should not cheat here. It's for your own benefit as a developer. I know the temptation is high, but it is actually more fun and addictive if you try to solve it yourself and compare your results with the official solution. Just believe me!

You'll learn the double if you try to do it yourself and then study the official solution. Actually, you'll have at least 2 different points of view about the coding challenge, and you'll be better prepared to solve almost any problem. 

Another benefit here is to pay more attention to the official solution. When you try just to copy and paste, you're on automatic mode, not in a deep work mode to solve problems. 

Step #4- What's the expected output from the challenge? 

Generally speaking, when you're reading the problem, you should find examples of the expected output at the end of the description. 

This output is critical because you could find different gotchas in the result. For instance, a problem expects to return an array of characters between A to Z. Still, it can also expect to respond just in lowercase, so if you also allow the return of uppercase letters, you could fail the challenge. 

So, pay careful attention to these examples.

Step 5- Did I solve a similar problem before? How?

Suppose you start solving challenges, and after 5-10 solutions, you'll be collecting a lot of different ways to solve that challenges, and you could end up solving quite similar issues later. So it's a good idea to start having your own cheat sheet or documentation about the problems you've solved in the past.

It also is imperative to remember how you solve it because you can apply that knowledge to the current challenge with that same logic. Also, it is not a matter of copy and pasting in this case. You're re-using code, but you already know what that code does. That's quite different. 

Step #6- Start your own documentation or cheatsheet

As we mentioned in previous steps, you should start your own documentation or cheatsheet from the beginning. However, don't trust your mind. It can be forgotten. 

You can start your documentation with the basics of the data structures and then start writing down the different algorithms you use to solve the problems. You don't need to share that cheatsheet with anybody; you can keep it just for yourself. Your future self will be pleased with your present self. 

Step #7- Solve the problem first on paper or a whiteboard

Many people tend to avoid the usage of sheets of paper or whiteboards. Probably the whiteboard is far from you, or you just want to start writing code. Take your time. You're not in a competition where you have to solve the challenge faster than others. You need your own time to solve the challenge; it doesn't matter your level. 

Once you have the paper or whiteboard, subdivide it as follows:

1. Make 15% of the total space to write the expected output of the code. We saw this in step #4
2. Make another 15% of the total space to write the following steps. This is very important to have your mind organized until coding the solution. 
3. Use the other 70% of the space to write the solution. Try to complete the whole solution here before coding. 

Look at my whiteboard. It's not a real coding challenge, but it is more or less that you have to divide the whiteboard and have the right amount of space to draw your thoughts. 



When you start dealing with coding challenges, that space can be enough. But later, you'll see yourself doing the following things.

  • * You don't have enough space to write the whole solution. Just take a sheet of paper and continue there
  • * Sometimes, you don't have a clear code output in your mind. So here, it is allowed for you to start using a tool like IRB to test the result rapidly or even use the text editor if the solution is really complicated. But at least you have an idea about where to start now. 

Step #8 - Start using the Ruby Interactive Console (IRB) or the text editor

This is the moment to start using the IRB or the text editor to write down your solution. Now you have an excellent idea about the problem. If not, at least you have been studying the description more in detail and trying to figure out a possible solution. That's something. Once you feel ready to start testing your assumptions about the possible answers, it is time to open the console or the text editor.

Remember that the console helps you to test any problem rapidly. Still, if you think the situation will take a couple of lines of code, it is probably better to create the entire solution in the text editor and then execute it in the console. 

One of the things you should start doing is printing statements with the command "puts" to see what you're returning on each step of the solution and try to catch any errors or insights about your answer and about the problem itself.

Step #9 - Solve it first via "brute force" 

In the beginning, your solution could not seem pretty professional or advanced. So you should not worry about it at this point. What you need now is to solve it and reach the expected results. In step number fourth, we've been talking about the results expected by the solution, so once you have the code ready or want to start printing things, it is better to start using brute force in the solution. Later, when we see the first examples, we'll be seeing what brute force is in detail. 

Once you have the solution and understand the problem, it might be good to refactor and do a better solution with less code or a better performance algorithm.

Test all types of situations once you think you've solved the problem. This tactic can open your mind to other possible solutions. Remember that each challenge has at least 2-3 different ways to solve it. 

Step #10- Review the time & space complexity 

You have the solution ready; that's awesome! Now it's time to review the time and space complexity and comment on what you think it is. For instance, if you believe the time is O(n) and space is O(log(n)), just put that in comments inside your solution and try to explain to yourself why it is. It's a fantastic exercise to start testing your knowledge about time and space complexity.

If you don't know your solution's time or space complexity, please refer and re-study (our past blog posts) the subject a little bit, or even go to the internet and figure out the proper notation for your case. 

I'm pretty sure that with these 10 steps, you can start solving coding challenges in a more structured and organized way. This is really good for you because you don't have to struggle, as I worked in the past, trying to figure out the best strategy to solve coding challenges. Obviously, we're not talking about solving the algorithms themselves, but this is an excellent framework to ace and approach the solutions. It doesn't matter the complexity. 

Later, we'll have coding challenges to solve to practice this framework. 

I hope you learned a lot.

Thanks for reading
Daniel Morales