Solving a problem

#problemsolvingskills are not a natural skill for many. I have really enjoyed sharing my insight into a few problems recently. The last one was a long read, so I thought I would tackle a #leetcode problem as it may be more suited to, and useful for, my network.

I have barely been on leetcode before. I have, however, racked up a pretty good ranking on #codewars. Many of my peers say that leetcode is where they are sent for technical tests during the interview process, so I thought I should give it a go.

I am tackling "Filter Elements from Array", a #javascript based problem: https://leetcode.com/problems/filter-elements-from-array/

Assess the problem statement

First off, I will assess the problem. As always, I will spend time picking out the requirements of the task. By doing this, I ensure I am solving what is being asked rather than diving into some code that solves an entirely different problem.

I will be given:

• an array | arr | it doesn't indicate what is contained in the array
• a function | fn | the function can take one or two args

I must:

• return a filtered array | filteredArr | only contains elements that, when run through fn, evaluate to true
• not use the built-in Array.filter method...that's a shame, I like the built-in array methods, but I must stick to the rules! (plus, using .filter() seems like it would make this far too easy)

My thoughts on some examples: if fn checks if a value is even, filteredArr should contain only and all the even values; if fn checks if a value is a string and only on even index values, filterArr should contain only the string values that are positioned in the original array at an even index.

The returned array contains the original elements that have evaluated fn to truthy when passed in.

Checking the interpretation

Next, I take time to check that my understanding of the problem aligns with the examples provided. My understanding appears to be correct (although, probably poorly worded...sorry!). Remember, this is checking for anything that returns a truthy value from the function, not the value it would return. Spend time to read the question again if you are stuck. If you don't understand the given examples, it is unlikely you will solve the correct problem!

Before coding

Some starter code is provided. I write a couple of comments within there to explain to myself the steps I need to take. I hold my hands up here, I do skip this step on the problems that I am more confident with. I have solved a lot of these types of things considering my time in the industry but, when I get stuck on something, this is what I come back to. Mild spoilers coming up...

My comments:

• // result is an array
• // check each element in given array
• // check if element returns truthy value when run through given function
• // if it does, add it to the array
• // return the array

I avoid the word "and" in a comment, I don't have any code above, just a couple of logical steps. "if" is a word used in everyday language, that's fine. You can also stretch to "for...of" (or in) which may be preferable in my second comment. Anything more code oriented than that and you are in danger of code-blinding yourself. Keep your options open and focus on the requirement of each step.

Comments to code

Now I transform that into code. I won't show you all the code for this bit, I don't want to give it away completely! But what I will say is that every comment becomes a line of code, sometimes more. If I realise I need to expand it further, I do so with additional comments first.

Let's tackle the first comment:

// result is an array

That's pretty simple to translate into code:

const result = [];

Yep, I use const. The array is defined in the problem statement as the type that needs to be returned. You can modify the contents of an array without needing to redefine the array itself. Think of it as a cardboard box; things can go in and out of the box, but the box itself remains the same (albeit, a little flexible in size).

Check as you go

It is also sensible to check your steps as you go. Many of these platforms have a console, so use it!

const result = [];

console.log(result);

Okay, this is pretty basic. However, it is a really good habit to get into. Prove what you think you know! How many times do you think you are working with a number only to find it is a string? This is a really good thing to practise and don't be afraid to check the type of your object, although you should definitely research some of the oddities of JavaScript before relying on this. In this instance, the typeof() method will return "object"! For an array, you could use Array.isArray(result), assuming your array is assigned to a variable called result.

Don't forget this step. If something doesn't work as you expected, you should work from a stage where you know what is happening. Even then, you should prove it once again to save yourself the frustration of finding something that isn't quite as you thought it was.

Unsure how to proceed

If you come across a comment that you cannot determine how to code, search the web! #stackoverflow is a great resource, but make sure you understand what you are using from it; don't just copy a response and hope it will work (please!!). I love the #mozilla webdocs at MDN, it's pretty much my go-to guide (for JavaScript, HTML and CSS).

Whatever happens, don't give up. If you do, you certainly will not succeed. If you persevere, even if you fail to complete a challenge in time for an #interview, you will learn by continuing through the problems you encounter and by asking the right questions you should further your knowledge.

If you followed the rules of writing comments rather than code, you can delete your code and return to your comment. Shake that fixation that you are using the best method and try and approach it from another angle. There are many ways to achieve the same goal in most languages; I wrote the solution to this problem 4 different ways just to prove to myself that I can. Did I submit all of them, no way! Did I learn from refactoring my code, most definitely!!!

Don't play golf!

Code golf is great fun. I love to write short solutions, not quite to the standard that the experts can do, but to prove to myself that my understanding is coming along nicely. I do not, however, think that these types of solutions are the most suitable for production code. Sometimes, depending on the situation, they might be. A well-written docstring may explain a complex-looking function if you know it is only ever going to be you that works on it, but how often is that really the case?

Summary

Solving problems like this can be great fun. It can also be a complete headache. I have spoken to many people about this sort of thing and I find the ones who do the best at it are those who are not afraid to stop and think. Sure, you might open the problem I have shared and solve it in 90 seconds. If you do, great, now go and find yourself a more challenging problem.

You won't learn by getting things right all the time. You learn by pushing yourself to the boundaries of your comfort zone and beyond. If you keep at it, you will improve! Who knows, you might even start to enjoy them like I do.

Good luck, and keep on developing your development skills!