4 outlines of mountains representing lessons 1–4, a plateau at lesson 5, and real mountains representing the assessments.
It‘s epic.

My Preparation Process for the LS 129 Written Assessment

Megan Turley
Jul 10, 2020 · 10 min read

First of all: I LOVE prepping for Launch School’s written assessments. I have an epic process that is slow but rewarding, where I see an exponential amount of growth as the concepts become more concrete.

I want to share what was helpful for me in case it helps someone else. With the caveat, of course, that everyone’s process is going to be different; I have greatly benefitted from borrowing from other students’ processes. I’d love to hear yours.

Part of what made 101 so hard was learning how to learn and figuring out what works for me. 120 allowed me to dig into my style/routine of learning and trust the process. Other students I have talked to agree: 120 is where we finally feel like we are in our groove.

Also, RB 120 was mind-blowing, but the concepts themselves were explained so well, and the lessons were so circular that I felt like they were easy to understand. In 101, I had to reread paragraphs many, many times before they started to click because they were entirely new for me. In 120, it was encouraging to feel like I had a basic comprehension of most lessons the first or second time I read them. This is a testament to how well the Launch School courses are written and organized. If you’re struggling through 101: be encouraged. It gets better. All the time you put into learning will strengthen the foundation you need for Object Oriented Programming.

What to Expect on the Assessment

The 129 written assessment for the Ruby track has a time limit of 3 hours. You can expect between 15–20 questions, including a longer question. They tell you to leave at least 30 minutes to answer this question; I took almost 50 minutes, but I also didn’t read the question as carefully as I could have and lost some time because of that. Thankfully, I had given myself enough buffer time to be able to finish. When you start the assessment, it’s a good idea to skip to the end and read this question so you can estimate how much time you need to leave yourself.

The other questions are a mix of open-ended concept explanations and problems similar to the ones you might find in the OOP problem sets. I expected it to be half/half, but the ratio leaned more towards open-ended concept explanations.

It was incredibly useful to prepare code examples and explanations for each topic on the study guide to use in your answers for the assessment. You will have to rework your pre-written response to get at more of what the question is asking, but it’s worth it not to have to think of an example when you’re under pressure. Make sure to test out your code examples!

Study Sessions

I started study sessions pretty early on, very thankful for the connections I had made in 101 and 109. Some students I studied with, like Steven, Felicia, and Kris were already preparing for their interview assessments when we had the study session together. The great part about RB 120 is that the course is so circular that you will be able to understand most of what they are talking about after you finish lesson 1. I learned so much by listening to them explain concepts and asking them questions.

I also recommend attending a TA-led study session after lesson 3 (if there is space — some students are preparing for the assessment and should have priority over someone who’s not done with the course yet). It was helpful to hear from Karl more about what to expect and how to prepare.

If you are both preparing for the written assessment, the most important thing to focus on is finding your blind spots. In a study session with Richard and Jay, Richard had developed a great set of Anki flashcards that he had been using consistently throughout the course. He shared his screen, opened the deck, and we went through the flashcards, taking a minute to answer them on our own and then sharing what we had answered. This process was invaluable to find blind spots.

Jay also shared the most fantastic set of notes I have ever seen that he wrote using Notion. I went through his notes to make sure I wasn’t off-mark. It is as helpful to read other people’s questions as it is to read their answers because everyone’s questions will be different from mine and will perhaps require me to expand my understanding of a concept.

Also, it is never a good idea to just copy-paste someone else’s notes. The process of making your own notes helps you to remember the concepts better. If you are going to use someone else’s notes, it should be like we did here: to compare to find blind spots or improve our already-existing explanations. Developing the muscle of asking questions is an integral part of learning how to learn.

I also learned to pinpoint key concepts from Marcos. My catchphrase is now What Would Marcos Say First? I often jump into talking about a code snippet example before mentioning key points, but the order is important: list main points first, then explain using examples. Prove right away that you know the most important talking point(s) about this concept to answer the specific question at hand. This is also a good way to prevent tangents, which could count against you.

Lesson 5: my Plateau

Leena shared on Slack about “learning to love the plateau.” OOP is such a new way of thinking about code that you will probably have a plateau at some point. Lesson 5 was mine!

Lesson 5 felt very challenging for me because it’s where the rubber meets the road: you put OOP concepts into practice by writing a Tic Tac Toe game and a Twenty One game. I didn’t truly understand how to make the different parts of the program work together until I made the Twenty One game from scratch, starting with my own spike.

I discovered through Srdjan’s review of my code that I hadn’t fully understood the purpose of class variables. As much as I wanted to toss the program and start over, it was a valuable process to refactor: it’s where I discovered my blind spots.

My Own Process

My process for preparing for this assessment was very similar to what Srdjan described in a Slack post as a tip to remember material:

My advice would be to do “circular” learning. This means that after you finish all lessons, you return to the beginning and redo them. This time, you can mark each lesson as easy, medium, hard. The ones that are easy you don’t have to review anymore, but for medium and hard, you might need a third, fourth, or fifth pass through the material.

I did this for 101, and I did it again now. Both times, I felt the difference in my confidence in being able to explain concepts using precise language. The first time I learn a concept, I am so focused on trying to wrap my head around it that I don’t pay as much attention to language. The second time around, I can pay more attention to the language needed to describe the concept more accurately, which helps it stick better. Here’s an in-depth description of my process:

ROUND ONE: Flashcards and Questions

The first time I went through the course, I made Anki flashcards and notes, trying to write out concepts in my own words. I reviewed topics using these flashcards while moving through each lesson. Still, by the time I got to the end of 120, I realized that most of these notes I had made were not accurate: they were either incomplete, incorrect, or trying too hard to put a concept into my own words when using a Launch School definition would have been better.

When you’re in the midst of the course, it’s hard to know what you know and what you don’t know. The most important thing for me was to trust the process and try to explain each concept. Even though I had to toss these notes later, I thanked them for their part in helping me get to where I am now, à la Marie Kondo.

The most valuable part of that process was amassing a list of questions that I later used to make my real notes. The second time I went through the course, every time I came across a new topic, I went to my list of questions and added more detailed questions about this topic in particular, along with links to where I could find the answer. I also made a note of which topics or quiz questions were particularly challenging so that I could revisit them later.

By this time, I was better at knowing what details to pay attention to in the course materials so I could make better questions. I also collected problems that I could use later to make a practice test. Here is my first list of questions and problems.

ROUND TWO: Organize the Questions and Notes

The next step was to start making prepared explanations and code examples that I could use in my assessment. To do this, I first had to organize my notes by topic. I initially used the study guide’s list of topics to make sure I had everything covered.

When I started to write my answers to these questions, I saw that many of them were so interrelated that they could be combined into one answer, or at least use the same code example to explain. I began to organize questions and corresponding links into lists of questions related to each topic. I grouped similar questions in a way that made sense to me.

“What is inheritance?” became a long list of related questions, with corresponding links.

I began to see patterns in what I was learning. For me, most topics seemed to fall under the umbrella of either Encapsulation or Polymorphism. These two concepts seem like opposites, but they work together in OOP. Encapsulation isolates, while Polymorphism creates relationships, but together they take code into higher levels of complexity. This still fascinates me. Based on these patterns I saw, I organized my notes into sections: OOP in general, Encapsulation, Polymorphism, and other topics that I know fall under one of those umbrellas (but the tables were getting too big, so it made sense to just pull them out).

My notes aren’t pretty. But the process is what mattered: it helped me to organize the topics and make cognitive connections between them. I am a very visual learner, so it helps me to visualize where the topic is on this table, so I know how to relate it to other topics. Here is the link for that document.

I extracted the problem sets into another document: see it here.

ROUND THREE: Pushing Myself to Answer Everything

Using my new list of questions, I went about writing out the answers to my questions and preparing code examples that I could use to explain concepts. I saved my answers in markdown using this in-browser markdown program because I was also making my list of text expander snippets using this Chrome extension. I wrote all of my code examples using a Coderpad sandbox to get comfortable thinking of examples there (just thinking ahead to the interview).

The process of thinking up real-life examples was a little too fun. I got sidetracked making silly examples like this:

What not to do: this was supposed to be a simple explanation about private methods, but it became an involved story about how cats make friends.

As you can see, I tend to overthink my examples, so I had to put some pressure on myself by giving myself a time limit to explain a set amount of concepts. The first time I did this, I only answered 3/10 questions in the hour. By the time I finished, I could answer all 10/10 questions I had given myself, and I now had the beginnings of my final set of notes.

ROUND FOUR: Review and Taking Practice Tests

I went back over these answers, compared them to the LS materials by using my previously collected set of links to check if my notes were accurate and complete, expanded on them if needed, and tested out concepts by writing new code examples. At this point, I also compared my notes with other students’ notes to make sure I wasn’t missing anything, as I mentioned previously.

For my final step, I reviewed the concepts and quiz questions that were hardest for me several more times. I made practice tests by combining questions about concepts and some debugging/what-will-this-output-and-why kind of problems. These practice tests contained ten questions.

I decided that I was ready when I could complete three practice tests in under an hour each. This speed took a while to achieve because I had to build up muscle memory in my fingers to be able to type out explanations using precise language, quickly. I even did a practice test where I wrote out detailed explanations of every problem from the Easy 2 set, which is an excellent set for gauging where you need to be as far as speed, understanding concepts, and precision of language.


Here are some of my key learnings when preparing for this assessment:

  • Dig into your own style of learning: trust the process.
  • The first (few) time(s) through the course, collect questions, and hold your initial answers lightly.
  • Find your blind spots and ways you need to improve by comparing notes, studying with other students, attending TA-led study sessions, and refactoring your code based on code reviews.
  • Take notes or organize what you’ve learned into a format that works for you.
  • Prepare pre-written code examples and/or explanations of concepts, and practice typing out those answers.
  • Decide what it looks like for you to be ready.

What works for you when preparing for written assessments? Please share; I’d love to keep learning new ways to learn.

Launch School

Publications of the Launch School Community