When Coding Goes Wrong: Or, My Advice for Launch School’s 109 Interview Assessment

You might call this my YAG (yet another guide) for Launch School’s 109 interview assessment. Although it’s not really a guide, the story and advice that I share below served me well when I made a mistake during the assessment, and as those who have seen the study guide know, one of the skills being tested is how we recover when we make a mistake (or whether we recover at all!).

In a lesson of Launch School’s JS101, there is a coding tip that describes how experiencing difficulty in coding helps us to learn better. It seems that the more we struggle to find a solution to a problem, the better we learn a lesson about coding, whatever that may be. Once we discover our mistake, it becomes implanted in our memory ever more permanently, and it lowers the risk that we will make the same one again. The lesson calls this the “burn”.

In the same lesson, we also learn the importance of developing the appropriate temperament for debugging — consisting of remaining patient and employing logic. While that sounds easy enough, for me it took a “burn” for this advice to really sink in. My own burn made it painfully obvious how easy it is to lose focus on solving the problem, and it wasn’t even in a stressful situation. This really made it apparent that I needed to be ready when I undoubtedly made a coding mistake in front of another person.

I have found that when things go awry, strong emotions leap quickly to the front of the mind and can threaten to dominate. And while it is easy to begin to feel panicked when coding goes wrong, it is vital to be able to keep one’s head. This is because the ability to think disappears as soon as panic sets in, and it is only in thinking through a problem that one might be able to find the issue and fix it.

So I was trying to solve one of JS101’s exercises — one of the small problems. But despite my best efforts, I just could not get my code to work, even though I had checked the algorithm forward and backward. After more fiddling, I began to play around with what I thought was the simplest part of the problem: the nested array that I initialized at the beginning of my solution. Here is what it looked like:

newMatrix; // => [ [], [], [], [] ]

And here is the problem that threw me for a loop. When I tried to assign a value to one of the subarrays, like so:

newMatrix[0][0] = 1;

Which should have resulted in an array like the following:

newMatrix; // => [ [ 1 ], [], [], [] ]

It instead resulted in:

newMatrix; // => [ [ 1 ], [ 1 ], [ 1 ], [ 1 ] ]

At the moment I saw this, I felt like I was going crazy: was there something wrong with JavaScript, or my understanding of how arrays worked? How was it possible that I could add an element to a subarray and find it placed into all subarrays?

This was where it became a battle between my rational mind and my emotional being. I had a few thoughts like: maybe my computer is broken, or: I will never figure out what is happening here, this is insane.

But while these thoughts were fighting for attention in my head, in the back of my mind I had another, more helpful thought: how was this array created? Why don’t you take a step back and look at the code above this? I started inspecting how I had created the array. Here’s how I had done it:

let newMatrix = Array(4).fill([]);
newMatrix; // => [ [], [], [], [] ]

I looked at the MDN documentation for the Array() constructor and array.prototype.fill(). After much searching, I finally stumbled on this, the last bullet point under the description for fill():

If the first parameter is an object, each slot in the array will reference that object.

AHA! I had specified that fill() should use [] to populate each element in the array. It had never occurred to me that the method might use the same array for each element. So all of the subarrays were referencing the same object! I wasn’t going crazy after all.

Lesson learned. Do not try to create multiple objects with the Array.prototype.fill() method, and if in doubt, read the documentation. And a broader lesson: don’t give up, and learn to listen to your thinking mind. I thought I was going crazy and I had no idea what was wrong, but I kept poking at the problem until I found the one line in the documentation that explained the whole thing.

Like I said earlier, this happened while I was alone and with no outside pressures, which made it feel all the more silly afterward, but also made it more apparent that I needed to practice keeping my head when struggling through a problem. And when coding in front of another person, it is easy to feel more pressure, and the likelihood increases that you will make a mistake. But that’s not a bad thing; it provides an opportunity to grow as a programmer. So my advice is this: do not shy away from difficult coding situations. Instead, embrace the discomfort, and use it as a way, even in the midst of doubt and anxiety, to practice maintaining your focus and your ability to think clearly.