On Launch School Interview Assessments
Assessments train you to understand problems, not memorizing solutions to problem. If you think that you can get away passing a test by memorizing solutions from Ruby exercises, think again.
One of the things that made learning in Launch School unique and more serious is its assessments. Assessments at LS do not only tests your technical capability, but act as a gauge on whether or not your are ready to advance in new course material. As the time of writing, I am currently progressing through course 130. In this post, I will be writing about my perspectives on LS assessments, particularly for interviews.
Initial Anxiety around Assessments
“If you receive a Not Yet on more than 6 times across all assessments in total, you may be asked to leave the program.” — Assessment Rules
My perception towards interview assessments now has changed since the day I started the Prep course. When talking about assessments, I am more relaxed now. In fact in the past few months, I worried a lot when hearing about other students’ experiences on assessments. Reading on students’ honest experiences and especially on assessments and how they prepared for them made me a little nervous when I finally decided to join LS.
While completing course 101 itself wasn’t too overwhelming, there’s a lot to take in when I finally hit the ‘Assessment Rules’ page on 109. Specifically, the guidelines below seemed to be a little jarring to me at first:
- 90% proficiency isn’t enough
- any grade below A- is not an automatic passing
- you may be asked to leave the program if you didn’t pass after 3 retakes on an assessment
The truth is, those guidelines aren’t as scary as they sound, those rules are in place so that you would take learning and practicing more seriously. I remember having to think about how I could tackle assessments, so that I could ease my initial anxiety. To do that, I spent 4 hours per day of studying and waking up at 7AM to practice with a regular student and attended weekly 109 study groups held by Elizabeth (advanced student) or Dalton(TA). I rewrote notes, practiced explaining code with words and articulating code out loud. I also did some practice on Codewars (7 kyu- 6 kyu) as a supplemental exercises before taking the test.
Interview Assessment 109 Experience
To anticipate and sit for an interview is perhaps one the most nerve-wrecking experience. I remember waking up at 6:30AM on the day of my interview test, from a nightmare of being late and unprepared to an interview. I figured out there’s still time to grab some last minute warm-up with Dalton’s study session, so I did. Ironically he’s also my 109 interviewer.
10AM was my 109 interview test. The first question given to me was straightforward, and maybe I wasn’t thinking too much and went ahead with my solution, I forgot to refactor my code. The interviewer pointed out that I left an unnecessary variable assignment, which was embarrassing. The first question was fairly easy otherwise.
The second question however, was not as clear-cut as it seems. There’s a lot of playing around in irb, asking questions and testing around edge cases before I was able to fully grasp the test cases’ return values. Maybe I misunderstood what the question meant, in the first try the output values were incorrect. I took a step back, rewrote some code and accounted different calculations for different inputs. I thought I spent a lot of time on just testing out cases in irb, but nonetheless my solution worked this time.
Before I was able to take my breath and be ready for the third, perhaps the most challenging question, the interviewer announced that the interview is over. No 3rd question? I’m relieved! The interview only took 25 minutes in total, all including receiving instructions, writing and explaining my solution, receiving comments and giving feedback.
That afternoon at 3PM I received my final grade of A+. Chris liked that I spent a lot of time exploring the problem, testing out edge cases and asked clarifying questions. He also felt that I was never out of control despite making some minor mistakes. Seeing that, I know that my hard work of preparation has paid off.
Interview Assessment 129 Experience
Practiced enough in articulating core OO concepts, and you’ll be ready for the interview test. It’s really that simple!
Or it seemed to be what I thought at first, not knowing of any unexpected problem-solving that may come.
Going into the 129 interview test, I was pretty confident that I did enough practice that I can explain any OO concepts well. And indeed, the first part of the test came as expected, and it was done without much effort.
The second part of the test seemed pretty easy at first when I was given some code to explain. However it became complicated when the interviewer intentionally modified the code to raise an error. I was asked to fix the error without removing any of the modified code on the spot. Initially my mind went blank for a few seconds before realizing that it’s nothing that I have done before. After asking some simple questions, I started thinking about ways in order to make it work, despite being clueless on what I should write next.
It took me some pauses and trying out a few things before I finally made it work. Then again, my solution seemed weird. Nevertheless the interviewer confirmed that I successfully solved it. And shortly after that interviewer announced that the interview was over, at the 25-minute mark.
In the end, I aced the 129 assessment but it was close. I realized that I was a lot more anxious this time during the interview, and for a moment I thought to myself, “it’s likely that I would have been stuck and going to have to retake the test again!” The lesson here is that no matter how confident you are going into a test, there’s bound to be unexpected problems being thrown at you. Be prepared to handle those cases under pressure.
General Expectations from Interview Tests
If you are an LS student reading this post, I’d like to share some general tips on how you can better handle an interview test. Please take note that there’s no “one-size-fit-all” approach. Sometimes you have to pick and choose, or even come up with your own that you feel comfortable with.
You will be forced to work under pressure
The reason why an interview assessment is important is because it does not only test heavily on your ability to execute technical skills, but also your ability to work under immense pressure. Such pressures may include: time pressure, being monitored by an interviewer, and the panicking when you inadvertently made a mistake. The key here is having lots of practice and perhaps there’s no way around it. Maybe practicing with other students is a great way to start.
You will be expected to take apart a problem
Assessments train you to understand problems, not memorizing solutions to problem.
In interview assessments, you will probably be forced to deal with problems that you have not seen before. It’s probably a good idea to start to be good at taking apart a problem, testing out edge cases and asking questions to the interviewer. A good practice is to spend a lot of time exploring the problem (using irb / making initial assumptions about the problem) without writing any actual code. Once you have a strong grasp of the problem, implementing a solution will seem a lot easier. Also, you’re less likely to miss out an important detail.
You will deal with mistakes that you have not made before
It may come as a surprise if you made a mistake that you haven’t made before during the interview. And it’s completely normal to be nervous. But the question is, despite the anxiety, what action can you take?
Therefore it’s probably good to learn how to recover from mistakes at an earlier stage. One way which I found extremely helpful is to take a step back and output some values. Maybe instead of running all test cases, you only run one. Or, give a stab at placing some p somethings within your code to output some values. Simple actions such as those can help you see where the code broke and examine why some values don’t return as you expected.
Having a Systematic Approach
LS always talks about ‘having a systematic approach’. But, how does it look like, and how can you do it?
A systematic problem-solving approach means that you have a general workflow that you are comfortable with, and you have an action plan if things go sour (your code crashes, or you get stuck). Generally, you know where to look and have a general idea of how to fix them.
For example, while looping through a hash with nested hashes you were stuck at not knowing how to access those values within nested hashes:
computers = {
dell1: { name: 'Dell A', price: 100 },
hp1: { name: 'HP B', price: 200 },
asus1: { name: 'Asus C', price: 300 },
#...
} # Example of nested hashescomputers.select do |computer, hsh|
# stuck: how can I access the price value within the nested hash?
end
It’s probably a good idea to take a step back, try to access them manually outside the loop first and print out some values before moving on. It may not automatically help you solve the entire problem, but at least you have taken some steps to help you think through what you’re missing and help you unstuck.
Again, there is no “one-size-fit-all” approach. Everyone is different and should only follow any advice if you think it’s a good idea to do so. During problem solving, maybe you are comfortable to do some (or all) of these tasks:
- Writing pseudo-code (or saying out loud)
- Playing around with irb
- Testing out the edge cases
- Solving the problem with irb
- Outputting every single line of code
- Asking yourself questions
- Asking the interviewer clarifying questions
- Taking a step back to figure out where the code break
More importantly, don’t be afraid to spend a lot of time on exploring the problem before coding up a solution in the text editor.
Using irb is often helpful during situations where you are working under pressure. Insights to solutions can come after playing around in irb with some methods and calculation, while trying to arrive at some expected return values. I won’t go into technical details here, but working in irb makes it easier to come out with a logical approach and helps you expose mistakes that you may not have noticed.
Also, asking clarifying questions like “will the input be an empty array”, “does the question want me to do X” or “am I allowed to change lines X to Y within the code” provides better clarity on how to approach the problem more effectively. It also helps you to have a better control over the situation. All of these can help you be more systematic in case of an unexpected challenge that comes up during the interview.
Summary
My experiences with interview assessments have been great. If I have time, I might even write a follow-up post on the less-hyped written assessments. Going through assessments, I was able to see for myself if I actually have a good grasp of the core concepts taught, and whether or not I was ready to move on. Assessments are also critical to test if I am able to learn deeply in order to build a strong foundation towards programming.
Perhaps the presence of assessments have brought students closer together. With them, we are willing to come together to practice coding as well as discuss strategies towards tackling assessments. On top of all, we share our unique experiences on assessments, goals as well as encouraging each other to succeed. Without assessments, our programming journey would have been less exciting.
** This post is written for reference only and not intended as any professional advice. If you find any discrepancies in my examples with facts, or any mistakes within this article, feel free to comment below or send me a message.
