Preparing for the JS109 Interview Assessment

Getting through the first interview assessment in Launch School’s curriculum is a subject that has been written about extensively. And having recently gone through that process myself, I can safely say there’s a good reason for that. It’s a different format for testing your knowledge, and the higher stress environment really stretches your abilities to the limit.

As of the time I am writing this, the JavaScript track is still pretty new at Launch School, and all of the stories of students’ successes and recommendations for the 109 interview assessment are discussed in the context of the Ruby track. This article is set in the context of the JavaScript track, and I’ll try to give specifics about JavaScript where I can. But the most important thing I realized during my preparation was that the key to success is the same in either case — you have to establish the problem solving patterns in your mind well enough that they come naturally even when you’re under the gun. Mastering the language-specific details is certainly a part of that, but it’s the easy part. When you get down to solving a coding problem in your interview, the hard work will have already been done before you even write any code if you are doing it right.

To be honest, most of these points are included in the study guide. And as a general note, spending some quality time with the study guide and its recommendations is one of the most important things you can do. Listed below are some of the specific things that directly benefited me during the actual interview. Even if some of them are repetitive, I can’t emphasize enough how important they are!

Always use the Mini-PEDAC process

Remember the “Introduction to the PEDAC Process” lesson? I hope you do because they basically gave away the keys to the castle there. As you do practice problems, always use the “PEDAC-light” method that is described in JS101. This is different from the full PEDAC which is used much later in the course. It is simpler and perfectly suited for the complexity of the problems you will need to solve during the interview.

When I first committed to using the mini-PEDAC process to work through the JS101 exercises, it actually took longer to do than if I had jumped right into the code. But as I started doing harder exercises — or more importantly problems I hadn’t seen before — the mini-PEDAC process was the only way to consistently get them done in a reasonable amount of time.

Think in terms of input, output, rules, and an algorithm. The data structure part of the full PEDAC process isn’t important at this point since you are just working with arrays, objects, and primitives.

For the algorithm, start with a sentence or two of how you, a human being living on planet earth, would solve the problem. If a human wants to know how many times a certain letter occurs in a sentence, they don’t start by splitting it into an array and iterating on the array. A human just goes through each letter in the sentence and counts on their fingers whenever they hit the letter they are interested in. Once you have the problem understood at that level, you can start thinking more like a computer, creating more specific iterations of the algorithm until the actual code practically writes itself. Using this kind of common-sense first approach to developing the algorithm will make sure you start with a logical foundation that will effectively solve the problem.

As a point of reference: I had never seen the exact problems I was given in my assessment before. You probably won’t have seen yours before either. And I’m confident that if I hadn’t used the mini-PEDAC process, I would have bombed the interview.

Test Stuff Out

It’s one thing to know how to use a specific method when you are relaxed and practicing for fun at home. It can be quite different getting it to work right when you are live coding, even for the really simple ones. So go ahead and try it out in the console before putting it in your code. One of the worst things you can have happen is to think you have solved the problem, only to realize that a method doesn’t work like you think it does.

For example, I can never remember with 100% certainty how splice works. Is it the first or second argument that says where to start from? And what does that even mean? If I give it a 0, what does that do? It’s hard to know the answers to these questions from memory during an interview, but it’s super easy to test in the console, which can prevent a lot of pain later on.

When in Doubt, Review the Algorithm

In the process of writing and testing your code, you might encounter unexpected results. It can be tempting at this point to revise the code to get the results you were expecting, and sometimes that will work. Sometimes, though, there’s a logical flaw in the original algorithm. Trying to tweak the code in this case can lead you down a rabbit hole of fixing the wrong problem, creating new bugs, and generally wasting huge amounts of time.

It is therefore extremely important when something doesn’t work the way you expected to go back to your algorithm and review it. Perhaps the new behavior will alert you to a flaw in your logic, and you can easily revise the algorithm to correct it. Then it should be more simple to revise the code. Even completely starting over with new code isn’t a disaster: Remember, the code is the easy part.

Getting the Most out of the JS101 Exercises

Once you master the basic syntax of JavaScript, it is crucial to start recognizing the general types of problems you will encounter. Like I said earlier, you won’t have seen the exact problems you are asked to solve during the interview before. But with the right kind of preparation, you can immediately recognize the type of problem it is.

This builds on using the mini-PEDAC process, particularly the input and output. Simply listing the input and output can start to shape the problem. If the input is a string and the required output is an array, that’s a clue — and you can start thinking in terms of patterns around converting strings into arrays. As you use the mini-PEDAC process with the JS101 exercises, you can start thinking of your practice in terms of solving types of problems rather than specific problems.

For my preparation, I started using intentionally vague prompts like “Make a string into a different version of itself”. The answer to this prompt isn’t strictly defined and requires brainstorming on the general things you can do when transforming a string.

What worked well for me when using these more general prompts was to invent several problems on the spot to convince myself that I knew a lot about transforming strings, which I could then solve using the mini-PEDAC process. For example:

• Swap the capitalization of every “nth” letter of a string
• Shift all the vowels in a string N letters later in the alphabet
• Remove all non-letter characters from a string
• Reverse a string using only the reduce method

The problems I tended to come up with under this approach were similar to the JS101 exercises problems, but not exactly the same. Needless to say, this was very helpful when taking the interview assessment, since I think it would be fair to describe the interview problems as similar to the JS101 exercises, but not exactly the same.

Act Like You Know What You’re Doing by Actually Knowing What You’re Doing

As a final note, there is a portion of your grade for Launch School assessments that is “non-technical”. This especially comes into play during the interview assessment, since you are interacting with somebody else in a live setting.

A great deal has been said elsewhere about how useful it is to attend study sessions and set up 1-on-1 coding sessions with your peers to practice live coding. The goal is to first of all get used to talking, thinking, and typing at the same time, which can be difficult if you haven’t done it before. Doing this well is critical for getting a good non-technical grade. So please, practice talking and coding at the same time, preferably with another person.

After some practice doing this, you should have a rough script to follow:

• Break the problem down and document the algorithm using the mini-PEDAC process
• Write the code for your algorithm, testing extensively along the way
• Circle back around to the algorithm and revise it until your solution works the way it needs to

While going through this process, get used to saying things like:

• “I’m going to start by breaking this problem down into its inputs and outputs.”
• “Just thinking at a high level, to solve this problem I would ….”
• “Before I use this method, let me test it out and see if it works the way I think it does.”
• “That isn’t the result I expected, let’s go back and review the algorithm to see if we need to make any changes there first before revising the code.”

Acting like you know what you’re doing is another way of saying “speak with confidence”, which is maybe the biggest part of presenting yourself well. The best way to do this is to actually know what you are doing, and I hope that these suggestions will help you achieve that goal.