Tips for interviewing at a large tech company

I wrote about what I enjoyed from interviewing at Spotify, and now I often get friendly emails from strangers asking for tips on how they should prepare for an upcoming Software Engineer interview. I wanted to share my thoughts more publicly — though they aren’t really specific to Spotify, but hold for any larger tech company.

If you have an upcoming interview with the tech company of your dreams, it’s probably too late to benefit from any tips. You should already be prepared for the championships.

If you still have time to prepare, though, here are a few recommendations.

Kick your negative view of whiteboarding

It doesn’t help you to think you’re above whiteboarding. The issue is also not really with the whiteboard. I know that there’s a stigma around whiteboard interviews in the industry; ignore that shit and keep your eye on the (dream company) prize. Buy into the whole “walk out of interviews that involve whiteboarding,” and you’re going to miss out on joining a great company with teammates that are better than you.

Accept reality, stop complaining, and put your boots on to do some real prep to earn your spot. You’re in competition with the thousands of other candidates who want to be at that company and who will do whatever it takes to get in. It’s kind of like college admissions all over again.

Interview with your dream company last

Don’t make the mistake of having your dream company be the first company that you interview with. You’ll be extremely nervous, under-practiced, and have a lot to lose.

Before you even apply (or if you can delay the interview by a month), line up interviews with other companies that are interesting, but where you wouldn’t be crushed if they rejected you. It’s hard, for me at least, to fake enthusiasm, but do your best to at least get a phone screen for practice. If you can convince them to give you an onsite, awesome! The onsite interview is the championships — with real stress, real people judging you, and real interview-level of difficulty programming problems to solve.

This likely applies in sports, but if you want to win the championship match, you can’t buckle under the stress of the championship match. You have to be practiced and confident enough to know that you can win.

Interview with your dream company last — when you’re no longer nervous, when you have several “gauntlets” (all-day interview loops with big tech companies) under your belt, when you’re excited to see what they’ll throw at you (since it’s another opportunity to improve), and when you understand yourself (your problem-solving approach, limitations, bad habits, and strengths).

You need to take that interviewer on your journey. Be confident, polished, and put on a great show.

Set up mock interviews with friends

This is more like the playoffs than the championships: you don’t have as much on the line, but it’s still stressful and close to the real thing.

Interviewing with your friends gets the jitters of being judged out of your system. You’ll want to impress your friend and not look dumb, you’ll want to continue to improve your skill at solving foreign programming problems, and they’ll have different styles and experience levels to administering a programming interview. The variation in interviewer style here will be good for rounding out how you perform with various audiences.

Interviewing is a performance art — much like playing an instrument on stage.

If you’re like me, you won’t want to “burden” your programmer friends with mock interviewing, but there will be a time when they’ll ask the same of you. They’ll also benefit from additional practice as an interviewer — which is another art form of accompanying/helping someone in their journey through a solution space.

Practice at home

You need to be critical of your skills with an eye for improving your problem solving approach. You need to fill the gaps in your knowledge.

Not comfortable with binary trees (because you’ve rarely used them)? Work problems with binary trees and have that tool in your toolbox to help you in future work. Don’t just accept the fact that you don’t fully understand binary trees or a particular algorithm, patch that hole and get familiar with it. It’s not wasted time, that material doesn’t ever change and you’ll be able to see problems in a different light with that additional perspective at your fingertips.

The more you practice at home (with careful self-reflection of what you did well and where you stumbled), the more likely you are to no longer be afraid of the problems you’re given during the interview.

As an aside, it really sucks that you need a certain level of privilege to have spare time to do this prep work. I hope we find a better path forward.

Focus on the language, not the frameworks

You need to be able to think in terms of a programming language. It’s fine to use helper methods if you don’t remember part of the standard library, but you shouldn’t be thinking about how to express your thoughts in the language on interview day. You shouldn’t be thinking about the programming language, you shouldn’t be thinking about your body language, and you shouldn’t be thinking about how a data structure works. You should be at a level of practice where you only need to think about the given problem, its constraints, and coming up with a few solutions.

I also see a lot of programmers spend years of their career only working in higher layers of abstraction (frameworks, libraries, abstractions specific to your project) and never spend time exploring and understanding the surface area of their most familiar language. If you think that you can improve your skill by learning the hottest new framework, you’ll probably fail the interview.

Postpone your interview, study your language, solve more problems in that language, and you’ll have increased your chances of success.

Focus on your performance, not your portfolio

Your portfolio only gets you an interview, it doesn’t get you the gig. A lot of people feel that whiteboarding is beneath them because they’ve built so many amazing things.

The issue, from an interviewer’s perspective, is that only the end result is visible, not the process you went through to craft the result. Did you code and pray the entire time (rewriting parts of the project many times over)? Did you collaborate with someone who did most of the work? Did you copy/paste code a lot of code from the internet? Did you base your work on another project that did the heavy lifting? What are the trade-offs that you had to make and were you aware of them?

You can glean some of this from the commit log (assuming that’s coherent), but an interviewer doesn’t have all day to prep for their session with you.

You need to spend time improving your performance on programming problems, or you’ll fail the interview.

Know how to articulate why the company is your dream company

If you come off as just looking for a job, you’ll fail the interview. You need to be passionate about some aspect of the company or one of its products. Do your homework on the company and be able to let the interviewer feel your passion for wanting to work there.

I think cover letters are a great exercise in formulating an answer to this.

Best of luck to you

I hope the above tips have been helpful to you. You most likely only get one shot at that company (or likely one shot a year) — make it count and show them your skill.

If you have any questions, feel free to reach out to me @mrjoelkemp.

Best of luck in your job search!