How I Passed RB 119

This article is written for students in Launch School who are in RB 110 or RB 119. It may also apply to the equivalent courses in the JavaScript and Python tracks.

Photo by Nick Morrison on Unsplash

Passing the RB 119 written and interview assessments was quite challenging. Everyone is different, and the path taken must also look different for each student, but I have found that I learn a lot from hearing about other people’s journeys. Much of what I did I borrowed from other student’s stories and tips.

How I Passed the Written Assessment

Here are the steps I took to prepare for the written assessment:

First 2–3 weeks:

My goal was to gain a rudimentary familiarity with the material, a thorough introduction.

1. I read through all the material, worked the exercises, and took all the quizzes for rb110 and rb119. On this first pass I focused on reading for comprehension, but I took no notes and made no flash cards.
2. As soon as I got into rb119, I started working through the Ruby small problems Easy and Medium. I created a target number of daily problems to complete and did them while I was working through rb119, only taking a break when I worked on the larger programs in the curriculum. I focused on finding a solution to each problem without using the hints or looking at solutions. Instead, I used the RubyDocs and google when I got stuck. My goal was simply to find solutions, and to develop familiarity with PEDAC while working the Medium problems.
3. During this whole process, I joined as many TA led study sessions, and PEDAC sessions as I could. I also joined the SPOT sessions.

Next 2–3 weeks:

My goal was to master the concepts in preparation for the written assessment.

1. I took the study guide I had made for rb109, and modified it with the “Specific Topics of Interest” listed in the curriculum under “Study Guide for RB119 Exam”.
2. Then I went through all the rb101, rb109, rb110, and rb119 material again. The 101–109 material was just review, but I quickly did all the practice exercises. It was boring, but I forced myself to take a couple days to review it all just so it was fresh in my memory. But when I got to the 110–119 material, I focused on learning it deeply. I typed all the illustrations in VSCode to build muscle memory. I read the material out loud, which meant that I was seeing it, and hearing it, then I summarized each concept out loud in my own words. This forced me to pay attention to everything I was reading. I then typed my summaries in my study guide (a markdown file in Obsidian, complete with the backtick and markdown formatting required for the exam). This means that I not only summarized the concepts out loud, but also when I was writing them down. I also made flash cards. Typing uses a different part of your mind than handwriting, and my goal was to get as many parts of my mind engaged in the material as possible because the more neuropathways I built the higher my recall would be in the future. By the time I finished the second pass, I had a stack of flash cards and a complete study guide.
3. I did not review the flash cards, making them was sufficient.
4. I continued attending every TA session and SPOT session I could.

I spent one day reviewing. I filled out my study guide with example code which I created off the top of my head. I reviewed my study guide. And then I got a good night sleep.

The next day I took and passed the written exam.

How I Passed the Interview

After passing the written exam, I felt pretty good about my study methods and anticipated that I would be able to pass the written exam without too much difficulty. Here is how I prepared:

1. I continued to attend the TA sessions on PEDAC and on the Interview Prep. I also continued to attend the SPOT sessions.
2. I worked through the 20 Interview Prep questions, recording myself with Wondershare DemoCreator (about $80), and timing myself. I used the full PEDAC process. I solved all but one problem in under 25 minutes and without having to look at any documentation. I felt pretty good about the assessment, so I scheduled the interview.

During the interview assessment, I received a problem at about the level of the LS Medium Small Problems (just as LS advertised). I was a bit nervous, but I had aced the rb109 interview, so I was fairly confident. I worked through the problem with PEDAC, coded it, and it didn’t work. At about 50 minutes in, I finally worked out the last bug. But I was out of time. I received a Not Yet.

While it was discouraging to receive a Not Yet, I did receive some valuable feedback:

1. My PEDAC process was fairly solid. And I was familiar with most of the methods necessary for the assessment. However, I should have used 1 or 2 helper methods. This would have isolated portions of the logic and would have made it easier to test, verify and debug.
2. I did not test the code as I wrote it. I should have tested line by line as I went.
3. There were a couple of places in the code where I used the wrong name for a method, or the wrong method for a data type. I needed to work on my Ruby fluency.

After taking a day off to recover from the disappointment, I decided that I was going to overprepare for the interview.

Here is how I prepared over the next 5–6 weeks:

I went over all the rb101–119 materials again, including the small problems, focusing especially on charting which methods work for which data types, their return values, and whether they are mutating.

1. I identified some areas for improvement: I was having difficulty with testing consistently, using helper methods, talking while coding, manipulating hashes, using recursion, and using regex. Each week I chose two of these things and found ways to learn more about and practice them.
2. I worked all the SPOT Wiki codewars challenges on the Codewars site using PEDAC. I redid all the LS Medium and Difficult problems along with the Debugging problems. I looked for places to use hashes, each, map, and select, and solved those problems twice, once with basic looping structure, and once with the appropriate iterator method. I also looked for places to use the variations on each like each_index and each_with_index. Each time I solved a problem, I then read the official solution (where there was one) and refactored using anything helpful I learned from that solution. I then read through 2–5 student solutions looking for at least one clever solution, and one that was easy to read but different from mine and the official solution. When possible, I then refactored my code from memory to mimic a student solution which impressed me.
3. I also worked through the easy and medium free problems on Coderbyte, some problems from Project Euler, and some from Leetcode. I chose 4–5 of the interview prep problems from Topcoder (there are 10 free ones). These are significantly more challenging than anything in rb119 or on the assessment. (Please note that Launch School does not recommend using any of these outside resources. It takes a lot of extra work to format and solve them in your IDE, and often they introduce concepts that we have not covered in the LS curriculum. They may be considered a distraction.)
4. I also set up many study sessions with fellow students preparing for the same interview assessment. I created a free calendly.com account, which allows me to share my calendar availability so other people can schedule meetings with me. I posted that link in the rb110–119 Slack channel with an invitation that anyone wanting to work on their PEDAC/coding skills live in a pair study session was free to put something on my calendar. I also direct messaged people I had seen in TA sessions and SPOT sessions who I knew would be good study partners. Over the course of 3–4 weeks I think I was able to work through about 20 pair programming study sessions. During study sessions lasted 60–90 minutes and consisted of one person solving a challenging problem using PEDAC and talking through their reasoning while the other watched and took notes. We generally timed them. Then the other student would give feedback. Was the PEDAC process easy to follow? Did the algorithm contain all the logic that was used in the code? Did the student use appropriate helper methods? Was the code tested frequently? What went well and what could be improved? Then we swapped places and the other student solved a problem and then received feedback. This practice was invaluable. I think I studied with 7–8 different students, some 2–3 times. Their various code styles were helpful to see, and they each gave me different, valuable feedback.

During this whole process, I took note of any problems I had trouble solving. I then hunted for similar type problems on CodeWars to work through, and then resolved the original problem.

After a while, both TAs and fellow students informed me that I was more than ready for the assessment, so I retook it and passed with flying colors!

Additional Study Tips

1. I have heard that 4–5 hours of intense study is all the mind can handle in a day. I typically get up early (4:30–5:00am) and start my day with a few minutes of prayer and Bible reading. Once I am in the right state of mind, I dive into my studies, and work until about lunch time. I find that I can join a study session or pair programming session in addition to 5–6 hours of study and still be engaged.
2. I spend the afternoons/early evenings working on my rental properties. (I buy rundown property, fix them, and rent them out.) This change of pace allows my brain to recover, and keeps my physically active. I recommend doing something active in addition to your studies as it helps with good sleep and mental recovery. I study 6 days a week and rest on Sunday (as a Christian, it is what I am supposed to do, as a student, I think I perform better on the other days and make faster progress because of the weekly day off).
3. Whenever I find my mind wandering, I take a break. I do not believe that learning can occur when one is distracted. I grab a cup of coffee, hit the exercise bike for 5 minutes, or hug my wife and kids. But I keep these breaks to 5–10 minutes and then return to my studies.
4. I find that my peak mental capacity is during my first 2–3 hours of study in the morning. So I get up before my wife and kids, and work on new material or the most challenging problems first. Review and group studying comes later when I am no longer at my mental peak, but still able to pay attention and learn.
5. I am a firm believer that practice makes permanent. So rather than mindlessly reading or solving coding problems, I always approach my studies with intentional focus. If I am reading, I focus on comprehension and regularly stop and summarize out loud what I just read. I test things out in my IDE. I take notes. Whatever it takes to maintain focus and learn. When I am working problems, I focus on improving areas of weakness. If I encounter a recursion problem and can’t seem to solve it, I review the course materials on recursion, do a bit of research online, and then look for a few other recursion problems to solve. If someone tells me that I am not testing my code frequently, I write ‘test code’ on a sticky note and put it on my monitor. And then with each new code challenge, I look to see what I am working on, and I see my two or three sticky notes (never more than 3 on the monitor at once!) and work on testing line by line. Practice the things that come hardest to you, and take the time to do them right. Once you have them down, move on!
6. Finally, do not be afraid to take the test! Getting a Not Yet is not the end of the world. I think if I had studied for 2 more months before taking the plunge I would still have received a Not Yet. I didn’t know what I didn’t know. I was focusing on completing PEDAC, and finding a solution to the problem. I was not focusing on testing line by line, and developing better debugging skills. I had to take the test to find out where I was weak so that I could work on my weaknesses and then pass the second time! Better to fail sooner and then recover than to take forever and still not pass!

Conclusion

I am a firm believer in forming good habits and working hard while I work. Habits get us further than goals and deadlines. I have found an intentional study process that works for me. Your will look different, but I hope this and other testimonies will give you some guidance for how you can develop your study plan and accomplish your goals. Feel free to reach out to me with questions or suggestions!