I haven’t completed all of Launch School yet (I’m in Course 220: Front-End Development with JavaScript), but I have completed enough assessments to have some thoughts on how to prepare. To give you some idea of my experience, I passed all of the Back-end courses and the first Front-end course assessments on my first try, several with perfect or near-perfect scores.

I also have experienced failing an assessment, when I did the interview for the first JavaScript course without adequate preparation. Through this experience I have some thoughts on how to study for an assessment. Your mileage may vary, and I’m sure this isn’t an exhaustive list, but here are some recommendations that I gleaned from my experience and from other students:

Take Multiple Passes Through a Course

Launch School courses are long and have a lot of depth. By the time you have completed a course, you may already be beginning to forget what you learned in the beginning of the course. Or you may have completed all of the materials, but realize you are still fuzzy on a lot of the concepts.

This is why it is important to be willing to go through a course again for the second or third time. As someone who was a musician before learning to code, I know that it takes multiple practice sessions to learn a passage of music. Similarly, it’s not enough to read about a concept once and then move on. See Elizabeth’s post on Circular Learning for more perspective.

Utilize Spaced Repetition

Because it takes multiple repetitions to remember something well, it’s good to have a system in place that helps you review exercises and concepts on a regular basis. I use a program called Anki to do this. Whenever I come across a new concept or an exercise that trips me up, I make an Anki card for it. What makes Anki cool is that each time you review a card, you can tell the program if it was difficult or easy for you and Anki will use that response to calculate which day you should review the card next. This method works best if you use Anki on a daily basis.

Several programmers have thought a lot about how to learn with Anki. I especially recommend Derek Siver’s post and the Janki Method.

Take Notes

This is something that I don’t do enough. From talking with other students, I’ve noticed a lot of them have good systems in place for taking notes. Even though our primary work is done on the computer, a number of students have recommended handwriting notes. There is science to back up why handwriting may be helpful.

One student uses different colored pens as he take notes. I imagine that would make note-taking more fun and your notes more memorable. As far as note-taking apps, I’ve heard Quiver recommended.

Explain a Concept Out Loud

One of the skills you need to have for both the written assessments and the coding interviews is to be able to precisely explain concepts and code examples. This is not a skill that comes naturally, so it’s good to be intentional in how you practice. One student told me that he sometimes paces around while talking through concepts, and I’ve found myself doing the same. I’ve also found doing study sessions with other students is a good way to practice. If you don’t have another student to talk to, maybe try a rubber duck.

Write a Blog Post

By blogging you can take notes, explain a concept, and share your learning with others all at the same time. By writing about a concept, you have to explain it in a step by step way, which is good practice. You also discover gaps in your own knowledge while writing, which can assist you in knowing what to study. And by writing about code, just like speaking about it, you are helping yourself remember syntax and concepts. If you’re having trouble getting started with blogging about code, check out How to Blog About Programming While You’re a Student.

Do the Optional Exercises

The one time I failed an assessment (or “Not Yet”, as the instructors like to say), it was because I had gotten overconfident from passing previous assessments and did not adequately prepare. The assessment that tripped me up was a live coding interview where I had to solve a problem using JavaScript. The instructor realized that I needed more practice with solving problems and the JavaScript syntax. He recommended I do the optional small problems exercises for Ruby (Medium difficulty), but solve them using JavaScript. I did those and shortly after that, Launch School added the JavaScript exercises and I did those as well.

By going through those exercises, I got a lot more comfortable with the problem-solving process and the JavaScript syntax. When it was time to take the assessment again, I was confident in my skills and passed. Looking back, I’m glad the instructor had me spend the extra time on this subject, as it gave me an important foundation for the next course which is even more challenging.

Build a Project

After completing a course, consider building a small program or project with what you have learned. This tests your ability to put together all of the concepts from the course. And unlike many of the course exercises, you can’t rely on a walkthrough video to help you along, forcing you to solve all of the problems on your own. Victor combined building a project and taking notes together into his impressive HTML and CSS Notes.

If you’re a Launch School student, what have you found helpful in preparing for assessments? If you’re not a Launch School student, but you have experience passing programming tests or coding interviews, your tips are welcome too!

Tip #1: Be Honest

Be transparent about your experience. If you’re a student, say so. If you just learned the concept you’re writing about yesterday, make that clear. Readers are very forgiving if you’re honest about the fact that you’re still learning. What upsets readers is if the writer claims to be an expert at something they are not (yet!).

Tip #2: Don’t Worry About Going Viral

This may surprise you, but this is a real concern I and others have had when publishing to the internet for the first time. It’s been shown that almost everyone thinks they are above average, and likewise many of us feel that the moment we share our amazing wisdom with the world millions of readers on the interwebs will flock to it.

The reality is, that unless you are Chewbacca Mom, almost no one will see your first attempts at publicity on the internet. It normally takes years of writing to build a large following, so don’t fret that you might hit the front page of reddit with your post on floating point numbers in Ruby and that thousands of angry commenters are going to descend upon you.

Tip #3: Find Inspiration By Talking With Other Students

Both my first post and this one were inspired by conversations I had with other students. When you’re describing something you’re learning to another student, you naturally have to explain it in a step by step way. Take that conversation and summarize it as a post. You also may realize that the question another student has was one you also had. This means it’s likely that many students had the same question and would like to read about it!

Tip #4: Notice when you’re stuck on a problem and how you got unstuck

Keep track of when you don’t understand something. Describe what you didn’t understand and why you were stuck. Then explain the process you took to become unstuck. Learning that process is valuable for other students. Show the process you took, whether it was looking up documentation, experimenting with code, or asking the right question. Students want to know, how do you solve a coding problem you’re stuck on?

Tip #5: In the beginning, your blog posts are mostly for yourself

Given that not many people are going to read your first posts, and that you aren’t an expert on these topics yet, your first posts are mostly about solidifying your own understanding. By writing about what you’re learning, you are helping yourself remember the concepts you are studying. And by explaining a concept, you often get a better understanding of it.

Tip #6: Have someone hold you accountable

This is the approach I took with my first post. Tell another student that you are going to write a post and what it will be about. If you’re like me you also tell them you start many posts but don’t finish them. Tell them to hold you accountable that you’ll publish this time. Then, when you feel like giving up, there will be someone that won’t let you get away with it, which is often fun for them as well.

I hope these tips are helpful for you. I’ll take my own advice and say that I’m new to writing about code and could be wrong about all of this, so if you disagree, please let me know!

On line 1 we declare the inventory variable within the global scope. This way we can access it in the console as we are developing. Then we use an Immediately-Invoked Function Expression (IIFE) to add properties to the inventory object. We use an IIFE so that the properties are private and encapsulated in the inventory object.

The final line is where I got stumped.

$(inventory.init.bind(inventory));

I stared at that line a long time.

I wondered, why is it necessary to bind the inventory.init method to the inventory object context? And why is this line wrapped in a jQuery function?

Since it took me a long time and a lot of reading to answer these questions for myself, I thought I would share how I broke down what was happening and what I learned about context in JavaScript and the jQuery function in the process.

Let’s start with the first question:

Why is it necessary to bind the inventory.init method to the inventory object context?

In my understanding of context in JavaScript so far, I knew that if you call a method on an object the context is set to the object calling it. So, I thought, couldn’t you just write $(inventory.init)?

I tried that and got this error:

Uncaught TypeError: this.bindEvents is not a function

What? But bindEvents is defined in the inventory object, and the inventory object is this right? … Wrong. After using a breakpoint in the console I discovered that this was pointing to the Window, the implicit global context. But how did that happen? Why was the inventory context lost?

Then came my first a-ha moment. I realized that the inventory.init method was not being immediately called. If it was being called it would be followed by a parenthesis like so: inventory.init().

And unlike call or apply, bind does not call the function. Instead, its purpose is to permanently bind the context to the object passed to it.

This is when I remembered an important concept: function execution context is determined not when the function is defined but instead when it is executed.

For example:

var foo = {
  bar: function() {
    return this;
  }
};

var baz = foo.bar;

foo.bar(); // => returns Object { ... }
baz();     // => returns Window { ... }

foo.bar() sets this to foo because it is method invocation. However, when we assign foo.bar to baz and then later call baz(), the foo context is lost because we are using function invocation, so the implicit Window context is used as this instead.

To correct this, we would use bind like so:

var foo = {
  bar: function() {
    return this;
  }
}

var baz = foo.bar.bind(foo);

foo.bar(); // => returns Object { ... }
baz();     // => returns Object { ... }

With the first piece of the puzzle solved, it was time to move to the next question:

Why is the line wrapped in a jQuery function?

Here’s the line in question again for our reference:

$(inventory.init.bind(inventory));

The jQuery function, which the $ is a shorthand for, was the other mysterious element to me. Couldn’t we leave it out and just write:

inventory.init()

And anyway, I’m used to seeing the jQuery function wrapping selectors like $('p'), what is it doing wrapping a function?

That’s when I remembered that a shortcut for writing

$(document).ready(function() { } )

is

$(function() { } );

Then I realized that what we were doing was instead of using an anonymous function like the line above, we were telling jQuery to run the inventory.init function after the document was ready.

Because the jQuery function was not immediately calling the inventory.init function, but instead storing it to be called later when the document was ready, the context is lost if you don’t bind the context to the inventory object.

This is because when the function is actually called it is being called by the jQuery function, making it function invocation, so the implicit function context of Window is used. This is why we instead write $(inventory.init.bind(inventory)) to permanently bind the function context to the inventory object so that when the jQuery function later calls it the context is retained.

This also helps explain why on line 10,

$(“#add_item”).on(“click”, this.newItem.bind(this)); 

we have to bind the context again, because we are not immediately calling the this.newItem method, but instead jQuery will call it later using function invocation when the click event fires.

So, in summary, if we were to explain what happens in the last line of code,

$(inventory.init.bind(inventory));

we would say that we bind the inventory.init method to the inventory object context and pass it to the jQuery function as a callback that will be called as function invocation after the document has loaded and the DOM is ready.

Phew! Now I finally understood what was happening on that final line of code and felt I had a better understanding of context in JavaScript and how the jQuery function works.

For further reading, I highly recommend Gentle explanation of ‘this’ keyword in JavaScript.

Note: Since I’m relatively new to these concepts, it’s very possible there are mistakes in this post that need corrected. Please help me out and add corrections in the comments and I will edit this post.

How being stumped by one line of code helped me understand context in JavaScript was originally published in Launch School on Medium, where people are continuing the conversation by highlighting and responding to this story.