Secret Sauce Comes in Many Flavors
How Launch School’s first assessments helped me learn how to learn.
To say I was nervous about Launch School’s RB109 assessments would be an understatement. The first time I live coded during a study group I was terrified. I was so nervous that I think I may have spent more time guzzling water than solving the problem. I put off taking both assessments (but especially the interview) for longer than necessary because I was scared that I would freeze in the middle of them and forget everything I’d learned.
During this time, I thought a lot about what helped me prepare and what didn’t. Beyond the recommendations of the study guides, the way we each prepare for an assessment is individualized — any particular study strategy may work well for some and not for others. Just because one person swears by a note-taking app or someone else evangelizes some spaced repetition software doesn’t mean either will be a good fit for everyone. As obvious as it might sound, I had to learn not to be a ‘dabbler’ even when it came to study strategies.
Below I’ve listed the strategies that I found the most helpful during my preparation for both the written and interview assessments. None of these strategies are prescriptive, so while I hope you find them useful, please disregard them if you don’t feel that they would help you — my secret sauce might not be yours.
The Written Assessment
The two key things to remember while preparing for the written assessment are that the time pressure will be real, and that you can forget everything you’ve ever learned about creative writing before you hit ‘begin the assessment’ because you won’t need it here. These are some of the ways I prepared for it:
- I regularly reevaluated my understanding. I wrote a massive cheat-sheet. Seriously — it was nine pages long. I wrote in depth about every key topic listed in the written assessment study guide (variable scoping, truthiness, etc.), then I wrote about the main methods presented in the RB101 course material, and then I went back and wrote examples for everything in code. I went a bit overboard — I even wrote it all in Markdown. However, the benefit of making the cheat-sheet was not in having one, but in repeatedly reevaluating my understanding of the material. Throughout my preparation, I would revisit my cheat-sheet to polish it or clarify its content, but by the time I took the assessment, I remembered everything on it well enough that I didn’t even need it. I could have saved myself a lot of time if I was focused solely on reconciling new information instead of creating a comprehensive, albeit aesthetically pleasing, cheat-sheet that I never used.
- I practiced explaining code. The act of explaining concepts and code snippets to another person forces us to reckon with any weak points in our understanding. While the assessment is open book, there may not be time for that reckoning during the assessment.
- I practiced typing out code explanations under time pressure. Once you have a deep conceptual understanding of the material, honing the ability to quickly write out what’s happening in the code will serve you well. I practiced using some of the questions from this practice document (found in Chris Larwood’s extremely helpful article about assessment preparation). The day before I took the assessment, I did a dry run to make sure I could correctly complete twenty-four questions in three hours.
- I left time to review. During the written assessment, I left about fifty minutes at the end to review. During that time, I made sure to look for any minor errors (i.e. a misnamed variable), and I added content where I felt it was necessary. However, I should have tried to answer each question in my mind from scratch, and then check for any discrepancies between what I thought of and what I wrote. This strategy would have highlighted any mistakes or lack of content by default. I overlooked several minor errors in my responses because I didn’t evaluate each of them with fresh eyes.
The Interview
Looking back, I was over prepared for the interview. The number of hours I prepared, the sheer volume of problems I did, and my Codewars score all point to how I went a little overboard. Like a baby bird jumping out of the nest, we all must learn when it’s time to just go for it. I metaphorically clung to the edge of the nest for at least a week screaming that I’m terrified of heights before I finally took the plunge.
The interview wasn’t as scary as I thought it would be. I’m not sure how I developed this mental image, but I had basically pictured the interview in my mind as a Bond villain sitting on the other end of the call, silently judging me and asking probing questions about every line of my code. It wasn’t like that at all.
My interviewer’s friendly demeanor immediately put me at ease. When I wasn’t actively solving a problem, the tone of the interview was pleasant and conversational. I feel like the whole experience was wholly positive. Here are some of my general thoughts about preparing and some of the strategies that I think helped me the most:
You shouldn’t have to memorize anything
While I was preparing for the assessments, I found that I was really only tempted to memorize something when I hadn’t mastered it yet. While the following strategies might not be right for everyone, they helped me retain the material more efficiently and more reliably than any flashcard app ever has:
- Play with it in irb — Use the method, chain the method, pass an object to the method and note whether that object is mutated by the method. If you’re confused about a concept introduced in the course material (i.e. variable shadowing), try to code an example of the concept. For tricky logical processes, like generating an array of every substring in a string, try coding it from the ground up with the help of the PEDAC process.
- Consult the documentation — If you’re confused about a method, read about it in the documentation, and take note of how this method compares to other methods you’ve used. Think about ways this method could be useful. What kinds of problems could the method be applied to? Every method we see in the documentation is representative of many developer hours spent carefully and deliberately thinking about the method’s name, implementation, purpose, signature, and return value. Why might this method exist in the way that it does?
- Write it out — If you were to post a detailed question in Slack about what’s confusing you, how would you describe it? What examples would you include? List out the things you know and don’t know. Best case scenario, writing about what you’re confused by clarifies something and eliminates the confusion. Worst case scenario, you can hit send and talk it through with others in the Launch School community.
- Simmer responsibly — While letting something confusing cognitively simmer in the background can help lead to a solution, this strategy has diminishing returns. Simmering takes up time that might be better spent live coding or studying, so it’s important to be discerning about when to let something simmer, and when to just ask for help.
Generally, I would argue that hands-on learning (sometimes through struggling) is the best way to cultivate and retain knowledge long-term. Some would claim that memorization allows faster access to concepts in an assessment scenario where speed is critical. Even if that’s true, which I haven’t found to be the case, I would counter that the short-term benefit is a hindrance in the long run.
Memorization does not facilitate the creativity or the adaptability that deep understanding does. Understanding something deeply means that you can recognize what concept is being demonstrated in a code snippet even if the code looks nothing like any code you’ve seen before. It means that when you’re presented with a problem to solve, you’ll probably wonder how you should solve it rather than if you can.
Deep understanding allows us to synthesize information and appreciate the whole, while memorization relegates us to the parts. Deep understanding requires time, determination, and a struggle from time to time, but deep understanding is what we’re here for.
Focus on things you struggle with
Spending time on material you’ve already mastered will only get you so far. While it can be a confidence boost to solve the kinds of problems you demolish in six-and-a-half minutes, you’re not getting much out of the time you spend doing this. Practice like this indicates one of two things: you’re either already prepared for the assessment (and you should just take it already), or you’re focusing on the wrong material. The essence of studying smarter instead of harder is focusing primarily on areas you struggle in. If there’s a Small Problem or a six or seven-kyu Codewars exercise that you find really difficult (even if there are four and five-kyu problems you’ve nailed), spend some time thinking about why that is. Find similar problems so you can begin to work through the confusion and develop strategies for solving similar problems.
Live code at every opportunity
Live code when you feel like it, when you don’t feel like it, when you’re alert, when you’re exhausted, when you’re in flow state, and when you can barely concentrate. Live coding in a variety of different moods and cognitive states will help you cultivate confidence in your ability to perform regardless of the circumstances.
Along the same vein, attend every study group you can. Live coding during a study group can be a lot more nerve-wracking than live coding with another student, and this probably helped me prepare for the interview most directly. Additionally, the TAs have a lot of great advice to give about assessment preparation, study strategies, and dealing with nerves.
Breathe
Before it was time to begin the interview, I took some time to get in the right headspace. I had practiced for hours already; I knew that if I wasn’t ready at that point, thirty more minutes of Codewars problems wouldn’t change that. I sat back and took a few deep breaths. I reminded myself that if this assessment went well, I’d get to explore new material. If it didn’t go well, I would hone my skills some more and I would try again. There is no bad outcome.
If you have any questions or comments, please let me know — I’d love to hear your feedback! If you’re a Launch School Student and would like a study buddy, I’m in RB120 now 🙂 and you can reach me on Slack (@Anne), and if you’re not a Launch School student but would like to learn more, you can do that here.
