The Introvert’s Guide to interviewing with Tech Companies

One of my star students is working his way through the high-level gauntlet: interviewing at Apple, Facebook, Microsoft, Lyft… you name it. Interviews at the highest level are exhaustive and will test you on all aspects of development: CS concepts, platform-specific knowledge, team dynamics, your experience. Not only that but they will happen across hours and hours of interviews.

When I did the rounds myself I landed two on-site interviews, one at Microsoft and another at Facebook. Both processes are difficult and grilling. Getting an on-site interview is complex and it only gets harder there. On-site means you get to be interviewed by 5+ people for an hour each, with a lunch “interview” in there, and that’s after several phone and live-coding rounds.

That’s The Interview Game™. At these companies, it’s all about live coding with someone else during an interview. It may be pair programming on an IDE (e.g. Xcode) or you may have to do a whiteboard problem. There is no escaping either.

But what if I’m an introvert/bad under pressure/don’t know a lot of CS…

I’ve consistently heard from voices I respect that interviews in tech are not fair or consistent. They are right. The honest truth is that there is no way to predict how someone will perform on the job other than giving them the job. During the past years a vocal part of the industry has moved away from CS questions to take home projects and “cultural fit”. I believe the latter are much better at weeding out candidates that will not work out, technically or otherwise.

It’s great if you can find a company with common sense where they test you with a take home test or with a trial run, however, while looking for a job you must prepare yourself for a talk and code interview. There is no escaping the fact that the majority of interviews will involve coding with someone else in one way or another.

No way to sugarcoat it: for introverts and people who are bad under pressure, you’re playing at a disadvantage. If you got into programming because it’s your personal exploration space, you’re going to have to share it and sharing such a personal part of you is complex. If you retreat to your PC (and programming) because it became a friend that wouldn’t bully you and would always be there, it’s time to open up, at least for the interview process.

I know how you feel, it happened to me.

The Interviewer

So when you go to these interviews it’s unsettling. You know how to code, so why is it so hard? Because you’ve treated programming as you and your PC against “the elements”. It was always you against the problem. You must come to the realization that during an interview, it’s not you against the problem. It’s not about coding. It’s about getting someone else to like you.

Yes, to like you.

An interview is incredibly difficult because you need to understand what the interviewer wants from you. Yes, of course the interviewer wants to see you code, but they are people and so have visible and invisible biases.

Some interviewers are there to guide you and want to see you succeed. They will help you throughout the interview and will open a dialogue as to where you should go. Even if you get stuck, and they’ve made up their mind about hiring you, they will keep guiding you and rooting for you.

Others want to impress you with their tech skills, so if you don’t know the answer to that stupid “knight dialer” problem it means you’ve failed as a developer and they want nothing to do with you. They may present you with a complicated CS/Math problem and expect you to be able to solve it while describing its Big O notation for both memory and time.

Others are looking to test your skills while under pressure, so they will offer very little guidance and are looking for you to claw yourself out of the pit, even if you don’t get the correct answer. To them, grit is everything and the end result is not as important as you trying you hardest to find the answer.

And the worse kind: the ones that have made up their mind the moment they first interacted with you. Yes, it happens. They may dislike you for a number of things you will have no control over. Those reasons may not be overtly racist or political; think “oh, you haven’t programmed in a real language like C?”.

The Interview Problem

Then we get to the actual interview problem: usually either a contrived brainteaser or a CS problem that involves specific domain knowledge. These problems are easy to find if you prepare using sites like LeetCode or books like Cracking the Coding Interview. They are usually meant to test you on CS fundamentals, most of which are not as important anymore on most programming jobs.

[Yes, I said it. Not that the fundamentals are not important, but that they are less important as they were before. Most people who get into S-Tier companies will not need to know how to recursively reverse a singly-linked list or to reverse in-place a binary tree in O(n) – both obviously vital issues when using Cocoapods or building an API].

Answering these problems with common sense will make you immediately fail the interview. If someone asks you “how fast will this algorithm parse a JSON?” and you answer “I would use Codable and measure it with Instruments” means you lose the game.

Prepare for The Game

The game is frustrating and I personally hate it, but you have to play it if you want to be in the big leagues. So you must prepare for it.

Preparing for CS questions and brainteasers is actually not difficult, it’s just time-consuming. The good news is that there’s so many resources I wouldn’t be able to list them here. Go google “ace coding interview” and you’ll get hundreds of high quality resources preparing you for your next high-level interview.

Preparing for the interview itself is where I can help you. If you are an introvert, here’s the algorithm you need to use during the interview.

How to play The Game

Understand that this is not programming as you know it. Solving the problem is mostly secondary to letting the interviewer know what you’re thinking. First, get yourself a rubber duck. I’m not kidding. It can be any doll, obviously, but don’t think they’re not useful. Find a problem you want to solve and explain the problem as you go. When you get stuck on a problem, you must ask your rubber duck questions. Ask the duck how they would solve it. Restate what you know. Make sure to keep the conversation going, even when it sounds dumb and you keep repeating yourself. The goal here is not to solve the problem. The goal is for you to practice keeping your interviewer aware of your Mental Stack™.

This is a good first step, but it is only practice. During your real interview, you must be very aware of the answers you are given and act accordingly.

For example, did the interviewer seem interested in a certain part of what you said? Dive deeper into that part and test the waters. Maybe the interviewer wants you to stray a bit because they want to explore an interesting subject more than solving the actual problem.

Or maybe they ask technical questions as to the performance or memory tradeoffs? Change gears and instead display the technical side of your mental process. Bring up Big O Notation and a list of algorithms you practiced that are related to the problem at hand. Explain the common pitfalls in this problem.

Finally, and the most important advice, be enjoyable! If your interviewer wants to chat about a topic, listen carefully and ask interesting questions or remark positively on something they said. If what they said is obviously wrong, first prod (carefully!) to make sure whether they hold a wrong opinion or if they’re testing you.

The ultimate purpose of the interview is not to code with your interviewer, it’s to convince them you are the right choice for the job. Usually that means you must focus on the person that’s interviewing you and what they want to get from the interview and not on the code.

Remember, coding is a team sport. Worry about your team first and then about winning and you’ll end up getting hired at the right company.

I write a weekly newsletter with a 15-minute coding exercise, and additional sections like interviews from members of our community. Subscribe to improve your coding skills!