Yet another guide to tech interviews

This content originally appeared on DEV Community and was authored by rinaarts

This is probably one of the most common types of posts, though sometimes I wonder if you just have to go through it yourself to figure it out. I’m not sure. But in the hope that it helps someone out there – I’m writing up everything I’ve learned about getting ready for tech interviews, I promise these tips are tried and tested and will help you if you read and apply them carefully.

Caveats:

• A few of the insights included in this post are most relevant for “big tech” companies, but most will be useful no matter where you apply.
• I live and work in Israel, so it’s possible there are some culture-specific details that won’t be applicable to your work situation (e.g. like most of the world, we’ve never heard of thank-you notes). Use discretion when applying 🙂

This post is long, so I suggest bookmarking it and reading it in sections. It covers:

1. Writing an excellent CV
2. Coding interviews
3. System design interviews
4. Deep dive interviews
5. Culture fit interviews
6. Questions you should ask
7. Resources

Writing an excellent CV

There are many guides on how to write an excellent CV, and I won’t go into everything, but the message I want to get across is that a good CV tells a potential employer what you can do for them. You want to make it easy for the recruiter to say “I want this person on my team!” and that’s hard to gather from a laundry list of technologies and projects. Focus on skills you have and what you bring to the table as an employee.

My CV is structured as follows:

Basic personal details

Name, email, phone, LinkedIn profile. That’s all. Your address, other personal information or profile picture can only add bias and don’t really add any relevant signal.

Mission statement

Not everyone agrees with me on this one, but I still like to add a short sentence or paragraph about who you are and what you’re looking for. I currently use my personal brand slogan, but most people don’t have one (go figure).

A short, and I mean short – no more than 2 lines long – “Full stack software engineer with 7 years experience, passionate about revolutionizing buzzwords, looking for a position that will make the world a better place” is a convenient way to help recruiters decide if you’re a good fit for the position before they read your entire history, so make it good.

Ask friends to read it and give you feedback on what vibe they’re getting – I once wrote one of these that made me sound like a lone wolf who can’t work in a team instead of sounding independent and motivated. What a miss.

Employment history

I have more than a few years of job experience so I don’t provide full details on every job I’ve ever had. I list the last two jobs and put the rest under ancient history (yes, that is what I wrote) with a reference to LinkedIn for anyone who really cares about where I worked 15 years ago.

When I describe a specific position, I list the skills I used in that workplace and how I demonstrated them. Remember, I want to focus on “what I can do for you” and not so much “here’s a long list of what the job included”. So, something like (OK, this is a real extract from my CV):

Focus on results and customer impact:

I excelled at discovering the essence of what needs to be done and eliminating non-essential features or requirements and even entire projects in order to deliver value to customers with minimal time & effort from engineering. I have successfully used this approach to navigate product, design, legal requirements and resolve engineering conflicts to arrive at the best solution.

This is the type of thing I’m good at as a senior engineer and I’m looking for an employer who appreciates that type of thing. If your focus is more “technological expert” you might want headers like “Problem solver”.

Got any real numbers to share? Things like improved efficiency, KPIs you’ve improved etc.? Include them. If you didn’t actually measure any of this stuff, please don’t invent numbers, if someone asks how you measured the improvement you won’t end up looking very good.

At the very end I add a bit about the technology stack so I pass the automatic filters, because I’m looking for an employer who’s looking for a technology generalist. If you’re an expert in a specific technology you might want to put an emphasis on that. The point is to craft the message so it tells employers who you are and what type of job you’d be best for (and make it match the job you want).

Bonus points

Don’t forget to add any extra-curricular activities like talks, blog posts, open source contributions, mentoring etc. I do this stuff because I enjoy it and vaguely thought maybe someday it would create some startup co-founding opportunity network, but I was surprised at the effect some of these had on potential employers.

Submit

Reach out to people you know, through online groups and other networks and get them to refer you. A referral can really make a difference, even if your CV is far from perfect. Use those connections to get inside info on the process and ask for advice on how to prepare. Most people will be happy to help, either because they’re nice or because of the prospect of getting a referral bonus (or both).

Do yourself a favor and try uploading your CV to one of the HR systems companies use and check how well it can parse them, there’s nothing more annoying than having to fill in a million details manually because you used some elaborate design they weren’t designed to understand. This is especially important if you submitted your CV through a referral, you don’t want to get on your referrer’s bad side by making them enter a whole lot of details manually.

Coding interviews

RTFM

Seriously.

Big tech companies like Google, Facebook and Dropbox will send you a lot of information on how to prepare for their interview process. Read it. The recruiter will call you to prep. Listen to what they’re saying and take notes. They want you to pass. The chance you can pass without paying attention and preparing is extremely low. Take advantage of the resources they offer you.

Coding interviews receive a lot of hate, some of it justified. Unfortunately, no one has figured out a way to assess potential candidate skills perfectly, so we use proxies. Every proxy has advantages and disadvantages, but if you want that job – you’re going to have to “play the game”.

Coding interviews below the surface

Pay attention: even if an interview appears similar, it doesn’t mean it’s actually the same. The coding interviews at different companies test different things even if they all start out with a leetcode style prompt. At Dropbox they start out with a simple coding prompt and then expand on that in a way that’s similar to issues you’d actually encounter at work. At Google they emphasize algorithms and run time analysis. At Facebook they start with an easy warm-up exercise and then move on to something a bit more difficult. Each company has their own interview structure and assessment.

What this means is that solving leetcode (or interviewbit or “cracking the coding interview”) challenges is not enough. You can (and should) practice this type of question, but that doesn’t mean you know how to articulate your thoughts, analyze runtime correctly, or solve more complex problems based on the coding exercise, which is absolutely critical.

In fact, I’ve had candidates who say they “already know this one”, because they’ve seen the prompt on one of these sites – but if they can code it (and unfortunately they don’t always succeed), they’re not necessarily prepared for the next parts of the interview.

How to prepare

Don’t panic!

1. Start by interviewing for jobs you’re not sure you want. Be fair, don’t waste time on a company you’re sure you don’t want to work for under any circumstances, but don’t start with your #1 dream job. Use these interviews to prepare. If you pass and get an offer – great! You might have a change of heart and decide you want to accept, or use it as a counter-offer for another job. If you don’t, you’ve at least gotten some experience interviewing.
2. Do mock interviews. There are sites that can pair you with a mock interview, community groups, friends… Some companies offer them, take them up on the offer! Those mock interviews are golden because they give you insight into what that company is looking for and exact feedback on how you did.
3. If you already work at a company that does this type of interview, join the round. Read the interview guides. Getting behind-the-scenes experience on how the process works takes some of the mystery out of the process helps you reduce stress.

During the interview

Remember to ask clarification questions and share your thought process. Another thing to notice is not to make the problem more complicated than it is – don’t jump ahead into premature optimization before you know what you should be optimizing. The interviewer (usually) knows what they’re doing, so listen to what they’re saying. If they’re trying to point you in a different direction please let them – they want to help you succeed and you’re probably coding yourself into a corner without knowing.

My top absolute #1 recommended guide for this part is cracking the coding skills flow chart which takes you through the coding interview step by step, laying out the expectations from each part and how to get through it successfully. The first time I went through these interview loops I memorized the steps, and it helped me feel more in control – when my mind tried to go into stress mode and black out I would say to myself: “OK, you’ve done Listen and Example, next is Brute Force” and I would be able to get my focus back. By now, after being on the interviewer side of things for a while, it’s just second nature.

System design interviews

I don’t know about you, but this one had me super stressed. System design interviews are one of the main factors considered in leveling, which significantly effects your compensation and role coming into the company.

(Don’t know about levels? Ask your recruiter. Also google it. And check out levels.fyi. It’s important.)

On the one hand, our daily work may already include quite a lot of system design so this should be easy, but on the other hand – most of us are working within existing systems, systems which have already solved most of the basic scale and performance issues so we don’t have to worry about them. The DB is distributed, the servers autoscale, new keys are being magically generated. And that’s the stuff they ask about… So… not as easy as you might presume.

How to prepare

I prepared by reading System Design Interview – An insider’s guide which outlines how to approach system design interviews and a number of basic problems and common practice solutions, as well as common system design interview problems. After that, I followed up with Grokking the system design interview. What I did was look at the problem and write down my thoughts as if I was designing this system. I found scale and performance issues and focused on parts of the system I found interesting. This did not always match the solution they gave, but actually – the solutions didn’t always match the book either! That’s actually expected with this type of interview, there is no “right answer”.

Same advice as the coding interviews applies here – throwaway interviews, mock interviews and join the interview rounds if you can. I used the mock interviews offered by the companies I was interviewing for to practice system design and they gave me invaluable feedback which really helped me improve how I was leading the conversation.

During the interview

The idea in a a system design interview is to work with your interviewer to understand the requirements and constraints of the system and come up with a scalable design that makes sense. There is no correct answer, they want to see how you think. The more senior you are, the more they’ll expect you to lead the conversation.

The weird part was that by the time I got to the actual interviews I knew the common questions so well, I ended up trying to remember what the solution was instead of having working with my interviewer to create a good design. Apparently it worked, but it still felt off, almost as if I was cheating. The only system design interview I felt went really well was Google – where they asked something totally out of the box which really allowed me to think about things I didn’t already know. That was fun and interesting. So if you’re reading this and are in a position to do something about it – I want to ask, for everyone’s good, please stop asking “design Instagram” or “design Twitter” and think of something new.

Deep dive interviews

Unfortunately not all companies have one of these, where you’re asked to present something you built or a project you worked on. And I say “unfortunately” because I’m really good at these. And I think they give some good signals on the candidate – how well they understand what they did, how it fits in with other systems, their approach to working with systems they didn’t write themselves etc.

The first rule of deep dive interviews is “no BS”.

The second rule of deep dive interviews is “no BS”.

The third rule of deep dive interviews is “don’t reveal any company secrets” because (1) that’s not OK and (2) you’ve probably signed an NDA so you’d be breaching your contract. It might also send a signal to the interviewer that you’re not trustworthy. Bad idea.

How to prepare

Choose a system you know well and were involved in developing. If you were involved in the design – even better. Decide where the system boundaries are.

If there are subsystems your system interacts with, but you don’t know very well, that’s fine. No one expects you to know everything about everything, show you know the API and understand how the other system integrates in to your system. If you try to deep dive into the details of a system you don’t know well – it will show and the interviewer will notice you don’t know what you’re talking about. Remember the first rule – no BS.

Practice your presentation with a friend. This will help you discover where you get “stuck” and should dig in deeper, where you’re straying out of the boundaries you decided on and into BS territory, which parts of the system are interesting and which parts are dull.

During the interview

Don’t apologize for what you don’t know. You’ve already decided what you plan to talk about and where the system boundaries are. In a company of almost any size it’s impossible to know everything about everything and still have time to get your own work done, so there’s nothing to apologize for. You can use the word “sorry” if you like, as in “I’m sorry, I didn’t develop that part and I’m not sure about all the implementation details”, but you shouldn’t feel sorry or have it throw you off.

If they insist on talking about something you don’t really know, do not BS. You can say you guess it’s built like this or that or suggest how you would do it if you were writing that component.

Still pushing? Arggg so annoying. Switch into a design mindset and work with the interviewer to design such a system.

Culture fit interviews

The point of this type of interview is to get to know you and assess how you fit in with the organizational culture. I think it’s important to understand how important this match is. A person can be incredible in some work settings and terrible in others, depending on what the organization values and rewards.

How to prepare

The first and most common mistake with this type of interview is to think you don’t have to prepare because it’s not “hard” the same way technical interviews are hard. But you do, because:

1. It’s hard to come up with “good”, representative stories during the interview.
2. It’s even harder to construct a clear narrative on your feet.
3. The same story can be told in a way that makes you look bitter and passive or empathetic and proactive, it’s all about how you craft your narrative. It will be very hard to get right if you didn’t give it some serious thought ahead of time.

I recommend writing down your stories and thinking about the different situations and which qualities you displayed in each. Read about the company values and try to have at least one story for each value (you can use the same story for different values).

When they ask you about a time when you had to solve a conflict or made a mistake or got some tough feedback – you’ll have a story ready. Sometimes they’ll surprise you with some situation you weren’t prepared for, and you’ll have to quickly adjust one of your stories, but at least you’re not starting from scratch.

Get a friend to listen to your stories. As with other interviews – practice makes perfect. Also, they might see things in the story you don’t see and their feedback will help you refine the message or choose different stories.

Questions you should ask

Remember, they are not the only ones interviewing you – you should also be interviewing them. Starting a job and then finding out the organization doesn’t meet your expectations – not fun. You need to interview them to make sure, as much as possible, that you want to work there.

How to prepare

Sit down and make a “wish list” for prospective employers. It can be anything from team structure and release schedule to personal development and management style. Think about everything you do and don’t like about your current and past employers and what you’d want at your next job. You can also google for “questions to ask your interviewer” for inspiration.

Once you have that list, you know what you want to find out. Some things you can ask directly (e.g. do you have an L&D budget? What is your performance review cycle like?). Others you have to ask as an open ended question, or you won’t get a real answer. For example, if consistent and honest feedback is super important to me, I can’t ask “do you give consistent and honest feedback?” because the answer will always be “yes”. I need to ask something like “What is your management philosophy?” or “How do you conduct 1:1s?”.

And the life-hack I learned somewhere (I’m sorry! I don’t remember who told me this): Ask every interviewer what they like most about working at that company and what they don’t like very much. I’m very careful about not using strong words, because people won’t want to share what they hate about their employer, but you’ll get honest answers to “don’t like very much”. This question provide a wealth of information, mostly about things you wouldn’t think of asking.

I wish I’d known some (all) of this many years ago, and I hope this helps you in your journey. You can do it! I’ll be sharing how I got my career back on track in a future post, so if you come from a non-traditional background or your career took a “wrong turn” sometime in the past… follow to get an update when that post is up.

Good luck!

Resources

This is a very incomplete list of resources that may be helpful, but there are plenty of other resources out there, choose whatever works for you.

• https://thetechresume.com/
• https://www.careercup.com/resume
• Cracking the coding interview (of course)
• Leetcode, interviewbit… any number of these sites.
• The material companies send you!
• https://www.levels.fyi/
• System Design Interview – An insider’s guide
• Grokking the system design interview
• https://blog.pragmaticengineer.com/preparing-for-the-systems-design-and-coding-interviews/
• https://techinterviewhandbook.org/

This content originally appeared on DEV Community and was authored by rinaarts