Are you an internal processor like me? 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 resources provided by 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, if you keep talking, it keeps the nerves at bay, at least long enough to get your act together. 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).
The question is: what words can we use to keep talking? This, my dear internal processor, is what we need to explicitly develop: our toolbox of next words.
PEDAC: the toolbox itself
We like to write. Launch School’s PEDAC process gives us the opportunity 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.
Specific tools
Practice talking out loud: as the study guide and others have said, you need to overprepare. At least one time, preferably the first time you go through each Small Problem, you should use the PEDAC process and talk through the whole thing out loud, even the Easy sets, even if it seems like overkill. Remember that you are training your ability to talk out loud while thinking.
Use a template to do PEDAC: 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 will ensure that you have the next words you need to say ready to go.
Writing out the whole algorithm (yes, the whole thing): you need to know exactly 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. This leaves our brainpower freer to problem-solve when issues arise because the coding itself is now just muscle memory based on our already-developed algorithm. [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 a TA-led study session 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 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 solving 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 all small 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 important 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 constantly reminds us to test the code while we are writing it. This keeps easily-preventable bugs from distracting us, and we can keep talking about how what we are writing should work the way we expect it to, and if it doesn’t, why not and how can we fix it (you might have to go back to the algorithm and fix things).
Reread your algorithm as you code: you might think you will remember what to do next, but under pressure, your brain will not work normally. I can’t tell you how many times I had serious problems with my code, only to discover 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 LS students: part of the benefit of practicing with others is that you see new ways of doing things, and you can compare your problem-solving process to your peers’ to form your own list of “best practices”. You can also start to distinguish for yourself when a quiet moment is a processing pause or a freaking-out pause. Ask your study partner 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 breathe and think about why you are really pausing. This will help you feel less afraid of pauses when you are in the interview.
I hope this helps other internal processors like me to know that it is possible to succeed in this assessment and to know that you’re not alone.
Further Exploration
Go through the study guide thoroughly: other students have mentioned the benefits of trying to solve a problem from the videos mentioned in the study guide, watching how the student solves it, then solving it again keeping in mind Chris’ pointers. Here is a companion guide to the study guide that has the problems already written out.
Choose your battles: I personally 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 succinct. Personally, 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 to not learn Regex until after I had passed the interview assessment. You also do not need to know how to do recursion for this 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. This can give us tunnel vision if we aren’t careful, and also negates the benefits of Ruby’s dynamic power.