The blog ofJonathan Pepin

Getting ready for any tech interview


I just went through the process of getting a new job as a software engineer in the Bay Area and I consider that I've done quite well, despite how nervous I was about it.

Quick stats for context:

Of course this is a very small sample size, but I found more similarities between interviews than expected, while dealing with a broad range of companies (from 150 people to Google, with everything in between).

As a self-taught engineer, I have more practice than theoretical experience, which I consider a disadvantage for interviews, but I've also seen others, with a CS degree and smarter than me, doing poorly in interviews.

This leads me to believe that interview performance is about preparation - and most importantly, the right preparation.

I am writing this post in a neutral, matter-of-fact manner about how I went through the process and what I believe helped me succeed. I am not trying to argue that my way is the only or best way, just a personal perspective that will hopefully help a few people.

I've also done over 300 interviews at Uber, and the process was similar.

Getting ready

While interviewing, you will be going through different rounds, each trying to get some signals:

Ability to code

If you are indeed a software engineer, this should not be an issue for you. Basic coding skills are enough for most interview questions, and the practice will happen as you prepare for solving problems.

Interviews always let you chose your own language, so pick one and stick to it. After a few days of practice, you won't have any issue with the language standard lib and its syntax.

Picking a higher level language like JS, Ruby or Python makes things a bit easier and faster.

Knowledge of CS concepts

This is why most people struggle and say that interviewing is broken - very few engineers work daily on complex algorithms or data structures, so experience doesn't help much here.

Most of your preparation will be about brushing up on (or learning about) the main data structures and their related algorithms.

A strong foundation is important, as this is what unlocks your ability to consistently solve problems by being able to recognise the type of algorithm and data structures required.

Ability to think through and solve problems

A good foundation in DS/algo is important because most problems you'll face in interviews will match one or multiple algorithms.

Solving a problem usually implies recognising what type of data you are working with, the types of structure you can fit that data in and what algorithm to use to process that data.

Once you have a strong foundation, it's all about practice so you get better at parsing a problem's statement and deduct the type of data, structure and algorithm that make the most sense. There are no secrets here - practice makes perfect. There is an infinite amount of problems, but a finite amount of problem types.

For example, if you are asked to find the smallest number in a unsorted list of numbers, you'll probably be working with an array. From an unsorted array, you know you'll either have to sort the array, or traverse the array at least once. Etc, etc.

Ability to communicate and collaborate

The main mistake people tend to make in interviews is to think that the only think they are being judged about is whether they'll be able to find the best solution for the problem, and how fast they'll do so.

That's false. I've probably rejected as many people who didn't find a solution than people who found the optimal solution.

Why? Because despite the fact that we want to hire brilliant people, nobody wants to work with a brilliant jerk.

You are as much trying to show your ability to code and solve problems as you are trying to show that you are capable to work with other team members.

So before trying to look super smart and figure out a solution out of nowhere, take a step back and remember to communicate. It is important for the interviewer to know how you are approaching the problem and what you are thinking.

Saying "I have no idea about...", "Right now I'm not sure how to continue, I'm thinking about A or B...", "What would you do here? I'm not sure between A and B" or even asking for confirmation "I'm going towards A... does it sound ok to you?" will show that you take other people's input as valuable and include others in solutions.

As an example, during a previous coding round, the interviewer asked me to build a live chat server. I had never done it or even thought about it. He mentioned TCP and I knew nothing about it.

I took a deep breadth and said "Well ok. That is going to be interesting. I've never done it and except the fact that it's a transport protocol, I have no idea how TCP works. But we'll figure it out! I'd like to use Nodejs, do you think it will be ok?".

Instead of freaking out, I showed (legit) interest and excitement about learning something new. I showed I had listened by picking on him mentioning TCP. I set realistic expectations by saying that I had no idea what the solution would look like. And I instantly asked for help by confirming my language of choice would be ok, etc. That showed the interviewer that I was humble and able to function in stressful and known situation.

I then started googling "node js tcp server" and found about the Net module. It was then just a matter of working with a documentation. The interviewer helped me a bit and we got something working.

If you don't feel comfortable about thinking out loud or being interrupted when working on a problem, practice it while working on problems. Act as if someone was sitting next to you and make sure to regularly pause to tell your imaginary friend what you are working on.

Ability to design complex systems

This one is trickier to talk about because your ability to design complex systems is directly related to your own experience.

It is helpful to read blog posts and other resources about how some systems are being designed and scaled, but it is very hard to discuss high level designs if you've never done them yourself.

This round is often used as a levelling interview, as it is easier to get signals on your actual experience in working with more complex systems. The expectations will usually be much lower for more junior candidates.

There are some good resources that are helpful to refresh your memory about high level parts of systems design.

Previous experiences (fit)

The other place where practice is usually needed is talking about previous experiences.

We tend to think that this will be a piece of cake, but it's not. Getting asked "tell me about a time you disagreed with a co-worker" in an interview without prior preparation is extremely stressful.

The same is true for talking about a previous project. Some of my interviews were about diving deep into a larger project I worked on (or ideally, lead), and it is very useful to prepare in advance and make sure you are able to talk clearly about the project, its goals, challenges, your role and why it mattered.

how deep to go

You can never over prepare but at the same time don't overstretch or don't get nervous by thinking you didn't prepare enough. No matter how much you prepare you'll get questions that weird you out or that you didn't expect.

You are not preparing for a final exam at College where if you don't know the answer you pretty much fail. Those exams test your knowledge and capacity to learn something.

Interviews are a bit different. With enough of a base, the goal is really for the interviewer to gauge how much you can solve a problem, collaborate, communicate and figure out something you don't know. So it's actually better to train yourself to get into an interview not knowing, instead of trying to do as much as possible to know everything.

Day to day work as a software engineer is more working with the unknown, googling and figuring things out than doing things you previously learnt. This is the signal interviewers are trying to get. It is much more valuable to say that you don't know about a specific solution and then show that you are able to figure it out, then just spit out a solution you memorised.


The main resources I've worked with are

Where to work

Once you start feeling ready to get out there, you need to start contacting companies to actually land interviews.

The first things I want to say is to aim for quality. I've heard people say they've sent out 50 résumés and don't understand why they have such low response.

The other things is, be confident. Other people have said they don't apply to companies they recognise the name, because they assume the positions are receiving more application, hence much better candidates than they are.

Don't do that. Be confident. And be picky.

There are no reasons for you to think you are a lesser candidate than others, and if you'll be spending 40 hours a week at a job for the next few years, you should aim for a company and a role you are excited about. How can you be excited if you only apply to companies you've never heard of?

So first, make a list of things you want in your next job.

For example when I looked, I decided that I wanted:

From this list of requirements, prepare a list of about 10 companies.

You can do some research about what companies fit there, ideally you already know which companies are exciting to you, and if you find more companies, make sure to research enough to be convinced you'd like working there.

How to reach out

Now that you have a list of companies you're truly excited about, contact them.

Use your network. Find people you know on LinkedIn. Even if you barely know them, they'll happily refer you. Their is no negative effect of referring someone bad, and very high upside ($$) in having a referral hired. In most cases, a referral will ensure that you at least get a call with a recruiter.

If you don't know anyone, try to find a recruiter on LinkedIn. It's their job, so they'll be happy to have someone reach out. Send them a quick note introducing yourself and asking for a call.

Recruiter spend their life on LinkedIn trying to find candidates to contact and try to hire. Having someone contact them is like a free lunch for them - they'll reach back to you 100% of the time, even if they don't see fit for now.

planning on sites

After talking to recruiters, finding a fit (there is since you already did your own research) you'll quickly find yourself scheduling phone screen interview.

If you prep'ed well, you'll then be invited for on sites.

On sites are 8 hours of full interviews, so it is very intense and tiring. Ideally keep it at max 2-3 on sites per week. If you are located where you interview, make sure to spread those and not take more than 2.

I had to fly to SF for my on sites, so I packed 5 in a week (Monday Tuesday Thursday Friday and Monday). It was definitely too much.

Although I had offers from the 4 first interviews, I definitely felt exhausted on my 4th interview, and the weekend wasn't enough to recover. My Monday interview didn't go well.

I'd also say that my 2nd and 3rd on sites were the ones that went the best so I'd fit my favourite companies in those slots.

Depending on how you cope with stress, the first one can be a bit harder to warm up and get comfortable.


In conclusion I'd say that interviewing is still a heavy, hard and stressful process, but definitely doable with the correct approach and a good plan.

There a plenty of resources online, such as the ones I shared, and by preparing and practicing you'll find yourself more prepared that the average candidate and impress interviewers. In a few weeks of practice, no interview should scare you!

Good luck :)