Life update time! After three great years at Spring, I’m moving on to my next adventure; in April, I’ll be joining Windmill as their fifth engineer, where I’ll be building cloud-based developer tools, as well as company culture.
The most frequent question I’ve got from people upon telling them this news (after “what the heck is Windmill?!”) is, “How did you prepare for your interviews?” (And all the related questions: “How long did you prep for?”, “What were your on-sites like?”, etc.)
This post aims to answer those questions. Here’s some detail on my own personal interview prep and interview process. Of course, everything here should be taken with a grain of salt, as all of this will vary widely based on you and your skills, the sorts of companies you’re interviewing for, etc.
How did you prep?
The first thing I did (because it felt like the least intimidating way to ease into the job search process) was to update my resume. I made a big list of all the things I’d done at work since I last updated my resume, then went back over that list, pulled out the most compelling and impressive items, and wrote bullets for them. I also got several rounds of feedback from friends and collegues in the tech industry. You can never have too many eyes on your resume.
I also practiced talking about my work and my projects, and answering so-called “soft skills” questions. Cracking the Coding Interview has a handy grid to help you organize your thoughts about your projects:
I didn’t physically fill this out, because I’m lazy—but I did go over all of this in my head, making sure I had an idea of the interesting, challenging, and conversation-worthy bits of the major bullet points on my resume.
I’ve been interviewing candidates at work for 2ish years now, so I have some idea of the questions that get asked in interviews and could think ahead about my answers to those1: but by far the most useful prep I did here was to have people mock-interview me. Having to answer these questions out loud forced me to think about them more concretely, and I could also get feedback on the things that I was saying that were more or less impressive, red-flag-y, etc. (“If they ask you about conflicts with coworkers, tell story A, not story B, cuz in story A you resolved your disagreement, and in story B you were right and your coworker wrong and the system broke because of it, but even though you were right, it still resulted in the system breaking.”)
Preparing YOUR Interview Qs
Another thing worth doing is preparing a list of questions that you want to ask of your interviewers to get a better idea about the company you may possibly work for. The better your questions for them, the more insight you can get into their workplace—and the more prepared you are with these questions, the less dumb you look in front of your interviewer.
I read a bunch of “questions to ask in job interviews” articles, grilled my friends, and put together a big doc of the questions I thought were the most informative. Some useful blog posts on the topic: * https://jvns.ca/blog/2013/12/30/questions-im-asking-in-interviews/ * http://juliepagano.com/blog/2015/08/15/job-search-retrospective/#interview-questions * http://lizabinante.com/blog/getting-hired-without-getting-burned/
To brush up on my algos, I worked through Problem Solving with Algorithms and Data Structures using Python, making sure to ask questions about/dig deeper into anything I didn’t understand. Most of this I skimmed b/c I was already familiar with it, but I made sure to note the architypal problems for each data type (“oh, it’s an X problem? You should use data structure Y!”), and paid special attention to trees and graphs cuz they’re my weak spot.
And then it was just looots of practice problems. Some from Cracking the Coding Interview, some from LeetCode, and as much practicing with friends as I could get. The best is to get friends who actually interview developers, because they know the ins and outs of their questions better, but even just having a friend mock-interview you with CtCI or LeetCode questions will do.
Practicing algos Qs on your own just thinking through the solution, or writing the solution on a computer, is good. Writing it out on paper/a whiteboard is better. Practicing with a person (in a mock interview sort of capacity, where you’re timed, they’re giving you hints where necessary but pushing you to explain yourself) is best.
Like with algos, mostly this was a matter of practice—getting friends to mock interview me with system design quesitons. I also went over some of the systems I built at work and made sure that I understood the technical choices and trade-offs there, so I could talk intelligently about it in interviews.
A piece of advice I got here (which I didn’t end up taking, and it all turned out okay, but I probably should have done this anyway) was to talk to folks at other companies about their system architecture. My Achilles’ heel in system design interviews has always been that I’m only really familiar with the one or two paradigms I’ve worked in—talking to others’ about their paradigms would have been super useful, and given me a lot more ideas to draw on.
How long did you prep for?
I took two weeks off of work around Christmas/New Years, and was doing a bit of prep work every day—sometimes several hours of reading or practice interviews, sometimes 15 minutes researching a company or brushing up my resume, but I tried to do something every day. After that, I went back to my day job and I did a bit whenever I could—some problems on LeetCode in the evening, or a practice problem coffee date with a friend over the weekend. After a few weeks of occasional practice interviews, I felt pretty prepped. My process was pretty drawn out cuz I took my time to find companies I wanted to interview for, set up those interviews, etc., so I would keep doing the occasional practice problem during that to keep in shape, but mostly I felt pretty well prepared.
What was your interview schedule like?
Like I said, I took a while at the beginning of this process to get my resume in order, do some research on companies and write up a big list, brush up on algos, etc.
I lined up a couple of phone screens early to get them out of the way (staggering them so that I wasn’t too absent at work), and punted on the on-sites so I could cluster those around the same time.
I highly recommend having your first on-site (or two) be a “warm-up”: not your dream job, but either one you don’t feel too strongly about, or one that is a real long shot and you’re not really banking on. The idea is to have your first interview or two be a little lower stress and lower stakes. Best case scenario, you get an offer and have more leverage or a fab opportunity you didn’t count on; worst case, you get to ease yourself back into the sometimes-grueling world of on-site technical interviews.
How did you decide where to interview?
The way I decide many other things: I made a big ol’ doc where I kept track of recommendations from friends, collegues, the Internet, etc. I brainstormed products I’d be interested to work on, and places friends had worked or places I’d seen on the internet with cultures that I liked. I looked up the companies of people I enjoy on Twitter and elsewhere on the interwebs. I took suggestions from the amaaazing jobs team at RC.
And then I dug into those companies. Looked for articles on company culture, their approach to tech problems, their thoughts on diversity and whether they had women and PoC on their engineering team/in management, how many blog posts they had by women/PoC, etc. I looked on Glassdoor. If I had friends there, or friends of friends, I reached out to them to ask them if they liked it there. I hit up people in my network (esp. women) for word-on-the-street. And from all that, sortakinda got a picture of these companies and which I was or wasn’t interested in moving forward with.
(I should note that an important part of this process was being clear on what I wanted out of my next company. Having a concrete idea of my own values helped me know what things to look for, which questions to ask, and which things were dealbreakers. It’s worth spending a good chunk of time on this step, as it will inform the rest of your search. In particular, I found Key Values’ Culture Queries a useful place to start.)
Well hopefully, the offers start rolling in! Be transparent with everyone in your interview process about where you’re at (esp. with other companies), what your concerns are, and what you need from them. Stating your needs going in sets a good precedent!
When you start thinking about switching jobs, be prepared for lots of last minute insurance submissions and affair-getting-in-order, and remember to take any relevant documents off your computer/email/google drive, any relevant passwords off your password manager, etc. (Pro tip: if you know you’ll be leaving early-ish in the year, max out your Flex Spending Account and you’ll end up with free money! It’s a good time to buy those prescription sunglasses you don’t reaaally need, but heck, they’re free!)
As for me, I’m taking a month off and chilling, and so very excited about it. And thennnnn… I start my new job!
I’m pretty psyched about this next chapter in my life, and I hope that some of the thoughts above are of use to someone. Best of luck, y’all!
Things like: “How do you learn a new language or framework?”; “Tell me about a time that you failed”; etc.↩