Interviewing at Six Silicon Valley Giants in Six Days: Day 1 @ LinkedIn
A contemporaneous account of my 2018 interview gauntlet. You can find Part 0 here.
The Morning Of
I didn’t really sleep last night. I didn’t sleep particularly poorly, but I woke up hourly and checked the clock to make sure I hadn’t overslept, despite it being more or less pitch-black outside. I decided to pass some time waiting for the continental breakfast to open up by looking at some classic Leetcode problems and similar problems as they popped up (4Sum and its variants, subset sum and its variants). It went ok.
I’m of the mind that a bunch of studying the night before/the morning of has more potential for harm than good; I’m not going to learn anything new (at best, I’d recall something quicker in the interview) and there’s every chance I hit a problem that locks me up and then I feel super discouraged heading into the next day/the interview. I think practicing on a bunch of easy problems would help.
I filled up a bit on breakfast with some very subpar turkey sausage and a yogurt, plus a coffee. I don’t really feel that I need to caffeinate right now, but I’d rather be a little bit more caffeinated than yawning. This is the last I’ll write before I’m out of the meat grinder. As a reminder, if I had to guess, this is one of the interviews I was feeling more confident about, as I believe I have the skillset that they’re seeking. We’ll see how misplaced that confidence soon enough.
My schedule today is as follows:
9:45am–10:00am: meeting with recruiter
10:00am-11:00am: iOS-specific programming
11:00am–12:00pm: speak w/ hiring manager; review career goals, resume
12:00pm-1:00pm: lunch w/ engineer
1:00pm-2:00pm: mobile system design whiteboard interview
2:00pm-3:00pm: algorithmic whiteboard interview
And off I go! 😱
The Interviews
I’m actually writing this the following morning (Tuesday) because I was just so exhausted. As for how the interview went, I’ll break it down piece-by-piece. I will, of course, avoid giving any concrete questions, but I may comment on the difficulty. To “set the scene”, I was put in a small room for the duration of the day, save for lunch. Interviewers would come in and out as their time slot came up.
9:45am–10:00am: Meeting with recruiter
My recruiter ended up being late and I had to text someone to get the ball rolling. It wasn’t a big deal; I assume that the recruiter primarily wants to put candidates at ease as it benefits everyone if the interviewee does well. We eventually teleconferenced and talked a bit about the day ahead until he said he saw people at the door behind me, meaning it was time to pass me off.
10:00am-11:00am: iOS-specific programming
I was interviewed by two mobile engineers on a laptop. I had some starter code and they asked me to develop a workflow that they loosely described. I had to dig a little bit to get the requirements for the screens they wanted, plus I had to wrap my head around some of the starter code infrastructure that I was supposed to use. There were some hiccups along the way; there was no one point in the interview where I was “stuck” in that I didn’t know what to do or how to do something properly, but the starter code had a small, but critical, issue that wasn’t supposed to be there (unless it was some next-level find-the-bug testing and they faked confusion) that cost me a decent amount of time testing.
I plugged along, unable to iteratively test what I had done, but once we resolved the starter code issue, I was able to test what I’d done up to that point. Thankfully, that stuff all worked. Unfortunately, I was only able to get through maybe 60% or 70% of the problem. They saved some time at the end to review different things that I’d done in the project. There were definitely corners I cut due to time; some things I discussed along the way and left comments explaining (i.e. with more time, I’d separate this to another class/enum etc), and some things they pointed out and I explained why my approach was suboptimal and what could be done to improve it.
Overall, I was happy with how this interview went. It’s a bummer I couldn’t get through it all; I don’t think the starter code problem cost me that much time, so I’m not sure what I should improve on in the future to improve my performance there. I much prefer building my UIs programmatically, so maybe that takes a lot longer than people that don’t do so? Maybe a lot of people don’t finish? Either way, both interviewers were very friendly, they both seemed very competent, and I did as well as I think I could have. I’m ok with not doing well in an interview because they’re looking for someone different/better than me, but I’m not ok not doing well because my brain locked down. This was definitely me at normal working pace/ability.
11:00am–12:00pm: Speak w/ hiring manager; review career goals, resume
I don’t have a ton to say about this interview because you’d have to be there to really “get” it. It was very insightful and I had a wonderful conversation about culture, process, and life at LinkedIn. The manager I’d spoken with exhibited the sort of traits I would like in a manager: he was soft-spoken (in that he wasn’t abrasive), but he seemed to have convictions. He spoke positively of his team members at every chance he could get. Lastly, he just seemed to “get it”. The sort of things he looks for in a team or engineer align closely with what I want to be or traits I think that I already show a bit of. We hardly touched my resume; it was far more open-ended than that, and primarily I walked him through what I do now process-wise and what drives me.
I was happy with how I did in this interview, but I don’t think it’s something you can really say you did “bad” or “good” in. You just put yourself out there and provide another data point to the company to see if you’re what they look for in an engineer. I can’t know for certain what that is at this company, but if it’s what they espoused when I spoke to them, I suppose it would go in the “good” category.
12:00pm-1:00pm: Lunch w/ engineer
Not much to say here. I don’t have any stories or information to back this up, but I imagine this interview is a sanity check. I don’t think you can get a job based on a lunch interview in the middle of four technical interviews, but I absolutely think you can lose a job if you’re a rude or hateful person. I like to think I’m neither of those things, so I don’t think my lunch interview will work against me, which is the most you can ask for. The food was good and my interviewer was really cool, for what it’s worth.
1:00pm-2:00pm: Mobile system design whiteboard interview
This was my most exhausting interview by far. It was the first whiteboard interview of the day and it’s a system design interview, which means nonstop talking. Companies want to hear how you think, and interviews like this really dig into that. They basically never end. There are an infinite number of things that can be thrown at you. Once you’re “done”, there’s a new feature added and you explain how you’d do that. I didn’t stop talking for about an hour so I was wiped by the end of it. My interviewer was great to work with on the question. I think we had a really good dialogue throughout about different tradeoffs and approaches. If he didn’t like something I did, he would ask probing questions about it, and usually I was able to communicate deficiencies and suggest alternatives. I think it’s hard to “fake it” in this interview. I was happy with how I did. I don’t think anything stood out to me as particularly bad or detrimental to my case in the hour that I spoke.
2:00pm-3:00pm: Algorithmic whiteboard interview
This is the one interview I was worried about headed into the day, and I’m happy it was at the end of the day. I’m reasonably confident about my iOS and design chops because it’s what I do day-to-day, but contrived algorithm problems are not what I do day-to-day. They absolutely come up, and it’s important that you get them right, but often it’s when I’m building some new subsystem or something. I’m not usually evaluating the big-O of my layout fixes. That being said, I have a decent background (at this point) in the algorithmic field of interviews, so I wasn’t terrified, but I definitely thought it would be my weak point of the day. At a minimum, it represented my highest chance of failure.
My interviewer was very kind and easy to go back-and-forth with. I used Objective-C on the whiteboard but he wasn’t particularly concerned with the language. He explained/diagrammed my problem. I asked a few questions and ran through a few examples to make sure I really understood what he was asking. This, by the way, isn’t just something you should do to “look good” to an interviewer. It’s critical to make sure you’re solving the right problem. After I made sure we were on the same page, I rattled off the ideas that came to mind. I suggested a few algorithms and clarified a few points when it came to how they applied to my problem. Ultimately, after writing the code on the board, fixing issues as I wrote them, and finally running through a handful of test cases (and tweaking a few things), I told my interviewer I was happy. He seemed to agree, I gave him the correct complexities, and we moved on to the next problem.
He drew the next question on the board. I thought it was a simple enough problem to come up with a naïve solution to, so I explained what the first solution that jumped to mind was. He agreed it would work and asked me to improve it (so I didn’t code my original idea). I visualized the problem in my head and followed along on the board and suggested an approach he seemed happy with. Once I told him the approach (I hadn’t written any code yet), he tweaked the problem somewhat significantly. I had seen the second problem before, but he was merging it was the first problem. I told him I somewhat remember the algorithm to solve the second one and I explained how I’d apply it to the first problem. He seemed content, so I began writing my code.
Because I was dealing with multiple problems now, I wrote my method signature out for the root question. I then filled out everything assuming I’d already written code to solve the two problems it was composed of. I asked if he wanted me to write code for both of those. He indicated yes, so I wrote both. There was a small bug that took me 3 or 4 minutes to solve in one of the methods, but ultimately I finished it up and explained the complexities. He said that was all he had for me and I think it was at about 3:00 on the dot.
I either got very lucky in that I barely finished on time or they just ask questions until time is up to see how deep your knowledge goes/where it falls short. Regardless, I think I did well. If anything, it may have been the strong point of my day, although I thought the system design interview went well, too.
Closing Thoughts
Afterwards, I hung out with my brother who flew out to spend half of the week with me to assist my sanity. We hit up a really nice British gastropub in Sunnyvale called The Oxford. I had a drink and some really delicious food. I even indulged in avocado toast! I’m so in vogue. I passed out pretty quickly when I got back to the hotel and actually slept last night.
My recruiter did call me pretty quickly after the last interview (within 30 minutes) to ask how things went. He had told me he would do so, so it wasn’t a surprise or indicative of good or bad news. He said the feedback from the manager was positive and he probed a bit about how I feel about working at LinkedIn compared to the other places I’m interviewing. I told him that LinkedIn was definitely in my top tier of companies and I’d be excited to work there. I know you’re not supposed to show your hand with recruiters to maximize your cash, but it won’t really impact my negotiations, if I have any, later. Maybe they’ll use it against me. I don’t know! I have interviews to worry about. 😬
