As a junior developer, One of the pieces of advice I often read about how to improve my skills is to solve coding challenges. I started doing this about a week ago and at the beginning of this week, I decided to start picking questions that are above my current level. I have solved 1 and then yesterday I picked the next one. Believe me when I say, from yesterday up until this moment, I haven't written a single line of code because I have absolutely no idea on how to solve the problem. I am not a maths genius, but at least I know how to solve my basic maths problems, but the question is about Fibonacci😱and the help resources link to even a more confusing concept that I just heard about. Golden Ratio 😓.
I could just google the solution, but I feel like I won't be learning anything then. I could also just skip the question, but what if I face the same challenge with the next question and I press the skip button again, then I won't be improving myself since I will only be working on problems I can solve.
What do you do when you are faced with this kind of problem?
What's the best approach to make sure I keep learning?
I'd really appreciate any advice that will help🙏
Top comments (10)
My teachers told me not to start writing code unless enough paper work is done.
I still remember early days of my career when my team lead asked me to create a structure for our project's data access layer. I asked questions, a-lot of questions ... there were too many whats, too many whys and too many hows ... The good thing is that one of the solutions that I proposed that day is still working without any issues in production.
Never mind if you don't code for a while, but be sure what you code is worth it!
Thanks Aqeel, really appreciate your this.
Welcome ...
I did competitive programming in college, so I can explain how to break down the problem. But, I'd need to see the specific problem to explain how I approach it.
Generally, there's a few main "tricks" (or patterns) for solving programming problems, and the main task is recognizing which one is needed for the problem.
I would also say that a lot of competitive-programming style problems are not generally useful for the real world. In the last year at my job, the most complicated algorithm my team has used has probably mean... merging two sorted lists. And, if you didn't know how to do that before, you could just Google it, and spend a few days understanding, since the real world doesn't really require you to have too many algorithms memorized in your heart.
Thanks Curtis. Here is a link to the problem codewars.com/kata/5541f58a944b85ce...
First, the problem defines the Fibonacci numbers, though very poorly. (There are lots of questions about the Fibonacci numbers on Codewars, so they are probably assuming you have seen it before).
Each term in the Fibonacci sequence is the sum of the previous two:
This can be written in the mathematical notation,
F(0) = 0,F(1) = 1,F(n) = F(n-2) + F(n-1), which is also included in the problem.So this is task (1): come up with code to compute the Fibonacci numbers. You want to be able to go from an
nto anF(n). That means either writing a functionFwhich when called withnreturns then-th Fibonacci number, or filling an arrayFwith the Fibonacci numbers, where thenth index has thenth Fibonacci number.Next, the problem says you need to be able to take a
prod, and find annsuch thatF(n) * F(n + 1) = prod. This is task (2). If you think about this, it doesn't actually depend on the Fibonacci numbers at all -- it works on any sequence. So you can solve and test just this part of the problem using something simpler, maybe just the counting number1, 2, 3, 4, ...or the squares1, 2, 4, 9, 16, ..., or the odd numbers1, 3, 5, ...etc.Finally, you need to plug these two things together, which is task (3) and the simplest task.
The note at the bottom about the golden ratio is just a "hint", but it's not actually a useful hint. I would ignore it.
If at all possible, I do something else, at least for a while. I'll usually be having a shower the next day and realise I could take a completely different approach!
Wow, Thanks so much Ben
When I come to a problem where I need to create an algorithm and it is not immediately obvious how to do it, I will write out on paper examples of how I would solve the problem without code. I have spent a lot of paper with some problems!
For example, if I wanted to understand how I could implement quick sort, I would write a list of numbers:
Then I'd write out each step, splitting the list into smaller lists
And so on
Writing out all the steps until I get the sorted list.
Then I go back a write down (in human language) all the things I did to get from the input to the output.
e.g.
That list of things is my algorithm.
Then comes the challenge of translating the algorithm into actual code, but it should be clear from the list what to do. If any step is unclear, you might have to break it down into its own algorithm.
I like to oppose the argument of "think first - write then" - considering the environment. Of course in real tasks you should never start code without a concept. But these coding challenges places are great for such a concept-less trial-and-error approach.
Sometimes it requires you to fiddle around and try - read - try - read - (and read even more) until you get to some point where the shining light bulb pops up above your head.
Instead of overthinking you should make codewars your playground.