Launch School 109 Interview Assessment: Tips for Internal Processors
Are you an internal processor like me? You might feel overwhelmed at the thought of having to verbalize your thoughts as you solve a problem. I have good news for you: there is hope! You can succeed at the interview assessment! If you practice the right way, you will get better in this area. It takes consistency, a willingness to make mistakes in front of peers, and quite a bit of talking out loud.
I just took the 109 Interview assessment, so these tips are specifically for this assessment with internal processors in mind. Don’t forget to check out the other amazing articles written by students and found on the study guide and the Sharing tab on the Launch School course site.
The interview assessment is particularly challenging because it tests your ability to 1) communicate and 2) problem-solve while 3) under pressure. The hardest part is the pressure — how will you respond if you get stuck?
I used to go quiet when I got stuck, desperately trying to process internally (usually just freaking out). I didn’t even know I did this until I recorded myself and heard how long that “brief pause” actually was (minutes, y’all). I then became afraid of all pauses, even legitimate thinking pauses.
Here is the paradox for all internal processors: even though talking and thinking at the same time is difficult, the best way to remain calm is to keep talking. It is a physical, grounding action that has the spiritual-emotional benefit of keeping you fully present in the moment. You won’t have time to freak out because your brain is too busy producing words (which, as we know, takes up a lot of our brainpower).
In my interview experience, I let the words keep me calm. The words helped prevent me from retreating too far into my mind. The way to recognize when it’s time to stop talking and take a breather is when you start to repeat yourself. I did this in the interview because of nerves. However, I was still present enough to fix my mistake when the TA stopped me and redirected me. This experience was a considerable improvement from when I first began to live code and would become so frazzled I had to physically step away from the problem before my mind could clear up enough to continue.
Of course, in the interview assessment, it is not possible to step away from a problem. You are allowed to ask for a minute to breathe, but you cannot go to the next problem and come back, or walk around and clear your head. You must be present. You must keep communicating.
The question is, what words can we use to keep talking? This, my dear internal processor, is what we need to develop explicitly: our toolbox of Next Words.
PEDAC: the toolbox itself
We like to write, and we love to have a plan. Launch School’s PEDAC process allows us to shine in this area we know best. Those few seconds of silence while typing out our thoughts will give our brains a little bit of a break to recover in between thought-processing. Trust the PEDAC process: it is the toolbox that carries all of our tools.
The PEDAC process gives us our next words. In the assessment prep videos and Watch Others Code videos, most of the students solve the problems without using PEDAC. While impressive, this is not the way we will succeed (unless the problem is very easy for us). We need to have words already there on the screen so we can say them out loud to calm ourselves down when we have a mental block. I recommend this problem-solving video set to improve the PEDAC process and help you build up your repertoire of Next Words.
Consistent practice
Having the right words to say is only a part of the equation, of course. More importantly, you must practice consistently. The muscle memory that is necessary to do well on this assessment is even more critical for us because our brains will spiral into silent-freak-out mode a lot faster if we make a small mistake and can’t spot it quickly. Everyone makes simple mistakes, especially under pressure, but our simple mistakes while coding might make us think something is wrong with our algorithm, instead of just a typo. The more consistently you practice, the quicker you will spot the simple mistakes and learn how to differentiate the small errors from the doozies.
Specific tools to know what to say next
Here is a list of tools to use and steps to follow in order to figure out what to say next when you are tempted to go too far into internal processing.
Practice talking out loud: as the study guide and others have said, you need to overprepare, and for us, that means talking out loud. You should use the PEDAC process and talk through every Small Problem out loud, even the Easy sets, even if it seems like overkill. Remember that you are training your ability to speak out loud while thinking.
Use a template when PEDACing: why risk misspelling ‘input’ or even forgetting an entire step in the PEDAC process? Copy and paste your PEDAC template to the IDE (or use a text expander). This step will ensure that you have the Next Words ready to go.
Write out the whole algorithm (yes, the whole thing): you need to know what is happening at each stage of your solution before you even begin to code. Begin by explaining the problem in simple English, and then break it down into smaller steps. Don’t commit to any specific methods yet. [Note: if you find yourself saying, I think that’s good enough for now, I’ll figure out more as I go — under pressure, it’s not, and you won’t. Attend the TA-led study sessions to see what algorithms should look like.]
Talk through a real test case: our toolbox includes the use of a test case to talk through the algorithm/pseudo-code. Use an actual argument to mentally test out your algorithm by walking through your algorithm and talking about what return value you expect at every step. This checks for problems before they happen while remaining grounded through talking. Also, pick the trickiest test case to do your walk-through, and then walk through a more normal one. Some people solve for the normal test cases first and then go back and work on the tricky ones, but I have found that most problems can be solved by looking at the hardest test case first. The act of deciding which one is hardest has the added benefit of helping you review all the test cases.
Bolster your confidence with small wins: prevent a simple error message => more brainpower to use for talking. Eliminate minor bugs before they occur by immediately closing blocks, writing both opened and closed parentheses (remember that Coderpad does not do this automatically), indenting as you go, etc. Every time you fix small typos/errors while testing, you preserve brainpower that you can use to solve the more complex problems when they arise. Related to this, when errors do happen, make sure to read error messages out loud and explain why the error occurred.
Test the code as you write it, and talk about what you expect: in the Watch Others Code videos, Chris continually reminds us to test the code while we are writing it. Testing keeps easily-preventable bugs from distracting us. Talk about what you expect to happen at every step, and if it doesn’t, why and how you can fix it (you might have to go back to the algorithm to fix things).
Reread your algorithm while writing the code: you might think you will remember what to do next, but under pressure, your brain will not work the way it usually would. I can’t tell you how many times I had serious problems with my code, only to discover later that I had already resolved the issue in the algorithm. You can say: I’m going to pause and reread my algorithm, then read it out loud.
Practice with other students: part of the benefit of practicing with others is that you get to see different perspectives on working through a problem, and you can also see how you work from a different perspective. You can compare your problem-solving process to your peers’ to form a list of the practices that work best for you. You can also start to distinguish for yourself when a quiet moment is a processing pause or a freaking-out pause. Ask the person you are practicing with to tell you when you get quiet (they can say, “What are you thinking about now?”) to help you be aware of your quiet moments. When this happens, take a moment to think about why you are pausing. Differentiating your thoughts from your fears will help you feel less afraid of pauses when you are in the interview.
I hope this helps other internal processors like me know that it is possible to succeed in this assessment and to see that you’re not alone.
Further Exploration
Choose your battles: I decided to focus more on training myself in communication and using PEDAC instead of learning new methods. I know other students who have had great success in learning a variety of new methods that make their code more concise. However, I often forgot how to use those methods when coding under pressure, so I focused on using what I already knew to practice my real problem area: communicating out loud and remaining calm. I decided not to learn Regex or recursion until after I had passed the interview assessment.
The problem with fancy methods is that they give you a false sense of security and can sometimes blind you to an easier (sometimes longer, but sometimes even shorter) way of solving a problem. When we are freaking out, we tend to look for quick fixes. Focusing on a miracle method can give us tunnel vision if we aren’t careful.
A note for verbal processors: it might seem like you have an advantage in this type of assessment, and you do up to a certain point. You will immediately be able to express what the problem is and how you want to solve it, and you will be able to explain what you are doing as you are doing it. However, under pressure, you cannot depend on memory alone to get you through a problem. You will forget important details like how you need to pause and look at test cases, and that great algorithm you said a few minutes ago might get fuzzy.
Your saving grace will be just as counterintuitive as that of internal processors: you must stop talking, which means you momentarily stop thinking. You need to stop your brain from steamrolling through the problem by stopping your voice. You need to breathe — this is your grounding ritual. Only then can you think about the different ways to solve a problem, and you won’t be tempted to commit to something more complicated than it needs to be.
I had a student who was an extreme verbal processor. He would call me over and explain an insightful answer to the essay question he was answering. “Wonderful, write that down,” I told him. A minute later, I would see him staring at a blank page. What happened? “I forgot what I said,” he told me. After several times of this happening, I had him record himself as he talked. He learned how to write fabulous essays.
When the problems have a lot of small details to consider, you must keep a record of your thoughts. You must go back and read what you already wrote. Your brain might only focus on what you are talking about at the moment, so you will have difficulty remembering small details like that you needed to convert that integer into a string, for example. Even muscle memory might not save you here. Keeping a record of your thoughts is a skill that can be learned and must be practiced.
