Managing Anxiety in Launch School Assessments

How to confidently navigate the RB109 assessments.

All my life I’ve experienced anxiety when preparing for tests. My fear is that I will have somehow studied the wrong material, make a fatal mistake, or just not measure up. This has especially been the case in my journey through Launch School’s assessments, specifically because they set high standards for their students. My anxiety has declined considerably with subsequent exams, but those first two were certainly intimidating because I didn’t know what to expect.

Despite my worry, I managed to pass both exams…but I can’t say that I went in to either of them with dry hands or a resting heartbeat! Even deciding when to take each assessment was difficult. How would I know if I was ready? What if I fail? Will I freeze up during the interview? Do I need to do more coding challenges?!

So many questions rifled through my mind and it seemed easier to put off taking an assessment in the name of studying more.

If you can relate, I want to offer some thoughts on navigating the RB109 assessments. Rather than simply completing an endless series of coding challenges to rack up more experience, I would recommend thinking through a strategy for taking the assessments and focus all of your attention on practicing that strategy. Completing coding challenges won’t necessarily make you good at solving problems. Practicing problem solving techniques will absolutely make you better at completing coding challenges though.

When I was studying for the 109 Interview, there was a point when I was working on a code wars kata that was very difficult for me and was unrelated to anything Launch School had taught — it hit me then that this problem was actually a waste of time for the interview. I wasn’t learning how to solve problems because I was practicing poor problem-solving anyway. Around that same time, I coincidentally read a post in one of the LS Slack channels about how the exercises from RB101-RB109 — Small Problems were all you really needed to prepare for the assessments. It was one student’s opinion but I found the argument compelling. At that point I started working through the medium level exercises for a second time, solving each one of them in as many ways as possible, but also practicing PEDAC and the strategies I bring up below.

My strategy for test taking is really a personalized implementation of the PEDAC process, which in my mind is simply a series of steps to plan out a method of solving a problem. It’s helpful to structure your thinking when tackling a difficult problem. However, I have seen some students over-emphasize PEDAC to the point that it ends up creating a lot of unnecessary work and defeats the purpose of systematically solving a problem. Just remember that PEDAC is a tool made to serve you in solving problems; you were not meant to serve the almighty PEDAC.

Consider this: What is the least that you can do to sufficiently solve the problem?

For some of you “the least that you can do” may mean you actually need to do a lot more in terms of developing systems for problem-solving. For others it may mean you need to think through why each step of the PEDAC process is helpful to determine which areas to utilize more/less for any given problem. Something that has helped me with this balance is an axiom I learned from a long-time mentor: organize just enough to get the job done well.

Friends have occasionally remarked that I am “very organized”. However, there are several areas of my life that are disorganized. Instead of an “organized person” I would say that I am “a person with disorganized thoughts who leverages organization techniques to achieve success.” By asking myself questions and structuring my thoughts, I can develop a plan. With a solid plan, I can build confidence in my ability to perform well on the assessments.

I’m going to share my own systematic approach to the two assessments from RB109. There are already several great articles on studying for these assessments so I’ll primarily focus on creating a plan for taking the assessments. I’ll assume that you have a sufficient understanding of the material. And I’m only going to talk about these two assessments because the principles aren’t specific to any one assessment.

General Approach

It may help to think of this as a list of instructions that you can simply follow without having to think about it. Deciding on this ahead of time frees up brain power to focus more attention on answering the current question rather than constantly figuring out your assessment flow in the back of your mind. However, only do this as much as you need to. This is just another tool that you can use.

Some of the trouble is you don’t know exactly what to expect so your plan needs to be dynamic in nature and involve conditional steps. I’m going to share my plans but you have to keep in mind that your plan needs to be custom fit for you. The more you practice your strategy, the better sense you will have for what it should be exactly.

109 — Written

Steps:

1. Give only what the question is specifically asking for. I had heard/read about several people spending too much time on the first few questions which made them feel rushed near the end to finish within the time limit. To avoid this, I decided to be very careful to not over-answer any questions. My goal was to make sure I answer every question succinctly. Then if there is any extra time, I had the option to make another pass to edit/fill in my answers more thoroughly if necessary. And following these strategies has allowed me plenty of time for a complete second pass on every assessment I’ve taken so far (I’m currently in JS210).
2. As the 109 written study guide recommends, “when answering the questions, you should:”
   — Explain your reasoning with reference to specific lines…
   — Answer with extreme precision…
   — Highlight any specific syntactical conventions or technical observations where relevant.
   — Identify the key fundamental concept or concepts being demonstrated in the question.

I tried to make sure I ran through this list each time I answered a question. In fact I had these four bullet points listed in a text document on another screen while I was taking the assessment.

During the second run through the questions, I would highly recommend that you pause and ask yourself, “Is there any aspect of the question that I failed to answer, either because my response is incomplete or off-track?” You don’t want to accidentally leave out part of the answer just because you overlooked a small detail of the question. I know from experience!

109 — Interview

I spent quite a bit of time practicing solving challenge problems with other Launch School students. The greatest benefit from this was hearing their feedback of how I could improve. The best feedback I got came from those I spent the most time studying with because we were comfortable enough to be honest with one another.

Nathan Worden and I have spent countless hours studying together at this point. The two most memorable pieces of advice he gave me were to:

1. Focus on giving the interviewer a good experience. The basic point here is remember that you’re talking to another person who only knows what you say out loud or type in coderpad. So what do you need to say out loud to take them along with you through your thought process? What do you need to type so they understand your thought process? Keep them engaged by providing necessary information, but don’t talk so much that it’s potentially confusing or boring. Don’t talk just to fill the silence. It’s okay to have silence at times, but inform the interviewer that you are taking a moment think. Ultimately, if you practice establishing the interviewer as your focal point, you will prepare yourself for those future job interviews.
2. Say what you’re going to do. THEN do it. Try to avoid talking and typing simultaneously. This normally results in slow, clunky thinking. It forces your brain to do too much at once (thinking, speaking, and typing). Instead think silently in your mind, speak the thought after it has fully formed, then type it into coderpad. This is especially relevant with pseudocode as you try to reason through an algorithm! You may feel rushed and subconsciously start multi-tasking. If you catch yourself doing this, STOP and slow down. I promise, if you prepared enough for the assessment, you will have plenty of time. I went incredibly slow to avoid mistakes and still finished in 25 minutes.

Steps:

For me, I knew it was going to be really important to go slowly through these steps so that I don’t accidentally transition to autopilot mode. Focusing on a slow pace, allowed me to be mindful of what step I was on and what step was next at any given moment.

1. Read the problem out loud (allows the interviewer to know what you’re doing), as slow as you need to in order to comprehend. Reread anything that doesn’t make sense at first and I would even encourage you to read through the entire problem twice.
2. Read through all of the test cases (again out loud) and make sure you understand what they are testing for. Save yourself from being surprised by the infamous last test that includes an edge case.
3. Ask the interviewer any questions for clarification. If you are even remotely unclear about something, just ask. You won’t regret asking for too much clarification. The goal here is to be 100% confident of what is expected of you.
4. Ask if you need to create any additional test cases. If you do, what are some reasonable input values that might cause problems? You might want to wait until after you’ve solved for the provided test cases if you are going to add any additional cases. Also if the interviewer says you don’t need to add any, then don’t.
5. Read through the problem again, summarize the key points as succinctly and specifically as possible. This is for your reference so you don’t have to look back at the problem again — it’s a lot easier to look back at an organized list of bullet points that you created compared to a paragraph of bloated information written by someone else. I like to make note of:
   — the input type(s)
   — the expected output type
   — what data structure(s) may be required to convert the input into the expected output?
   — any rules, constraints, conditions, edge cases, or other important details
6. Write pseudocode for your algorithm. Before moving to the next step, I highly recommend that you try to solve every logical step of your solution. If possible, leave no decisions for later. While this may be difficult, try to think less about specific code and more about logical steps. This will open up different ways of coding it.
7. Finally, code out your solution. And don’t forget to follow your pseudocode! You didn’t spend all that time writing out the logic just to ignore it. While coding, try testing your code nearly every time you make a change. If you insure you get the expected result every step of of the way, you won’t be surprised and finding bugs becomes much easier. Ultimately, you will maintain total control over your program which will impress the interviewer.

Just for clarity I want to lay out where each part of the PEDAC process is implemented in the above strategy. Also remember this is my personal strategy so yours doesn’t necessarily have to be structured or ordered like this. One thing I want to point out is that your use of PEDAC doesn’t have to necessarily be linear, nor does each step require the same amount of time or attention. Your strategy may also need to flex depending on the actual problem.

Problem comprehension: steps 1–5
Examples/test cases: steps 2 & 4
Data structure(s): part of step 5
Algorithm: step 6
Code the solution: step 7

Potential Obstacles

There will be times during the assessments when you need to respond to unexpected situations. This is the part of your strategy that is the most dynamic and you won’t be able to prepare for in the same way. However, you can still come up with a plan for how you will respond to general types of situations. I provide a few brief thoughts on some potential situations below, but I encourage you to flesh out a specific plan or list of ideas that you can implement if any of these worry you. Try to think of other situations that might come up to avoid being caught off guard. Keep note of obstacles that arise in your own study times and think through how you can plan in advance to respond to them.

• You get stuck. Remember the basic philosophy on solving hard problems: try to break the problem into manageable pieces. What’s the easiest piece of logic you can extract from the overall problem? What’s the next easiest? Perhaps the momentum gained from solving one small problem will help you find a flow. Regardless, you can keep looking for smaller pieces to solve separately and put them all together at the end. A few other things to consider:
  — Maybe you need to run your code to see what it does.
  — Test out parts of it in irb to make sure it performs as expected.
  — If there’s something unexpected happening, can you isolate the root cause?
  — Are you still following your pseudocode or did you drift off course?
• You’re having trouble when asked to explain something. What is the main concept? You may need to look back to the lessons, book, or your notes. Ideally, you will have your notes organized so you can quickly find relevant information on any topic related to the course. What part of it do you understand? Perhaps this can provide some context for the parts you’re having trouble articulating or remembering.
• You aren’t certain what a method, keyword, etc. does. Test it in irb. If it doesn’t work as expected and you don’t know how to use it for your solution, drop it and find another way. Your solution doesn’t need to be the most impressive, but it does need to work.
• You find a bug and don’t know what’s causing it. STOP typing. This is usually where you will default to hack-and-slash. Do not allow it. Take a moment to think. Look at your code and reason through the steps. Don’t do anything unless it’s on purpose, even if you are just testing a potential idea (don’t forget about irb). What is actually going on? Find the problem, then find a solution. Remember coming across a bug or getting stuck is not the end but how you handle the situation will tell the interviewer a lot about you. Remember to test your code often and use pry if necessary. Don't panic. The best way to avoid panic is to stop everything for a moment and refocus on the problem.

Moving Forward in Confidence

Taking these first two assessments can create anxiety, especially because you don’t know exactly what to expect. Something I’ve noticed about my anxiety is that it seems to derive from feeling out of control. In developing a structured plan, I gain partial control over an unknown situation allowing me to move forward in confidence. That makes all the difference.