I was reading dev.to a couple of weeks ago (I think) and there was an article that made me reflect about my interviewing experience at big tech companies (as an interviewee). So I thought… Why not share it and help other people that may be in the process of interviewing? Or who are considering applying themselves but perhaps don’t dare to? Or with someone who is merely curious and may think of it as a long term career goal?

So here it goes! In this article you’ll find out how to tackle the technical interviews at big tech companies. You’ll learn from my experience and my mistakes and we’ll distill everything into a methodology of sorts: A way to prepare your mind, and body, and mind (:D) before and during the interviews.

Get those interview books ready, pen and paper, and let's kick some ass!

So one day many, many seasons ago I got this call from Amazon…

Amazon

…Although it wasn’t a call. It was actually Linkedin. Yep, Linkedin does seem to work for this sort of things. Google also contacted me via Linkedin but let’s not get ahead of ourselves because that happened a loooong time after.

A team of Amazon recruiters was going to come to Sweden and snatch the cream of the crop amongst the vikings and other creatures living among them (like me). The recruiter thought I had an interesting profile and encouraged me to take the plunge and apply for the interviews. There would be an online exercise which would be recorded through a specialized interviewing tool and, if all went well, I would be invited to Stockholm for a whole day of onsite interviews.

It’s good to make a stop here to describe how impossibly clueless I was about the prominence of Amazon as a tech giant at the time. I was very far deep into the Microsoft fanboy bubble (I was a proud owner of a Windows Phone for God’s sake) and if you had told me the word Amazon the only thoughts that would’ve popped up in my mind would’ve been e-commerce site and kindle. That’s it. No thoughts about AWS or Amazon being a huge tech player in its own right. So I thought cool, but I didn’t really think about it being a big deal (It was. kind. of a big deal).

So I went to do the online exercise with no preparation whatsoever. I honest to God didn’t know I was supposed to prepare for this thing and my reasoning was: I’m a somewhat experienced software developer, a good one, I should be able to show them what I’m made of since I do spend most of my time coding. I don’t remember the actual problem but I remember the experience was quite fun. I had an idea. To show them how I normally wrote software so they would have a picture of how it was to work with me. So I took the problem and TDDed a solution. They must’ve liked my approach because soon after they sent me an invite to the onsite interviews. Yey! On we go!

Ok. Now that I brought up the TDDing I feel we need an aside to talk about it. Let’s dive in for a sec and we’ll be back to the onsite interview right away. Note that we’re in Jaime-weird-experimental-land here, and nobody has ever given me any verbal feedback about this being a good idea for programming interviews. Feel free to jump over this aside and forget I ever mentioned it. But if you’re a tiddy bit curious…

TDD in Programming Interviews? Really?

Do I recommend using TDD in your programming interviews?

No, unless you are experienced TDDer. Otherwise TDD just adds yet another concern to the programming interview that wasn’t intended by the interviewer and will pile up additional stress and completixity to the task you need to solve and the interview itself.

TDD should feel really comfortable before you attempt this. But I think you will definitely get bonus points if you have the time to mention that you would write automated tests for your code and discuss some test cases. A good interviewer should either nudge you forward or redirect you to the problem at hand. This should give you a hint whether she/he/it/they finds valuable to know more about your testing practices or whether you should focus entirely on the problem being solved.

Why do I think it is very cool to solve programming interviews with TDD?

TDD is such a beautiful way to watch someone solve a problem because it tackles a problem from the outside-in. It brings the other person(s) along in a very straightforward way as you implement a body of software incrementally. Moreover, it also shows that you deeply care about automated testing and about solving problems systematically.

It doesn’t work well with all problems though and you may need to complement it with whiteboarding in some situations. For instance, TDD works great when solving a real business problem, like when you need to design a small car rental service or a calculator (hehe ¹), it’s also great to program data structures, say a linked list or a tree . It’s not that great for purely algorithmic questions where the API surface may be a single function and all the meat is in the implementation of the algorithm itself (although I find very elegant to write the test cases first from trivial inputs to not so trivial ones even in this case).

Why TDDing a programming interview can be a very bad idea?

Bears repeating but if you aren’t comfortable with TDD it’s going to be an extra burden. Don’t do it.

Then there’s the fact that coding interviews are typically quite short. You blink and the interview is done. Writing tests does take precious time that you may want to spend in solving the problem. An alternative here is to just write the first test and then mention additional test cases without actually writing the function body.

Then there’s culture to take into account. There’s company cultures who really, really frown upon the idea of dropping into coding right away without spending some time to think and reflect first. In such an environment, opening the laptop and starting typing may not be the best approach. Listen for cues like: “Oh! You’re coding right away?”.

The Amazon Onsite Interview

I went to the Amazon onsite interview with the same mindset and utter lack of preparation that I had doing the online exercise. Oh, the naivete! Looking back at how clueless I was about interviewing at big tech companies at the time it is somewhat embarrassing. The interviews were a lot of fun and all the interviewers were truly great: encouraging, helpful and interesting. I did all the interviews but for the last one before which I was sent home.

Here’s some things which I feel I did right:

• I had a great mindset: I was open, energetic, curious, joyful, positive and moreover I had a lot of confidence in my ability to pass the interviews.
• I put up a good fight and effort in the technical interviews and didn’t panic. Since I didn’t have a lot of experience on Computer Science algorithms at the time (my university days were long past) I tried to solve all problems from first principles which is slow but works. First principles in this case means that I knew the conceptual foundations of how different data structures and algorithms work but I may have not solved them myself or practiced with them thoroughly. So in order to solve a problem I would need to use reason from the very foundations upwards.
• I was very communicative about my thought process when working on solving problems.

Here’s other things I didn’t do right:

• I so should have prepared thoroughly for the programming interviews, specially for the computer science-y algorithms and data structure problems. This feels extremely basic and obvious in hindsight but I still didn’t do it. I hadn’t developed the practice, agility, pattern matching necessary to do a solid algorithmic programming interview and it showed in every regard.
• Mind the culture gap and listen for cues. Americans and Europeans may look similar, behave similar, share a similar western culture but you still have to be aware of the culture gap (there’s even a culture gap between European countries, for many examples ask my Swedish wife). Specially if you are European and are being interviewed by an American. In this particular case my interviewers were very keen in understanding what I had done in my previous jobs and I, as a good European, had a lot of trouble with self-promoting (still do most of the times) and kept using the word we (as in we did this, my team did this, and so forth). At the time I think I pretty much we-ed myself throughout the interviews but had I listened I would have understood what the interviewer was asking of me. (Also interviewers should be more aware of the culture gap, particularly if they’re doing a European tour as was the case).
• I was still pretty clueless about Amazon itself and their tech stack. Doing some research about the company, their services and products, the roles that were open would’ve given me more tools to relate to the engineers and ask better questions. I had the chance to talk to engineers that had developed amazing things and it was embarrassing to admit that I had not even the slightest clue about it.

Amazon Interview Teachings Summary

Google

In 2010 I started my third job as a Software Developer in Sweden (my first had been in Spain a year prior and my second one in Sweden had been a short affair). I remember very vividly going to work, 4:30 in the morning (I have experimented with very weird life routines), really cold, really dark, listening to an audio book. The audio book was In The Plex and it narrates the story of Google. I remember thinking as I was listening, “Wow… How cool… How beyond awesome it would be to work at Google…” (although you know it’ll never happen, right?)

(fast forward)

It was January 2016. A brisk Swedish winter at -25 degrees Celsius had gripped the land. Everything was sleepy, lethargic, awaiting the warmer months of Spring to come back to life. Everything but recruiters, that is. As soon as I came home from celebrating Christmas with my Scandinavian family I was surprised to find two Linkedin emails in my inbox: one from Microsoft and another from Google. (WAT?!)

Two weeks later I found myself interviewing for Mojang and Google. We’ll go back to Mojang later but let’s focus on Google now.

The position I would be interviewing for at Google was that of a Technical Solutions Consultant, which is sort of an software engineer that works very closely to Google partners and customers, helps them adopt and use Google products and services, works with them as a trusted advisor, and acts as a steward of the customer in relation to other Google engineering teams. This position requires a full set of technical interviews.

Preparing for an interview for a big tech company while working at a full time job, active side projects, existing commitments, and having a settled life is tough. There’s just not a lot of time left. You need to cultivate a lot of discipline to just focus on preparing and nothing else. So that’s what I did, over the space of several weeks I would focus solely on preparing for the interviews. I didn’t track hours or anything like that, I just devoted all my free time (that my girlfriend allowed :D) to preparing. Here’s what I did:

• Watched a couple of data structures and algorithms courses on Pluralsight as a refresher: Part I and Part II
• Read Cracking the Code Interview
• Read Programming Interviews Exposed
• Practiced solving different Computer Science-y problems with pen and paper and in code (I did some TDD Katas that I published in this very blog). Being a somewhat experienced Software Developer I felt like data structures and algorithms problems that you typically find in programming interviews were my Achilles heel so that’s what I focused most of my time on.
• Refreshed some fundamentals in different areas like distributed systems, networking, linux, etc

My frame of mind at the time could be summarized in: “Let’s do our best but don’t get our hopes too high” :D . You can clearly see this attitude in the fact that I didn’t tell almost anyone about the fact that I was interviewing for Google. I think that in my heart I didn’t believe I would make it through the interviews and I just didn’t want to tell anybody to later have to admit that I had failed. That sucks. We shouldn’t do that. I shouldn’t do that. We should throw our self-imposed limitations and fears out the window, embrace life to its fullest, dive head in and if you fail, you fail, you’ll do better next time. Still working on that.

Two months-ish later I would receive the happy news and an offer from Google. I was going to work at Google. Holy. Shit.

Here’s some things I feel I got right:

• I prepared for the effing interview this time. Yey! Jaime! You learned something from the last time. Props to you. Kudos to the Google recruiters who are very helpful at setting the right expectations and pointing you to topics and material you can use to prepare for the interview
• I had a great mindset preparing and during the interviews. Even though I didn’t expect to make it, I truly gave it my all during the preparation and at the interviews themselves. I pumped up before every remote interview with mediation, two cups of coffee and, yes, believe it, Dragonborn, from the Skyrim soundtrack (That thing is on fire! Dovaki! Dovaki!). That and I just brought my best self to these and the onsite interviews.

Here’s some other things I didn’t do well:

• I wish I had believed in myself, and myself worthy of Google. There’s some people that just have that seemingly natural aura of confidence and peace in themselves. I didn’t have that.

Google Interview Take #1 Teachings

Google Take #2

I love, love, love software development and coding. The thing I love the most is the creative side of coding. I love building things. In my job as a Technical Solutions Consultant I didn’t get to do that a lot (some but not nearly enough). And so, even though I did a great job in that position, there’s a lot of qualities that I have that are very handy in that role, I didn’t feel fulfilled. I tried to make up for that by trying to catch up on my free time but I think I began to lose myself. It felt like I was two persons at the same time travelling two distinct paths in diverging directions. And the person that I least wanted to be was going much faster and becoming stronger, while the other one was slowly fading away.

I was deeply unhappy. I had an awesome job, with awesome colleagues, in the most awesome company, everything was really good, but I wasn’t doing what I wanted to be doing in life. I really prided myself in being a great software developer but I could feel my skills rusting, degrading, disappearing, I just didn’t have time to cultivate the art of writing software anymore and what you do, you become, what you don’t do…

After a year and a half as a Technical Solutions Consultant I decided to make the jump to Software Engineering. I’m extremely thankful to my manager that was super encouraging and supportive, and my former and new colleagues who were likewise (Specially a couple of them to whom I’ll be for ever grateful). I felt extremely rusty at the time, plagued by self-doubt in my skills as a software developer and I was up for another round of interviews with one additional spice into the mix. Malin and I had just become first time parents and our little son Teo was 3 months old. Hell yeah. Bring it on.

If preparing for the interviews had been tough before. Think about preparing for the interviews while taking care of a baby. There aren’t words to describe the infinite level of exhaustion Malin and I were under in late 2017. You have to go through it to truly get it. So imagine putting the baby to sleep at 10pm after having fed him with a bottle, after a whole day of work and taking care of the baby, after 3 months of sleep deprivation, you open Cracking the Code Interview and start making problems for the next 3 hours until you literally fall asleep of exhaustion. Yep. Tough.

Cracking the Code Interview became one of my best friends at the time, and so did Interview Cake (Really. Good. Site), A Common-Sense Guide to Data Structures and Algorithms, Elements of Programming Interviews and The Algorithm Design Manual (although I didn’t get that far into this last one before doing the interviews).

In early 2018 I received the super happy news. I was to become a Software Engineer at Google. To say I was ecstatic is an understatement. I was coming back baby!

Google Interview Take #2 Teachings

A Methodology For Interviewing at Big Tech Companies

Let’s put all the teachings together and arrive at some sort of methodology that you can follow to prepare for the interviews and be successful. Here it goes!

Long Before the Interviews

Know thyself. What is it that you love doing? What is it that you hate doing? What are your career goals? What do you want to do with your life? You don’t need to know the answer to all this questions but fill some of the blanks and you’ll be in a much better position to decide whether you want to work at a particular company and in a specific role. It will also give you the foundation to ask the interviewers questions that matter to you. Also listen to your inner self.

Before the Interviews

1. Start with these videos from Life at Google that give you some guidance and a feeling of how a coding interview looks like (this advice is helpful even if you are interviewing for companies other than Google):
   1. How to Prepare For The Google Interview
   2. Example Google Coding Interview
2. Prepare your knowledge and flex your problem solving muscle
   1. Read Cracking The Coding Interview back to back. Solve all the problems. Repeat.
   2. If you have the cash take a look at Interview Cake. It truly is a terrific resource and they refund you the money if you don’t pass the interviews.
   3. Practice with pen and paper, practice coding in Google Docs (or a similar editor with no syntax highlighting), practice using a whiteboard, practice whichever conditions you expect to have during the interviews. Enlist a friend and do mocking interviews.
   4. Practice talking out loud as you solve problems. The goal is to help the interviewer understand your thought process
3. Work on your mindset
   1. Read The Obstacle is The Way
   2. Believe in yourself! You can do it! Be positive!
   3. Every problem solved will build up your confidence.
   4. Some days are better than others, if you’re not feeling it, just keep going. Even the bad days add up. Taking a break is also ok.

While preparing:

• Focus on preparing your weaknesses. If you haven’t looked at computer science problems in ages then focus on that. If you are a junior developer recent from university then you may want to spend some more time on system design, architecture, distributed systems, etc. (but do spend a considerable amount of time on algorithms)
• Solving data structure and algorithm problems with pen and paper in a rough fashion is much faster than solving them in actual code. If the time to prepare is limited you may favor solving problems with pen and paper and limit the problems you solve with code. This will allow you to get exposed to a wider number of problems.

Normally I would follow the following approach when solving problems:

1. Find simplest solution. Normally this would be a brute force algorithm
2. Write brute force algorithm in pseudocode with pen and paper
3. Analyze complexity of this solution with big O notation
4. Improve algorithm by optimizing runtime or space, or by removing repeated work. Normally there’s a trade-off that you can use to improve the algorithm. Add the use of some memory and the algorithm becomes orders of magnitude faster, memoize previous results and it may have a significant impact, etc
5. Write improved algorithm in pseudocode
6. Write improved algorithm in code
7. There may be more improvements on the improvements
8. Think of possible tests cases, edge conditions, off-by-1 errors, etc. Debug your own algorithm with some example inputs. In general, the use of sample inputs can be super helpful to reason about an algorithm.

After solving lots of problems you’ll be able to pattern match problems into families and you’ll develop an instinct for which types of algorithms and techniques can solve a specific problem faster and more effectively.

During the Interviews

1. Just before the interview
   1. Develop a ritual to get pumped up before the interview. Use Skyrim, Eye of the Tiger, Conan, Beyoncé, whatever works for you. Stand strong and spread your arms wide. Do an energizer. You got this!
   2. If you’re going for a coding interview then try to solve a simple problem. This will put your brain into problem solving mode and give you a boost of confidence before the interview.
2. During the interview
   1. Be enthusiastic, eager and curious. We’re all human and the person interviewing you is going to evaluate whether they would like to work with you. At least at a subconscious level if they are not actively asked to contemplate and answer that question. Above all, don’t be an asshole (bring that advice everywhere you go).
   2. Ask questions! Is there anything remotely ambiguous about the problem at hand? Is there something you’re wondering? Ask! Don’t be afraid to ask questions.
   3. Talk! Guide the interviewer through your thought process. This helps the interviewer understand how you solve problems and also steer you away if you stray too far or nudge you gently if you’re following the right path.
   4. Listen to the interviewer. What are they asking? What are they telling you? There’s this meta dimension throughout the interview and you can tap into it if you listen.
   5. At the end of the interview there will be time to ask some questions. Use this time to interview the interviewer back and find out more about the role and the company. Is this the right company for you? Is this the right position for you?
   6. Have fun!

A great principle to follow during the coding interview is to imagine that you and the interviewer are part of the same team and you’re solving a problem together. Keep that it mind and asking questions, and the talking will be more natural.

Concluding

And that is it! The process of interviewing for a big tech company can be long and grueling. You need to prepare body and mind to be your best self at the interviews, and have a lot of patience and grit as you traverse the process, do more interviews, more preparation and await the results. If you’ve started this journey, I really hope you’ve found this article to be useful. Go kick some ass! And if you fail. It is OK, you can learn from your mistakes and try again. As you’ve seen in this article, I’ve failed a bunch. Good luck!

As an add-on, if you’re interested in learning about Google hiring practices there’s this great book called Work Rules! Insights from Inside Google That Will Transform How You Live and Lead that has a lot of info about it and more.

A Few More Trivia on Other Interviewing Experiences I’ve Had

• When I arrived to Sweden I was looking for a job for about 7 months before I got my break. I sent ~200 cvs and cover letters until one awesome person trusted in me. Thank you! I should’ve spent that time learning Swedish but instead I learnt TDD (and more). The teaching here is that something that you may think is unimportant can actually be a hard requirement, a deal breaker and vital for the company you’re applying to.
• In the early 2010s I interviewed at Opera Software. I failed the programming interview. Again, in my clueless-ness of the time I didn’t prepare properly and I solved it using first principles. They asked me if I knew the solution before-hand and I said no. I think they thought I lied. I didn’t lie.
• Even though it would’ve been awesome to work at Mojang it didn’t work out. I had an interview with the team but I think they didn’t feel I was a good match for them. Could it be because they were a heavy linux shop and my background was Microsoft .NET Enterprise? Who knows. You very seldom get feedback when you fail an interview. We should change that.
• One of my favorite interview experiences was at Active Solution. They gave you a problem to solve in the comfort of your home. You’d then send it over and if it was deemed good enough you’d meet with the team and discuss how you solved it. Fun!

If you weren’t aware of it, a calculator is the canonical example of TDD. It’s like the ToDoList of TDD.