The 129 interview assessment for Launch School is a different experience from the 109 interview assessment. Many of the same principles apply: be professional, practice as if you were taking the interview, use precise language, expect the unexpected, explain what happened if you get an error, etc.
But the format is very different. You will be provided concepts that you have to explain using code examples, and you will be expected to explain and/or debug problems. I will go through some general tips first, then give some tips about what to expect for each of these parts specifically.
The interview assessment is the spoken version of the written assessment, just trickier. For some people, this means they feel ready to take the interview assessment fairly soon after the written assessment. Since I am an internal processor, I had to drill and practice talking out loud through all the concepts from the written assessment. Apart from going to peer-led and TA-led study sessions, I also recorded myself talking through each concept and question. Not only did I discover that I had some too-long pauses in my explanations, but I also discovered that my computer mic was cutting in and out — good to know!
I made it a point to practice like it was an interview. I did this by using a Coderpad sandbox (to get used to details like closing out parentheses, which my regular code editor does for me) and recording myself every time. I also used other students’ notes/questions to practice answering questions worded differently from my own questions (and to help you practice: here are my questions).
The first part of the interview is answering open-ended conceptual questions using code examples. They say to practice doing this like you are teaching someone else about the concept. It is a good idea to prepare code examples for every concept that you studied for the written assessment, and practice typing out these code examples. I used many of the same ones I had written while preparing for the written assessment — no need to reinvent the wheel here.
I loved being able to follow the PEDAC process in the 109 interview because it gave me a plan for what to say next. But for open-ended questions, how would I go about explaining the concepts? When I first started preparing, I tended to jump to writing a code example first, then revealing the principles behind the example. I liked having something on the screen to explain.
However, I learned from other students that in most cases, it is a better idea to state what you know about the topic in general terms before explaining it with an example. Don’t save the best for last. Prove right away that you know exactly what you are talking about. This might sound obvious to some people, but for my brain under stress, rational logic goes out the window. I needed a clear plan, a roadmap to follow. Here is an acronym I used to remember how to present information: TEA.
Tell ’em what you know. In a high school English class, this would be the equivalent of a topic sentence. Clearly outline the key points related to this topic and define any terms right away. Since I needed something on the screen to help me remain focused and grounded, I wrote out major terms in bullet points at the top of the screen and commented them out.
Example. Set up the code example and explain in precise language what you just did. You don’t necessarily have to talk while writing the code example — I am particularly bad at this kind of multitasking. I prefer to explain what I was going to do and then type, or type and then explain. For example, “I am going to write a class definition with some instance methods and instantiate a new object from that class.”
Analysis. Using that example, explain the concepts you outlined in your topic sentences. Try to explain only the concepts that are relevant to understanding that topic. Also, verbally note any exceptions or “gotchas” in general terms. Ask the interviewer if they would like to see an example of this exception. If you feel like your explanation is a little sparse, you could relate this concept to its importance for OOP in general.
The other half of the interview is based on problems. There are several types of problems:
- Without running the code, what will this output and why?
- What will the error in this code be, and how can you fix it?
- Make this code output the expected value, but you can only change [change criteria].
- Is this possible? Why or why not?
These are hard to prepare for because you have to expect the unexpected. However, it comes down to developing our creativity and curiosity muscles. These are learned skills, and I improved drastically in the past two months in learning how to exercise these muscles when thinking about OOP concepts. Here are some ways to build up these skills:
- Study with other students. We all ask different kinds of questions: why is this possible here? Why doesn’t this work? Is it possible to…? Creativity is about making cognitive connections between topics in new ways, so studying with other students allows us to see new perspectives we haven’t seen before and gives us the chance to challenge our personal understanding of topics. Practice giving another student a twist on the problem: what will happen if we do this..? If you can start to see potential twists, you can learn how to spot something unusual during the assessment.
- Combine topics. Is it possible to make methods in a module private? We know how
superworks in class inheritance — what about interface inheritance? Is it possible to have one module inherit from another? Take two topics that seem unrelated and see what happens if you try to mix them together.
- Practice thinking of multiple ways of doing something. Try to solve problems using two different techniques. Imagine that the interviewer asks you to solve this problem, but you’re not able to do it using the typical way of doing it — how would you go about solving the problem?
The other important skill to practice is talking your way through a problem. Similar to explaining problems in both the 109 and 129 written assessments, it is a good idea to talk through the problem by explaining what is happening based on what is happening in the public interface first, then going through the class or module definitions step by step using details specific to what is happening in the public interface. For example, looking at the problem below, let’s say you are asked: what is output by the code on line 8 and why?
- Point out module or class definitions: We have a class definition, as indicated by the keyword
classand the class name
Student. [There is no need to go into the details of the class definition yet, just point out that it’s there.]
- Describe what is happening in the public interface: On line 7, we instantiate an object from the
Studentclass by initializing a local variable and assigning it to the return value of calling the
::newmethod on the
Studentclass, which is an object. We pass in a
Stringobject to the
::newmethod as an argument. The
::newmethod triggers the constructor
#initializemethod, which is defined with a parameter, local variable
name. This local variable is now referencing the
Stringobject with the value “Megan”. Within the constructor method, instance variable
@nameis initialized and assigned to the value referenced by local variable
name, “Megan.” On line 8, we call a
namemethod on the object referenced by local variable
- Answer the question: On line 8, when we call the instance method
nameon the object referenced by
student, the program will raise a
NoMethodErrorbecause we do not have an instance method called
namedefined in the
- Identify key principles: We might expect to see a return value of the
Stringobject with the value “Megan”, but we don’t have access to this value from the public interface because this value is referenced by an instance variable, which is encapsulated as part of the state of the object and not available to the public interface because of its scope.
- Identify solutions: We could change the code to output a
Stringobject with the value “Megan” by exposing a getter method to the public interface, which will return the value referenced by
@name. Ruby provides us with two ways of doing this: defining the getter method or calling the
attr_readermethod and passing in the
:nameto it as an argument, which is Ruby’s syntactical sugar for writing getter methods.
- Ask if you should demonstrate or explain more. Would you like me to demonstrate how to define a getter method or explain something else more in-depth? [They might say no.]
I realized when I was practicing that sometimes my brain likes to talk through whatever’s first on the screen, but it is easier to talk through a problem like I described above. You can focus on what is important and you don’t have to worry about wasting time talking about methods or details that are not actually relevant to the problem at hand. [This example is easier than what you might expect on the assessment.]
For my own assessment experience, my interview lasted about 40 minutes (unlike Gooi, who took 25 minutes — based on what I hear from other students, I definitely took a little longer than normal). During that time, a Texas-sized thunderstorm appeared out of nowhere and caused the power to go off. I waited several minutes for the internet to come back on. They say to expect the unexpected, but I definitely did not expect that. However, I was still able to complete the assessment calmly. I credit this to the patience of other students while listening to me struggle through subpar explanations, hours of practice solving tricky problems in front of other students, and putting myself in the hot seat when practicing alone by recording myself. My body and brain were trained to deal with stress.
I made several mistakes but was able to recover somewhat quickly and fix what I did wrong. It is less about whether or not you make mistakes and more about how you respond. As the study guide says: “when you make a mistake, we also want to see how you recover — or whether you do at all.” When, not if. They expect to us to make mistakes.
JS track student William talks about collecting unusual problems or concepts to prepare for this assessment. This is a good way to prepare for the interview assessment because you will have a list of tricky problems you can use to talk through while practicing.
The problem sets from the OOP exercises are also good practice: for example, I talked through every problem in the Debugging set, which was very challenging for me. Similar to the 109 assessment, it’s a good idea to push yourself in areas you know are challenging for you in order to practice how you will react under pressure. The point is not whether or not you make a mistake, it’s how you respond to those mistakes and to unexpected problems.
I’m thankful for this chance to practice explaining concepts and solving problems in a live interview assessment. The feedback is invaluable and I know I’ll be especially grateful for these experiences when I have to solve problems in front of potential employers and future coworkers. Launch School provides a unique experience in online, mastery-based learning, and I celebrate the challenges of this assessment because I know that now I’m that much more prepared for my career.