After a solid month of interviews, I’ve gained some insight into the process. Out of 7 companies, I went onsite at 6 and received 6 offers (I epic failed my first phone screen, where I discovered that no, you can not just stroll into an interview with zero prep after two code-free months). Since I have the memory of a goldfish, I’m writing this down primarily for my future self, but hope this helps someone else as well. So how did I study?
Things I did:
Quit my job. This was 100% the most impactful thing I could have done to “study”. Yes, I did forget a lot of syntax over two months of no coding. In my first phone screen, I got the feedback “You don’t need to use Kotlin if you don’t know it well.” OUCH.
But the memory came back fast, particularly when I practiced with the next two tips: Leetcoding and writing a scratch app.
On the pros side, all your raw brain processing power can focus on the interview at hand. Last year, when I was interviewing with a full-time job, I felt like at least half my brain CPU cores were occupied with 1. doing well at work and 2. coming up with legitimate excuses to be gone from work. This time, without those worries in the back of my head, debugging and handling setbacks during the interview were a breeze. Coming up with responses to behavioral questions also went much smoother. Notably, I sailed through an interview where I was thrown into the deep end fumbling with a stack I hadn’t worked with in 5 years; this would have been impossible had I not had 100% of my brainpower available.
Leetcode. Unlike the people in r/cscareerquestions who all seem to do 50 Hards and 100 Mediums over 3 months, I did about 8 leetcode easy and 2 medium questions total in two 2-hour study sessions. Two reasons for the lack of leetcoding: I had gone through a round somewhat recently (when I applied to PlanGrid a bit over a year ago), but leetcoding was also my least favorite portion (I was politely asked to stop loudly cussing in the cafe where I was studying). I think this lack of prep was justified because this skill was only really used in phone screens, and even if algorithm questions showed up later on the onsites, they tended to be weighted less heavily than the other interviews.
Things to keep in mind while studying:
- Understand the algorithm deeply. Be able to teach the solution to someone else, since that’s the level of explaining you’ll need to do in the interview. The solutions posted on Leetcode are godawful because while technically correct they are utterly unreadable.
- Brush up on syntax. More and more companies were asking for code that compiles (thanks to smarter online IDEs that actually run code or screen sharing your IDE), so make sure you actually know the syntax of making commonly asked data structures like sets, lists, maps, arrays, stacks, and queues. Also be aware that a lot of Math operations are not part of the standard Kotlin library so know the imports.
- Lightly brush up on big O. No one asked me to compute it in these rounds, but have a general sense of what’s expensive and what’s fast. Usually throw a map or set at it for amortized constant time access.
Write a sample app from scratch. Almost every mobile position I applied to had a take-home project of “Use an API to get data, which you can optionally persist, and display the data (which are maybe images).”
Creating an app from scratch is a different enough beast from writing code in an existing codebase that you should do it at least once on your own (and the subsequent interviews will act as reinforcing practice).
This also lets you check out the new hotnesses in a safe low-pressure way. While I had touched coroutines, Room, and other new tech at my previous company PlanGrid, this was good for solidifying the understanding in a way that I would be comfortable talking about and using them in a high-pressure interview context.
Additionally, I didn’t end up finishing my app, but it probably would have been icing to throw the source code up on GitHub if I had. All companies want their hands on as much signal as they can get, and if you’re confident that signal is good, you might as well hand it to them to explore.
If I apply to more full-stack positions next time, it would be pretty valuable to build a simple React app from scratch as well.
Mock system design interviews. This is where it helps to have a big engineering network. Promise beer, boba, belay slaving, whatever and however many bribes you need because the difference between a hour-long Youtube video on “How to build Instagram” and a person asking you to design something on the spot are night and day. If your friends don’t have prepared system design questions, ask them to ask you about a feature that they worked on (that’s publicly launched). It is important that to walk through these with real people, since it emulates the real social anxiety of interviews.
These were always my most nerve-racking interviews so to make sure I didn’t panic and go off-script, I stuck to these steps: describe the UI, describe the data models, describe the client-server APIs. I liked going with the UI first, since questions about usage pretty naturally flow when drawing that out. Pay careful attention to any restrictions the interviewer gives you; an app designed to be used mostly offline requires a completely different architecture than one designed for a reliable and fast Internet connection. Common patterns that were good to know about include pagination, repositories, and a process queue for API calls. Incidentally, I received the “Design Instagram” problem twice so walk through that one at least.
Create a good webcam setup. Phone screens especially utilize both webcam and screen sharing often, so either 1. own a laptop that’s powerful enough to screen share and webcam at the same time or 2. have a separate webcam and screen-share the desktop.
Pick out an interview outfit. This might be old-school but I always felt more comfortable interviewing in business casual. Planning out my interview outfit also meant that I didn’t stress out the morning of trying to throw together something. I wore a fairly conservative work dress¹ with low closed-toe nude heels to every interview and light makeup. There is some² evidence³ that the halo effect/beauty bias affects your employability (applies to all genders).
Things I did not prep (but maybe should):
Stories/behavioral interview. Have some stories for some typically asked scenarios such as:
“What was a project you were proud of?”
“What was a difficult project?”
“What was a scenario where you and a coworker disagreed and how did it resolve?”
There are lists of common behavioral questions online so I won’t repeat here. If I was going to formally prep this, I would write out a list of previous projects and write out what signal each story portrayed. For example, the Messenger Codes project shows 1. how I work with tight deadlines 2. how I deal with unfamiliar technologies like JNI and C++ cross platform libraries 3. that I can work ungodly hours if need be. By writing them out like this, you can tailor your behavioral interviews to match the company; I told a work-a-holic team the Messenger Codes story, but avoided it for a company that emphasized their work-life balance. After listing out your stories, you should have at minimum 1. a story that demonstrates your strengths, 2. a story where you messed up and learned, and 3. a story where you had to convince someone successfully and unsuccessfully. Luckily I could draw on both big and small company situations, and your stories should also come as wide of a variety as possible.
The questions that probe weakness are my favorite questions. Do not give BS answers like “I just work too fast and everyone can’t keep up.” Be honest about a time you screwed up, but always frame these as something like “I was a young junior engineer when I committed these mistakes, I saw the consequences these mistakes had, I owned up to them without blaming others, and I had taken active steps to prevent them in the future.” Companies aren’t testing you on how clever of a “weakness” you can come up with, they want to see that in the inevitable case where you mess up, you fess up and make sure it never happens again.
Things to do better in the future:
Get references before quitting. I didn’t realize I needed references since the only companies I had applied to before were mid-size or larger, and they hadn’t asked for references. For small <50 companies though, it is worth the extra hassle to try to gain as much signal as possible. Unfortunately, I got caught pretty off-guard by this and scrambled to contact my old managers and coworkers. This resulted in a pretty awkward interaction where I would send the company my ex-coworkers’ emails, they would bounce, I would find out my ex-coworkers were on PTO, etc etc. This is now on my pre-quitting checklist to ask my manager and my coworkers for their contact information.
Own a laptop. I lugged my Mac Mini to 3 onsites after a loaner laptop died and ate my code. It worked but it always looked absurd. May have helped to stand out from the crowd but not worth it.
Last thoughts:
Overall, I think 7 was a good number of companies to interview with. I did about 2 phone screens a week and 2–3 onsites a week, but I would probably condense my phone screens to 4 a week in the future. I immediately refused interviews with companies that had hints of bro culture or Travis Kalanick. For future interview rounds, I would contact less exciting companies first; I barely squeaked past the phone screen when I flung out my resume early into Plaid’s online portal, not expecting to hear back so soon.
Luckily, squeak by I did; I will work at Plaid as their second Android engineer. Thanks for reading, and I’d love to hear other people’s interview tips!
Part 2: What companies can do to improve their interview processes
📝 Read this story later in Journal.
👩💻 Wake up every Sunday morning to the week’s most noteworthy stories in Tech waiting in your inbox. Read the Noteworthy in Tech newsletter.
