Preparing For My First Launch School Assessment

As a programming student without a background in tech, preparing for my first Launch School assessment was an intense experience.

Take the time to think

I managed to pass both the written and interview portions, but before going too deep into the next steps, I wanted to take some time and reflect on my recent experience. I found some of the blog posts of other students to be very helpful to me, and I hope my reflections are helpful for other students.

The assessment is broken into two parts: The written assessment comes first, and tests your knowledge of theory — expect to give long-form answers explaining what code examples do and why those things happen. Unlike the quizzes, the questions are not designed to be tricky. They target dead-centre concepts that you need to understand fluently in order to progress in your path to mastery.

Don’t think that an emphasis on core-concepts makes it an easy assessment though, because you’re expected to explain the code using an extreme precision of language. You also have a limited amount of time to convey your understanding. I tried to budget and benchmark my time and still found myself listening to my five-minutes-left alarm without having even started the final question. There’s a balance between being detailed and being unnecessarily wordy — if you’re asked to explain what happens on line 6 of the code, make sure that your focus is there, and not explaining everything everywhere in the code example. Also take note that you are responsible for tracking when the 3 hours are up, because Launch School does not provide any alarm or auto-submit at the deadline.

The prep materials provided by Launch School are very valuable. Whatever material is listed as necessary knowledge to move forwards, trust that you will be tested on it. You are expected to know those ideas at a mastery level. I suggest getting practice (and some very useful notes) by going through the study guide and writing out long-form explanations of each concept that is mentioned. Write your notes in markdown format, because that is what you will be doing for your assessment. Don’t try to learn anything or do it for the first time while you’re being tested on it. I originally hand-wrote all of my course notes, but re-wrote them all in markdown format using the very useful open-source note-taking program Boostnote (free). I found copy-pasting this helpful cheat sheet by Adam Pritchard into Boostnote very useful for referencing formatting, thanks to the slick multi-window live-preview format.

Confident that you know your stuff? Try testing your knowledge by writing flashcards using Anki (free). It has a dated interface, but functionally it’s really helpful for exposing things that you think you know, but then find out that you can’t explain when tested.

The second part of the assessment is a whole different animal. A live-coding interview using a combination of audio and coderpad, there is no more hiding behind a keyboard quietly inside your head. I learned the hard way that explaining your thought process while coding is skill that I had almost totally ignored until I began preparation for my interview. Join a study session, don’t be shy and speak about code. If you have trouble doing that (like I did the first time I realized how different it was), then recognize that you’re missing a vital skill that you will be tested on. Remember that you’re in school building knowledge and skills with the end goal of securing a job — which will involve going through the stressful process of interviews.

You’re sharing a path with other people, so make friends

When I realized what a skill-deficit I had, I went to work joining every study session I could, and afterwards asking all students if they’d like to continue holding informal sessions together. If you haven’t attended a session yet, then you’re missing out on one of the great resources available to you.

I was amazed as what a silent response I received to my offers. Out of the four study sessions I participated in, only one student took me up on my proposal. Lucky for me, that student happened to be the student who impressed me the most with her knowledge, skill and precision of language. I don’t think it’s a coincidence. Together we held many multi-hour sessions where we got to expose gaps in each others knowledge, share tips we’d picked up along the way, get comfortable speaking orally about code, jointly solve problems together, and more. During our first informal session we spent a solid half-hour just talking about our experiences going through the program, what led us there, challenges in doing a distance ed program and other normal social student things that humanize the learning experience. Brick-and-mortar students get this by default of being physically present; it’s obvious to them that they’re sharing an experience. We online students too easily hide from each other, and miss out on the humanizing benefits of professional friendships.

Despite my best efforts, I made mistakes during my first few steps of Launch School. I allowed myself avoid using the PEDAC problem solving process for far too long because I found myself able to solve the first few small-problems exercises without it. By the time the problems got more complex I had forgotten to ingrain a systematic approach to my problem solving strategy. I went through most of the 130 or so exercises hacking, slashing, and method-hunting like an amateur. I did learn a lot of new methods, but I didn’t learn to code with intention. I was pleased with myself with some solutions, but they often took me a long time with a lot of referencing and trial-and-error. If you take that approach during your interview, expect to be unimpressive.

It was during my first study session that I realized how sloppy my approach to problem solving had been. I misread the first question, because I only read it quickly due to the pressure. With no pseudo-code to guide me, when my code didn’t function it was a hot mess to try and fix it while several people watched me sweat it out.

Don’t underestimate how much your ability to code will suffer when solving problems under pressure and while explaining yourself. Having pseudo-code is really helpful in giving you a guide, and also to help you break your code down into smaller, more manageable problems. Run your code line-by-line as you implement your pseudo-code, to check that it’s doing what you expect it to do. If you run into a situation where you realize your pseudo-code is wrong, update it before trying to code up your solution. As my confidence increased, I sometimes found myself writing lots of lines of code without testing it, which is awful when trying to find the bug while in the spotlight. It’s challenging in general, so why needlessly subject yourself to it?

If you use Sublime Text as your text editor, there’s a very useful ‘build’ function (⌘b) that will pull up an run your code in the console. Beware of running loops that drain system resources — type ‘top’ in the terminal if using a mac. Sometimes I found otherwise invisible ruby processes running at 50–80% of cpu — they can be ended with $ kill -15 <pid>

Some things take time

To sum up, I found the assessment to be a very good gauge of ability, and there’s no shame in realizing that you’re not ready. Launch School is a mastery program, not a degree mill. Take advantage of the resources and people available to you through school and elsewhere on the web. If you’ve solved all the small-problems several times but still want more practice, try using a site like codewars. Get familiar with writing explanations in markdown format, and speaking orally about concepts. Shake off any vague terminology you’ve become used to, and focus on only using precise language. Practice problem solving under pressure, and coding with intention. Read through the materials several times, and test your understanding in various ways.

*All photos by me