JavaScript Interview Questions RealToughCandy

JavaScript interview questions: 4-step guide to solving every challenge (with examples)

This article was adapted from my video:


My early career as a self-taught software developer can be defined by three distinct traits: 

1. Absorbing and practicing everything I could, wherever I could, whenever I could, in order to understand my craft;

2. Feeling consistent urges to gouge my eyes out and go back to working at the United States Postal Service whenever a missing semicolon would break my program for six hours or more;

3. Suddenly receiving 6-10 daily coupon deals from local chain pizzerias once I started learning PHP and didn’t have the physical or mental fortitude to make dinner myself.

The first six to twelve months of learning software development on your own are difficult.

Not only are you stuffing your brain to the point where it feels like it’s about to literally explode, you’re also perhaps competing with naggingly negative thoughts about your competency. Nothing quite destroys confidence quicker than failing a so-called simple coding challenge, or having a hard time reading JavaScript examples from the Mozilla docs

Going from Level 0 to Level 1 in this industry takes time, patience, and failing. Lots of failing. Leveling up here is more difficult than any other level. It’s also where most people who are trying to become developers not only quit — but stay quit. 

If you feel like you’re at that level 0 and are ready to take a step forward, today I’m going to help you by showing a four-step process to assist you in solving any single JavaScript interview question. However, this technique isn’t limited to the interview room or even JavaScript itself: Whether you’re doing coding challenges on places like Code Wars, figuring out a feature for one of your personal or portfolio projects — wherever you need a solid method to solve a coding problem, this technique works.

Step 1: Define the question in human language.

Write down the problem you’re being asked to solve. If you take a closer look, these are structured just like high school algebra word problems. And that’s comforting because we know there is definitely a solution!

Here’s an example of something you might write down if a personal gave you this scenario aurally:

A kid’s fruit counting game needs functionality. I need this program to add the number of fruits the user provided at any one time and display that number. If the number is not provided, give a message that tells him no fruit have been added yet.

Right away I can already put my high school algebra education to use, because I see a special word: is. In math word problems, is translates to = (equals).

So, even though I might not have any great insight yet on how to exactly solve this problem, I can already see that there is an instantaneous translation into something that’s one small – but illuminating – step closer to our solution. This keeps me optimistic.

Now I’m going to segment each issue as its own “problem block” to help my brain better organize it:

A kid’s fruit counting game needs functionality.

I need this program to add the number of fruits the user provided at any one time and display that number.

If the number = not provided, give a message that tells him no fruit have been added yet. 

I know it seems small, but it can be a confidence booster, reminding you that the translation to a computer-readable solution is already in play. I also put each requirement (condition) on its own line to help my brain segment the problem into more manageable bits. Note that there are a few other places where you can add simple math operators to help you process the problem from a new perspective (like “+” to replace “add”)

This process of putting your problem into a descriptive word problem and adding simple, human-readable math symbols in places ( +, -, /, *, =) naturally oozes into step 2: Iterate and Translate.

Step 2: Iterate and Translate

Like any other programming task, you’ll find yourself going over and over and over the same problem: reading it, absorbing it, assessing it, repeat. Each time you do this, your brain hurts just a little more. That’s the feeling of pure thinking, my fellow developer, so you’re on the right track. This cycle is called an iteration.

It’s time to start translating this problem while you’re iterating. Don’t let all that brain energy go to waste just by looping through this problem in your head and not getting anywhere – take action! For each iteration, let your human language problem start morphing into a programming language solution. This is the digital equivalent of the pupa phase: not quite fully matured into a real programming language, but getting there. 

The term for this morphed language is called pseudocode: it resembles a programming language, but is designed for you to use more human-readable terms to solve your programming problem. For example, let’s go back to our fruit counting program we defined in Step 1, adding pseudocode.

/* A kid’s fruit counting game needs functionality. 

I need this program to add up the number of fruits the user provided at any one time. */

function AddFruitNumber(any number of arguments go here, including none)

add numbers provided by user, then print(total number of fruits)

/* If the number = not provided, give a message that tells him no fruit have been added yet. */

if number = undefined , print(“No fruits added…gimme fruits!”) 

Here’s what’s nice about pseudocode: There’s no pseudocode standard; there’s no compiler; there’s nobody to tell you, “You forgot to indent on line 2504.” Pseudocode can’t break, it’s totally up to you how you form it, and it can only do good things in assisting you in getting you one step closer to a working solution for your JavaScript interview questions written in a real programming language. 

Step 3: Solve entirely in a programming language

We’ve worked hard in the last two steps to get us to the moment we’ve been waiting for: solving this problem purely in a programming language. We’re going to go over our pseudocode and hopefully by this point your brain has been making some connections to how this should look as a real program. I’m going to use JavaScript here, and while I’m not going to go over the theory behind this code, what I’m doing is taking what I know from that language and applying it to complete the problem, so that I have minimum functionality.

(for example, I used JavaScript’s arguments object so that I can have an indefinite number of arguments): 


function addFruits() {
    var basketOfFruit = 0;
    for (var i = 0; i < arguments.length; i++) {
        basketOfFruit += arguments[i];
    }
    if (isNaN(basketOfFruit) || basketOfFruit === 0) {
        return 'No fruits added...Gimme fruits!'
    } else {
        return basketOfFruit + ' fruits have been added to the basket.'
    };
}

If you’re new to programming, or haven’t had a lot of practice with a specific programming language yet, it’s possible this step is going to stop you dead in your tracks. It might also stop you slowly in your tracks. Either way, computers are very strict inventions, and unfortunately you can’t invent JavaScript theory or syntax on the fly (yet!). So what happens if you get to this step and you’re stuck? Further, what happens if you don’t know where to go after reading the language’s documentation and testing some similar code you saw on Stack Overflow for hours on end?

At this point, your eyes have been glazed over for hours and you feel like quitting. The negative thoughts are starting to drip in: “This problem is dumb anyway,” or “Maybe I’ll just go learn network security; programming sucks.” 

Step 3.5: Reach Out

You’re stuck on a coding problem, going in circles, and you’re ready to give up. Don’t give up — ask for help. Remember, this is a collaborative industry, despite the stereotype of unsocialized nerds living in a dank basement cranking out brilliant code on zero sleep and Mountain Dew Code Red by the two liter. The overwhelming majority of good code is the result of a concentrated and collaborative effort over years of perfecting it. All that said — you’re stuck. You tried. You’re tired. Reach out. Ask your interviewer to give you some a pointer or insight!

When you’re working with your interviewer, be sure to actively listen to this person’s feedback and take notes that you can refer to when heading back to solve the problem. Repeat the person’s observations back to them to clarify any misunderstandings. While it may be very tempting to nod your head “yes” when your interviewer asks “Are you following?” but you have no clue what she just said, have the courage to say no and tell her what isn’t clear to you. Use as specific and technical terms as possible. With this new expert insight, head back to the code dungeon to try and slay this problem once again.

Step 4: Improving Your Working Solution

You’ve finally got your program working. Congrats! Consider this a victory; many developers have quit before reaching this stage. 

Now it’s time for an extra round of fortitude-testing. . .Because 1) developers love to hurt themselves in weird ways and 2) there’s only one thing better than solving a coding challenge: solving that coding challenge optimally. In problem-solving mania with your JavaScript interview questions, you may have latched on to the first solution in your head.

Oftentimes this solution isn’t the most efficient, and what really gets us paid in the software development industry is efficiency: Efficiency of communication, efficiency of actions, efficiency of programs. The technical term for re-designing our program to run better without changing its functionality is called refactoring.

A good way to kick off the process is simply to ask yourself, “How else can I solve this?” Don’t be afraid to experiment and break things; just set aside your original solution in a safe place and play around with a copy of that solution, seeing what you come up with.

Things might get cramped on a whiteboard, but do what you can to keep the original solution. An unoptimized solution is better than no solution when it comes to solving JavaScript interview questions.

Here is my optimized JavaScript solution to the problem:

function UserAddsFruits() {
  var UserBasketOfFruit = 0;
  for (var i = 0; i < arguments.length; i++) {
    UserBasketOfFruit += arguments[i];
  }
  if (isNaN(UserBasketOfFruit) || UserBasketOfFruit === 0) {
    return 'No fruits added...Gimme some fruits!'
  } else {
    return UserBasketOfFruit + ' fruits have been added to the basket.'
  };
}

For this pass, I’m making my function name and variable name more semantic. Other improvement ideas for future iterations include using ES6’s rest parameters instead of the current arguments object, and displaying the number of fruits in the browser as opposed to the console.

Those are the four steps to solving JavaScript interview questions.

This method may seem like a lot of work, and it is. But the alternative will take much longer and has far more negative consequences.

To recap, the four steps to solving JavaScript interview questions are:

1) Write down the problem

2) Iterate and translate

3) Solve the problem in a programming language (3.5: Reach Out)

4) Improve the working solution (refactor)

As programmers, it’s our job to solve problems. This four-step technique can bring us to the solutions of our JavaScript interview questions using a clear, logical, and efficient process that not only helps us do our jobs, but also improves our problem-solving abilities and confidence levels whether we’re trying to build a simple fruit counter or tweak the last function that will land our pet betta fish on Mars.

If you want more trick, tips, methods, techniques, and insights on getting a job in the web development industry, check out my top-rated book How to Get a Job in Web Development.


Code on and prosper,

-RTC 

Up next: 3 Web Developer Portfolio Project Doubts (& How to Overcome Them)

Leave a Comment