First Assessment Experience (RB 109)

Receiving a grade of “Not Yet”, especially on the first assessment doesn’t mean you’re crossed off the list for getting into Capstone. (Whether speaking to a TA or reviewing podcasts from Launch School season two, getting a “not yet”, especially early on in your Launch School journey is not uncommon.)

A different viewing of a “not yet”, rather than as a roadblock, is as a chance to show Launch School how drastically you can improve after utilizing constructive criticism. You didn’t let a roadblock, especially on the first assessment (RB109), stop you from moving forward on your path toward mastery. Instead you took the given feedback, and your personal assessment of your performance and used that to skyrocket your performance on future assessments.

Live Interview Assessment: Take One

As soon as I saw the first problem I knew right away that it was more difficult than the level of problems that I had been focusing on. I expected to struggle from the get go. ( I underestimated the challenge of the live interview possibly due to my past programming experience/my first written assessment performance)

I also made a vital mistake..I misunderstood a key aspect of the problem, and because of my nerves/lack of experience with tougher problems like this going back and fixing it was a nightmare. As my interviewer, Srdjan, was walking me through and offering hints I definitely was experiencing brain block, where I couldn’t think. I was spitting out anything that made immediate sense to me (regarding his hints/helpful questions) to where I basically started guessing (even though I fully understood how that data structure worked).

We ended up getting the problem to work (strong hand holding at the end), but by then it had reached about 55 minutes with no time to even start the second problem.

Key takeaway:

I knew that based on my performance I should not pass, and I would have been disappointed if I had passed.

I ended up not passing, and was actually relieved. This showed me directly that Launch School really values its long term goals for its students to master the fundamentals, over short term goals of perhaps passing everyone (which would keep all students from being discouraged and potentially cancelling their subscription) and making more immediate money.

Live Interview Assessment Preparation, Take One Versus Take Two

I prepared drastically different between takes one and two.

First Pass Preparation:

I only directly prepared for the interview assessment over a short week and a half period after I completed my written assessment corrections and received a full pass on my first try for the written assessment . (Despite this short study duration, I had prepared heavily for the written assessment over a much longer period)

I went back through most of the easy small problems, a few live coding sessions with students, one TA-led study group, reviewing all the material from the launch school study guide. A big part of the study guide that I used was watching the “Watch Others Code” videos. I paused the video whenever a problem was given, and I would solving the given problem. After I solved the problem I would then watch the student progress with their solution. (Even if the video had multiple exercises I would do this for every given exercise).

I spent some time on Codewars, but nothing significant (I’d estimate that I had done twenty ruby problems). I was no lower than 6 kyu, with likely below 300 points.(I have used Codewars in the past with another language, and started LS study prep at 7 kyu). (In codewars having a lower number means more advanced skill, like 6 kyu means more progress than a 7 kyu level).

Second Pass Preparation:

When preparing for my live coding assessment retake, I took the feedback largely into account to focus on problem solving, and to solve 5 and 6 kyu problems (more challenging problems). This time I took almost another month to prepare for the retake.

By the time I retook the interview, I was at 761 points and level 4 kyu on codewars. After working with Callie, I took her advice of how to find comparable problems (https://medium.com/launch-school/passing-launch-schools-first-assessments-rb109-4b2b047060dc) on Codewars, listed under her “Some Final Tips” section. This advice really allowed me an easier path for finding comparable assessment problems because I could search on slack for someone that was in RB120 or in RB109 and then see what problems they had completed (after joining the Codewars Launch School clan).

When I started solving these problems I made it a priority to go back through many of the medium exercises in the Launch School small problems. I also reached out to more students for live coding, for the next month I had at least three living coding sessions a week with students, with sometimes two live coding sessions a day.

I also began attending as many study groups for RB109 as possible. The Sunday before my Thursday interview on 4/16/2020, I was the only student signed up for that study session. I actually got to live code with Srdjan, and I value that experience a lot. It helped me have confidence to actually schedule my retake (at this point it had almost been a month since I had gotten my interview “not yet”). On the day of my retake, I coded a problem live in front of a student in the morning, and attended a TA led study session that morning where I live coded again in front of four students.

Additionally I implemented advice from Nick Johnson’s article, (https://medium.com/launch-school/how-i-prepared-for-my-first-assessment-interview-109-at-launch-school-2a5cd6ba5b92 ), where after solving a Codewars kata I would study a top solution from Codewars and recode it from memory. I would pick either a top solution or a solution from my “Solutions of Users I am Following” (which were only the people from the Launch School “clan”) that wasn’t too advanced for my skill set. If I was not familiar with a method that they were using, I would read the ruby docs, and test out the output or return value of that new method. If a method was concise, like multiple one line blocks being called using the return value of the previous block, I would separate the blocks out, and look at the return value for each (often splitting them into multi-line do/end blocks). This was a great way to introduce different ways to solve a problem. In some instances the only possible algorithm that would appear to me would be a brute force approach; for example: getting all the possible element combinations by using multiple iterative methods. Whereas some of the top solutions revealed a faster path to the solution that I was able to learn from.

The biggest turning point I found to improving my problem solving skills was pivoting how I spent my time while attempting a problem. I greatly increased my time focusing on understanding the problem and reviewing the test cases, thinking through edge cases. Even when I was timing myself and was completing problems in about 22 minutes or less (ideally 20 minutes and less) to prepare for the available time during the interview,, I noticed that the more time I spent on my algorithm paid back big. Even if I spent 10+ minutes or half my allotted problem solving time on understanding/planning (to where I understood as best I could) I actually saved time. Solving harder problems became easier, it was an immediate difference. I was even able to solve a couple 4 kyu problems on Codewars, (although those took me more like an hour to solve). It’s the understanding of the problem, working out the kinks before you tackle the next beast (which becomes even harder if you’re working out logic inside a loop or even two!)

Assessment Take Two Self Review

I definitely came into this interview much calmer. I had just come from a TA led study group where I live coded in front of 4 other students, and had more confidence from both all the additional time I had spent problem solving and from constructive and positive feedback during my 1–1 session with Srdjan.

Surprisingly this interview I had a different TA (Karl) than anyone I had spoken and worked with before from any study group or past interview.

The First Problem:

I still ran into an issue where I missed part of understanding the problem, but I thoroughly ruled out/examined other edge cases. This time I got all test cases to pass except one. I had a mistake that I needed to fix,but this time since I was feeling calm, and after just hearing advice I approached the mistake much better this time (That morning during the TA-led study group Catherine’s advice stuck with me; she said along the lines of “expect mistakes, expecting to get it all right the first time and relying on that is luck”. ) I was able to figure out what was wrong, and explained that the code issues to my interviewer (Karl). I was leaning toward one possible fix, but thankfully my interviewer Karl pointed me toward a way that would be much less headache.

I was very happy to hit around the 30 minute mark and have all the test cases pass and then even have time to explain my completed solution.

The Second Problem:

I did not encounter any mistakes in understanding the core of the problem, which was a relief. I did have to make one fix to account for negative numbers, but the core of the solution was correct so to think of an ideal solution (rather than a solution that would just address the test cases at hand) took some brainstorming and some nudges, but I also solved the final problem.

What a world of difference it feels to solve both problems, with even extra time to explain your solution after you finishing the problem, rather than not even solving one without strong hand holding!

Second Interview Retake Results

I received a conditional pass after my interview retake. This meant that I had improved enough to not need a full interview retake, but that I still had some skills to improve on before moving forward onto RB120. I needed to work on my pseudocode/algorithm skills. For some reason my pseudocode/planning process involved implementation (like concerning what methods to use) AND the algorithm/solution. Before I had thought through my solution, I had already started picking methods and limiting my algorithm to one solution (rather than having it before general enough for it to be solved in many ways).

My “conditional pass” work included grabbing two problems from small problems advanced 1 (I had not completed any advanced small problems at this point). Ideally the chosen problems should have looping constructs involved (the TA’s were very helpful in recommending exactly which problems to choose). I was to create general pseudocode for both problems, and then to code up two different implementations from the general pseudocode (one with iterative methods and one with more basic looping constructs like “loop”, “while”, “until”).

I was pretty amazed at how much easier it was to code my solutions after I had a strong general algorithm. If you find yourself making mistakes, and struggling while implementing the solution into code, I would advise you to take a step back and evaluate whether your pseudocode is closer to an implementation itself or actually a general solution.

After turning in my “conditional pass” work, I received the go-ahead to move onto RB120! Even though I didn’t pass the interview assessment how I would have liked (the first time haha), I know for sure that Launch School doesn’t let you off easy. I want to work through this program and become fully capable of my future role as a software engineer. If the program was “easy” I would be disappointed, and experiencing this assessment process gave me a glimpse as if I was standing on a hill for a moment, and seeing more of the road ahead (challenges ahead) than before.