Write It Down — The System That Will Get You The Job Offer You Want

“I had taken plenty of time to prepare, and yet each interview was quite different from one another. With so much variety, how is one to be ready for them all?”

First part: Where I need to face the stressful technical interviews

“Design the whole thing,” my interviewer said, after providing only a brief description of a system. More of a concept of a system. There I was, next to a whiteboard, holding a marker in a nondescript room at a leading tech company. I was ready, though. So I began asking questions and estimating: Numbers of users, size of data, etc. After several rounds of questions and defining my assumptions, I finally had a good grasp of what this system was going to do, and I was excited to begin my design. Then he said, “There are only 5 minutes left.” What!? My heart sank.

Leading up to this interview, I prepared and felt confident. I had reviewed my CS concepts and design fundamentals; I had performed several practice questions; I was familiar with everything on my resume. Yet here I was again, blowing another interview. As a technical lead, I was expecting and had prepared for a difficult and challenging interview. However, what I got in this and other interviews was not what I had expected.

In fact, I had taken plenty of time to prepare, and yet each interview was quite different from one another. Some system design interviews were to design part of a more extensive system; some were to design around specific constraints, while others, like the one above, were very open-ended. Same for coding rounds where questions could come from anywhere, bit manipulation, BFS questions, to solving sudoku puzzles. Same for behavioral rounds. With so much variety, how is one to be ready for them all?

Here are some of the questions I was asked, and the ways I decide to deal with it next time I’ll face them.

“Design a search engine”

System Design question → C.H.E.D.B.: Constraints/assumptions, High-level Design, Estimates, Detailed Design, Bottlenecks

“Tell me about a time when you disagreed with your manager”

Behavioral Question → C.S.A.R.: Context, Situation, Action, Result

“Merge 500 files of integers into 2 sorted files where the smaller half are in one file and the larger half are in the other.”

Coding question → R.I.A.C.T.: Requirements, Ideas, Analysis, Code, Test

The other interviews that I experienced differed in other ways too. Some interviewers ask a lot of questions; some ask very few. Some were nice and while others were, well, not the type you’d want to pair-program with if you get what I mean. Furthermore, some interviews were in distracting environments like open office spaces, while others were in rooms that were too hot or too cold. Some didn’t even have properly working dry-erase markers. There were a plethora of distractions!

Second part: When I had to face to harsh truth

After the interview, I did what anyone would, I complained to a friend.

I complained to her, but this time it was different. She offered to help me out by doing a mock interview with me. So, we set a time for the next day, and I couldn’t be more grateful. She swiped a handful of commonly asked questions from websites like Leetcode, GeeksforGeeks, CareerCup and the next day she interviewed me. I thought I did well, but when we were done, I learned otherwise.

While it wasn’t all bad, she quickly saw some issues with how I was communicating and answering the questions. This part hurt like a punch in the gut. For some questions, I was too vague, while on others my answers were hard to follow because I was skipping around. For example, when she asked “Describe a time when you over-promised but under-delivered,” I ran out of time with my response. Lastly, I misunderstood one question and just kept on talking, and talking, and talking, not ever answering it correctly. I thanked her for the feedback and curled up into a little corner, with my ego crushed. I eventually emerged and realized I had to make some changes.

Third part: When I got over the ego crash and came up with a plan

I came up with a plan. This is the plan that I’d like to share now. From the feedback, I realized that even with all of the practice I had completed, there were several distractions that threw me off. To list a few: Interviewers ask questions, lots of them. I would answer those questions, fall into a different train of thought and not get back to the original point. Some challenging questions got me thinking so much that I lost track of time. For other questions, streams of ideas popped into my mind and I didn’t want to disrupt my creativity. These diversions were far too many kinds of distractions to anticipate.

So rather than try to practice focusing or anticipating all the distractions that may occur, I defined a system. My system involves 3 parts: (1) define, (2) identify, (3) write. It’s a simple system that takes just a little extra preparation.

Define

First part is that for each kind of interview I define the steps that I want to take during the round. Interviews are often broken up into several rounds where each round has a specific focus. I have developed numerous set of steps for different kinds of interview rounds. For example, let’s take my steps for answering coding questions: Requirements, Ideas, Analysis, Code, Test (R.I.A.C.T.). It goes something like this: I define and clarify the requirements, produce some ideas, analyze the runtime and memory complexity, I code up a solution and finally — test. That’s it; those are the steps that I follow for each coding question.

Identify

The second part is during the interview where I begin by identifying the kind of round it will be. Coding, system design, and behavioral are typical choices. When I find that I’m in a coding round, the very first thing I do is to write down my acronym for it: R.I.A.C.T. I explain to the interviewer that I follow a system and just want to write it down to keep track. I then write it down someplace I can see it, such as on the whiteboard or on the paper. Sometimes, interviewers will ask about the system, I then take that opportunity to talk about it and explain each step briefly, they usually are quite impressed. At other times, the interviewers are not interested at all and proceed. Either way, there’s never an issue with writing my acronym down.

Write

Finally, the third part is to use the acronym throughout the interview. Whenever I get distracted, I go back to my system. “What letter was I on?” I might ask myself. After I’ve spoken for a long time and get lost in a train of thought, I look at the acronym. “What’s next? Analysis,” I think to myself. When time is running short and I know I have limited time remaining, I quickly go through the remaining letters that I haven’t done. “Ok, I’ll quickly code and test,” I might say to the interviewer. And so on I proceed, keeping my cool since I’ve taken the time to write it down.

Here is an example of R.I.A.C.T. to the common coding interview question above:

“Merge 500 files of integers into 2 sorted files where the smaller half are in one file and the larger half are in the other.” For this problem, I would begin by writing my acronym and proceed through each. Below I will simply demonstrate how I might approach this problem using my system. Note that this is not meant to be an exhaustive solution:

Requirements and constraints —

Get details about the problem.

• The files are all 5 MBs. Since 5 MB x 500 is 2.5GB then this will all fit into memory.
• Each individual file is already sorted. Great, I can use this fact.
• Values are from 0 to 10000000.

And so on.

Ideas —

Generate some ideas while considering the bullet points above.

• Idea #1: concatenate the content of all files in memory and simply sort.
• Idea #2: load the content of each file into its own array and apply merge sort.
• Idea #3: load the content of each file into its own array and organize them into a min-heap where the array’s first (smallest) value is used to evaluate the heap.

Analysis —

Go through each idea and analyze the performance. Assuming N is the total number for numbers and K is the number of files.

• Idea #1: applying the sort across all numbers can result in a Nlg(N) runtime.
• Idea #2: applying the mergesort will result in a Nlg(K) runtime; however, given that using mergesort, many copies of the array will be needed, then the memory consumption will be large.
• Idea #3: applying the min-heap approach will result in a Nlg(K) runtime; since the min-heap needs only a reference to the array and no copy then we save on the extra space and only need the final array to place the output.

Code —

Pick idea #3 and proceed to code.

• Quickly outline the steps of the solution. I find that this helps.
• Code up the solution as best as you can.

Test —

Assess what needs to be tested

• Check boundary cases. Create a test input for this.
• Evaluate your code and determine if any issues arise. Create a test input for that.
• Finally, pick a test and trace through the code to ensure that it is working properly.

Voila!

When I began this system, my performance improved in a few ways. First, I was better equipped to handle the distractions that a new environment throws at you and refocus my attention on the task at hand. It was pretty easy to jump right back to where I wanted to be. Second, I was far more relaxed and less susceptible to becoming anxious or nervous. My effort went into solving the problems. Lastly, I clearly communicated my thorough process to the interviewer, and that demonstrated how I operate as a software engineer. As a result, the offers began rolling in and eventually I chose GrubHub because they offered the best opportunity to grow professionally and to learn new technology.

This process goes a long way toward helping you to perform the best that you can, and isn’t that the point? Basically, you go into an interview to demonstrate your absolute best in a short period. With this simple trick, you’ll be on your way to show how solid of a problem solver, developer, and generally how effective you are as a software engineer! I hope that you find as much success in interviewing with this approach as I have.

The Author: Jon Marin is a passionate software developer and has over 10 years of experience working on data-intensive applications. Jon is currently an Engineering Team Lead of Personalized CRM at GrubHub. Previously, Jon has worked on large-scale Legal Analytics applications at Bloomberg and real-time Financial Market Data applications at Factset Research Systems.