Here We Are Again!

For those of you wondering where the past couple weeks have gone in terms of this blog post, I ended up writing a series on System Design as preparation for an interview I had during this past week!

I'll do a short recap of my interview experience, as that's been what I was focused on during the past couple weeks! I've also been particularly exhausted from studying for 8-10 hours straight for two weeks, so I'm just taking it easy until I hear back!

Interview Application

This was a position that was targeting new programmers, but was about a totally new topic that I'd never heard about: Production Engineering. A couple things I did before I applied was:

• I googled the position to understand exactly what Production Engineering was
• I researched the company (although the company is well-known) and looked at their mission & values and tried to see if they aligned with my core values
• I messaged a couple Production Engineers at the company to get some information on the role and figuring out their day-to-day

I liked the position, the team, and the work. It involved a lot of new concepts that I didn't learn in my bootcamp, but I decided it would not hurt to apply and see what happens! Application Sent!

The Coding Challenge

Now at this point I had been using Leetcode and Hackerrank to practice algorithms. I had been doing easy problems and was feeling pretty good. When I say I was feeling good, I mean I could:

• Understand: Given the problem, I could re-state it clearly for myself to determine what it was asking me to do.
• Diagram: I could draw or diagram the problem on a whiteboard or on my laptop
• Pseudocode: I didn't get excited and try to jump into implementation, instead I could write an english-y version of my implementation that was easy to follow
• Code: I could take my pseudocode and comfortably translate it into Javascript/Ruby.

Doing easy problems let me build the muscle memory of following this process.

Luckily, I had networked with some fellow engineers who advised me to start trying to tackle some medium level coding problems as preparation for any coding interview. Immediately I started hitting road blocks.

I was following my regular process, writing code that I knew was working, but leetcode and hackerrank were shutting down my solutions for some specific test cases. What was going on?

My solutions were timing out (aka taking too long to run).

I needed to learn to optimize my code. This is why everyone on the planet tells you to "learn your data structures". I was using nested for-loops to brute force my way through problems, with a rare application of a hash to speed up indexing. This simply wouldn't cut it for medium problems, and turns out, is partially-acceptable in an interview.

So my strategy changed:

1) Understand the problem
2) Diagram the problem
3) Pseudocode a BRUTE FORCE solution
4) Code your BRUTE FORCE solution
5) Evaluate your solution (what could be improved)
6) Optimize your solution
7) Repeat 5 & 6 until you're satisfied

From my studies, I realized there is so much more to algorithms that I haven't even touched on, but for the most part, I focused on going through this process as I did coding problems.

And Then The Challenge Came

I was sent an email for the coding challenge. I would be given an hour and a half to complete 2 coding problems. I had a lot of practice doing this, so going in I felt pretty confident.

The platform basically worked the same as LeetCode:

• I had a problem laid out with a sample input and expected output
• I had an area where I could submit test cases
• I could run or submit my code

I flew through the first problem in less than 15 minutes, and I decided to annotate my code with comments just to be extra clear!

The Disastrous Second Problem of 2020

I was feeling really confident. I had an hour and fifteen minutes to do a single problem. I dived into the second problem and immediately knew I was in for some trouble. It involved traversing a matrix and determining the shortest route to a specific point considering the values of the matrix. I hit a mental block and minutes ticked away and I felt myself getting more and more nervous. I wanted to get some code on the page and after 10 minutes of thinking, I took the first solution and began implementing it. It didn't take long before I was getting frustrated because my solution couldn't handle edge cases, and I fixing the edge cases broke the other ones. Long story short, I couldn't finish the second problem.

But, in the last 5 minutes of the challenge, I wrote out my full understanding of the problem, acknowledged that I didn't have a working solution, and discussed possible implementations.

I don't know if that played any part in my evaluation, but I passed the coding challenge, barely!

The Interview

I was sent an email with a PDF packet of a laundry list of things I'd be tested on in two weeks. This wasn't to intimidate me, but a LOT of these things I honestly had no idea about. Some of them included:

• Linux
• How to troubleshoot a computer using bash
• How operating systems work
• System Design

and also some things that I was familiar with:

• Coding
• Behavior Qs!

At this point, I knew that if I wanted to really go for this position (which I knew I liked already), I'd need to commit myself to learning some new material for the next couple weeks.

I had a conversation with one of their recruiters which helped me understand what I should target. I found some awesome online resources to learn Linux, the Shell, and System Design and spent the next two weeks immersing myself. I actually learned a ton of interesting things about Linux (the vision behind it, how it works under the hood etc) and got absolutely fascinated with system design. Although learning in an almost academic way wasn't super exciting, I tried to make it fun and informative by doing things like writing blog posts or using useful bash commands to look at my own computer's processes.

I also created a STAR (or SAR) table in Google Sheets to help prepare myself for the Behavioral part of the interview. I also continued with my algorithms to prevent another debacle!

And so I trained for two weeks!

Taking The Interview

Because of COVID, everything as being done online. My interview had three parts, each one being conducted by a separate interviewer:

• Part 1: Linux + Coding
• Part 2: System Design
• Part 3: Behavioral

Part 1: Linux and Coding

With my struggle with the coding challenge at the forefront of my mind, I came into this part of the interview with the intention of taking my time, talking things through, and asking questions before anything else.

We started with the Linux questions first. Some of the questions I immediately knew, others I asked for clarification, and prefaced that I was a beginner to Linux administration. My interviewer was happy to answer my questions and I think my bringing it up was a better alternative than trying to pretend I was an expert.

The coding part of the interview was short. The algorithm felt easy, but as I followed my process, I found myself catching some edge cases (which I made sure to verbalize). I provided a brute force solution, and then evaluated its performance, and provided a "divide and conquer" approach to reduce the runtime complexity. My interviewer seemed pleased with the result, and I left this part of the interview feeling good!

Part 2: System Design

This was a very conversational part. I greeted my new interviewer and we immediately jumped into some basic questions about whether or not I understood the basic parts of a System and then moved into designing and optimizing a system on a limited budget.

I felt like I did very well on this part of the interview for one reason: I did not just provide one answer for each system design question, but I provided multiple alternatives and explained my justifications. I felt like this was the strongest part of my entire interview, and I left feeling awesome!

Part 3: Behavioral

I have one main problem with answering questions: I talk way too much. During my behavioral interview, I was asked some pretty standard questions about my projects and how I handle teamwork. The interviewer did cut me off during one of my answers, which meant I was probably rambling at some point. Nevertheless, I did spend a good amount of time talking to the interviewer and felt like although I could have been more clear, it went well overall.

And Now We Wait

So now after this two week study-pocalypse, I'll be awaiting an answer to see if I made the cut or not! I'm both dreadful and excited, but I was told that in the next couple days I should have an answer. Here's to hoping! Regardless, you'll know the outcome in my next post!

Good luck with your own endeavors!
Shawn