Knowing is not enough: You need tactics too — How to be prepared for Launch School written assessments

In Launch School (LS), we are doing many assessments, both written and oral. They are usually quite difficult, so good preparation is very important.

Many LS students have already published their guides and advice about how to prepare. They are very good and helped me a lot. They mostly stress good comprehension of the subject, practicing, learning above the mere comprehension — learning towards mastery. Of course they are right — the LS teaching philosophy itself is mastery-based, so it has to be required in the assessments also.

However, I would like to concentrate on other ways which can help us with good assessment preparation and execution, not only learning itself. These principles are mostly about tactics, how to handle the assessment itself. I often realized them not before the assessment itself. And that is why I believe they may help other students, not only in Launch School, but everybody who is taking any written exam with open questions/assignments. LS focuses on teaching programming, but except point 1, all principles are valid for other subjects.

I order them here by importance (of course, this is highly subjective), so that they reflect not only their incremental value for me, but also my tendency to forget them. With first things first:

1. Test all the code

Whenever you put three backticks (```) in the assessment form, which denotes that you intend to include longer code, test the code first in your text editor/irb or whatever you use for programming. Do it even if you include obvious, trivial example. Only then copy it and paste into assessment form (paste! — it is important if you do not want to bother with indentation issues).

I suppose it is unnecessary to demonstrate how many spelling, syntax, logical mistakes we can make as beginning programmers. These mistakes are of course directly proportional to the stress level we experience during the assessment itself.

Check for both syntactic and logical mistakes: Run the code. Use irb. Check results and return values. With more complicated code, do not forget to create some (new) test cases, exhaustive (if possible) and covering edge cases.

2. Read assignments VERY CAREFULLY

And then again. Really. Read it. Think first what assignment wants you to do. Think what knowledge it tests. Do not just search for keywords and take other assumptions for sure.

We all rush during assessments because time limit is not very benevolent. However the first place, where it does not pay out to rush through, is assignment text. Its comprehension decides about how you respond and how you respond decides about how you will be evaluated…

So as me not being misunderstood, I would like to emphasize that there are not tricky questions in assessments. But because assessment usually does not have multiple-choice form but wants you to elaborate on the subject, it is very important to understand what should you elaborate about — especially with some broadly defined subjects like “local variables” or “classes”…

3. Read “Study Guide” for the test and practice your answers in advance

This deep truth did not enlighten me at the beginning. It came to me not before later. Here it is:

When study guide emphasizes that test will focus on some subjects, there is really high probability that it will focus on these subjects.

All of important topics which assessment will ask about are listed in study guide. So, before the assessment, prepare/practice your answers: define or explain all the concepts (not only in your head, write it down), create examples to show them in code, think about some short code which will help the subject to stand out and be comprehended.

Written assessments are open book — you can consult your notes. And you can be pretty sure, that 80% of subjects specified by the study guide will be in some form examined during the assessments. It is especially helpful for theoretical/conceptual questions (not coding). Do not start learning to define the core concept at the moment when assessment wants you to do it.

4. At the beginning of the assessment, run through all the assignments and read all of them

Having been encyclopedically answering first question for one hour and then realizing that there are 20 assignments which you should answer in 3 hours, is not the best strategy for success. Getting overview first about what all the assignment are is crucially important. It will help you:

• To utilize time: you will know how difficult are individual assignments, so you can plan for how long to spend over each one. Again, because there are usually no multiple choice questions, it is on your deduction of how long the answer should be: One word? One sentence? Several paragraphs? Only code? Code and comments?
• Also, some assignments can take much longer than others and it is obvious from reading the assignment text itself. Appropriate time planning does not have to be anything elaborative. It runs on subconscious level which just says you where you are and how many and how difficult assignments are in front/behind you. However, you need to load this info into your mind first.
• To evaluate the level of expected details. If there are 30 questions (for 3 hour assessment), instructors will probably expect different level of details than when there are only 3 questions for the same time.
• To get better understanding of what is expected in your answers. Often, assignments are ordered in a way that helps you with understanding what assignments want you to emphasize. Sometimes, you can omit some part from your very elaborative (and time demanding) answering, because you know that the exact next assignment is focused on what you have tendency to describe in your current answer…

5. Answer what assignments want you to answer. When in doubt, aim for more.

Yes, I know, it sound zen-like. But still, however trivial this advice is, I tend to forget it. You may also.

• Assignment is not a showcase of all your domain knowledge. Try to be specific and focus on what (you think) assignment specifically wants you to focus on. Otherwise you will run out of time.
• When in doubt, aim for more. I believe it is better to be slightly more lengthy than overly brief because there can be danger of misunderstanding your answers or of you misunderstanding the questions. When in doubt, if it in fact asks about A, or rather B, write about both. When not absolutely sure that your example will be clearly understand, use two examples etc.
• Everywhere, use short examples to demonstrate your explanations. Your definitions may not be precise, there may be ambiguous without you realizing it. But if you specify one or two examples which clearly demonstrates what from ambiguous meanings in your definitions you had in mind, it will be always positive in your evaluation. (“OK, he is not very good in precise language, however he understands the concept…”)

6. Go in order

With multiple-choice tests, there is often favorable strategy to go through the test, answer the easy questions and later come back to more difficult ones. With LS written assessments (or with any assessment you have to elaborate on the open questions), I would not recommend so. Assignments are naturally ordered by instructor, they have logical sequence, they start with “warm-ups” or more general questions aiming later for more concrete knowledge utilization. Instructors have already thought for us when preparing the assessments. Use it.

Of course, when there is an assignment about which you especially know that it will take some extra time (stress, searching for answers), do not stay here and come back to this particularly difficult task later. But generally, go in order.

That said, the best general strategy with written test-taking (not only in Launch School) is in my opinion not to stay too long with answers. I would recommend giving them just appropriate time, trying to describe only the most important and go further. Eventually we can come back and elaborate them later (see bellow) when we will already have peace of mind that we have covered all assignments already.

7. Keep track of time and review in the end

Have a general notion, where you are (what time it is and how many assignments you already solved/have to do yet). Aim for having all assignments done 15–20 minutes before limit.

I highly recommend spending these last 15–20 minutes by reviewing your answers. It is usually not enough time for testing your code again, but I concentrate more on common mistakes:

• Are my answers understandable? Are they too complicated? Are there unanimous or ambiguous?
• Do I answer to all the specified points in assignment text? (Again, there is not enough time to emphasize this point)
• Are there any obvious mistakes or omissions in my answers?

Plus I try to format the text in better way, so that key points would stand out.

Of course, individual strategies for the order and review can be quite distinct. Somebody can be quick enough to go through two proper rounds (start again from the beginning and elaborate more deeply the answers). That was not possible for me, although I would like to go exactly this way. However, for me as a non-native English speaker, the formulation of answers takes more time and I am glad to finish with the assignments 15–20 minutes before deadline even with only one round of answering. That is why I recommend the following scheme with phase 3 as optional but ideal:

1. Orientation (quick run through all the questions — 5 minutes)
2. Reading carefully (!) assignments and answering them in order just in proper (not excessive) time
3. (Second round of deeper elaborations of your answers — or at least some of the answers — in time which remains)
4. Review (15–20 minutes)

Good luck!