Rogelio Gudiño

Interviewing For Big Tech Companies (Software Engineering)

Last updated: Dec 20, 2022

Given that interviewing for software engineering roles in big tech companies is a skill of its own, the goal of this document is solely to help people gain or improve that skill and increase their chances of getting a job at a big tech company. It does not argue for or against the interview process and neither does it propose something better.

General Preparation

Big O Notation

Not always, but in most interview exercises/problems you’ll be asked to identify the time/runtime or space/memory complexity of a method or algorithm. Be familiar with both the notation and their name. Mainly:

This will be asked with one of three purposes:

Basic Data Structures

You won’t necessarily be asked to implement these, but you’ll very likely be using them as part of your solutions. So it’s very important you’re very familiar with them: how they’re implemented, and the runtime complexity of all their operations (read, add, remove, etc.).

Binary Trees

Less important, but be familiar with:

Algorithm Techniques/Methods

Other Topics

These are either less likely to come up or just need to have a notion about them:


This is optional, but because onsite interviews will very likely be on a whiteboard, it’s recommended that you practice solving problems in one. If you’re not used to writing code in one, odds are it’ll hurt you a tiny bit since you’ll either run out of space, write extremely slow, find yourself erasing a lot, trying to fit stuff you missed in tight spaces, etc.

A few tips are:

Domain Specific Preparation

iOS with Objective-C

iOS with Swift

TODO: Need to update with latest language features!



Front End


Back End


The Interview

Choosing a Language

It’s very likely you’ll have a choice on which language to use. Always pick the one you’re most familiar with or know the best.

That said, there are a few things to consider:

Syntax Errors

Most companies are forgiving when it comes to syntax errors (Facebook might be the most strict). That said, you should strive to avoid them and write code that essentially compiles.

Interviewer Notes

Interviewers both take notes and copy your code. For note taking they’ll either use their computer or pen and paper (although some with great memory don’t take notes). For the copy of your code though, they’ll either type it live into their computer or take pictures of the whiteboard and then transcribe it all into their computers once the interview is over.

Many times the interviewers that write your code live into their computers won’t tell you about it at the beginning, so it throws people off sometimes: it’s either distracting or it makes it feel like they’re not paying attention. With that said, know that they are paying attention (which may make it less distracting).

Before The Problem(s)

The first 3-10 minutes of the interview are likely for the interviewer to ask you domain specific questions, behavioral questions, about your resume, or to answer any questions you have about the company or the interviewer’s job (this last one is most likely to happen at the end of the interview).

The Problem(s)

The key to performing well in the interview is communication and verbalizing most—if not all—of your thoughts.

The other thing you should keep in mind is that in most—if not all cases—you want to have a working solution fully coded, rather than a highly optimized solution that’s incomplete or contains many errors.

The following steps are a good recipe to succeed:

TI = The interviewer.
Y = You.

  1. TI: They will describe the problem to you.
  2. Y: Ask questions that clarify or reveal the specific edge cases of the problem. If the interviewer didn’t give you input examples, it might be a good idea to ask for some. If you don’t have any questions, at the very list verify that you understood the problem by saying out loud what you need to do. A few examples of questions: “do I have to worry about case sensitivity?”, “can you remind me of the definition of x?”, “can the input be a negative number?”, “is there a specific memory or runtime complexity I should aim for?”, etc.
  3. Y: Once everything is cleared out, vaguely describe the first solution that comes to mind. If multiple solutions came to mind before or during your description of the first solution, continue by mentioning/describing them. If you gave more than one, tell the interviewer what are the pros and cons of each one and which one you’d like to go with.
  4. TI: They might have a different opinion on what solution you should go with. Odds are they’re trying to guide you in the right direction, so it’s recommended you gracefully take their recommendation (after understanding and evaluating/assessing it, never take recommendations blindly!).
  5. Y: Try and give them all the steps of the solution‘s implementation verbally. In some cases this is not feasible or very hard to do so, but try. In some cases the steps are simply the main lines of a method. In other cases the steps are a bit bigger, general, and/or abstract.
  6. TI: If they detect an issue in your steps hopefully they’ll bring it up. They might also have new questions or suggestions for you. But at this stage it’s likely that not much conversation around the solution needs to take place anymore.
  7. Y: Announce you’ll now proceed to write code and do so. If you can, speak and write at the same time. If this is hard, try doing the speaking before or after you write each line of code.
  8. Y: Once you’re done writing the code you needed to write, tell the interviewer: “I’m now going to test the code to see if it works. Do you have any question, comment, or suggestion before I do so?”. If they do have one, address it.
  9. Y: (VERY IMPORTANT STEP!) Now proceed to test the code by making a line by line dry run* with a couple or few different inputs (if you were giving examples of them, use those) and going line by line of all the code you wrote. For example: “Ok let’s say we pass in 5, so x = 5, x square is 25, if x is greater than 10 we do this, then we return true. If we pass in 1, x = 1, x square is 1, if x is less than 10 we do this, we return false”.
  10. Y: If you found errors or issues, address them. If not, tell the interviewer that is your solution.
  11. TI: 3 things can happen now: they’ll add something new to the problem, they’ll give you a new problem, or you’re done with the interview. If it’s one of the first two, simply repeat from step 1.

* There are very few interviewers who’s expectation of testing the code isn’t a line by line dry run of your code, but to write actual unit tests. Make sure to ask the interviewer what are their expectations when it comes to testing the code.

After The Problem(s)

You’ll likely get 5 minutes at the end of the interview to ask questions to the interviewer (if this didn’t happen at the beginning). For the most part (if not the sole purpose of) this is for you to genuinely learn about the company through the interviewer.

Practicing and Other Resources

Cracking the Coding Interview

For many years, the Cracking the Coding Interview book by Gayle Laakmann McDowell has been the most popular way to prepare for technical interviews. This was the way I prepared myself, along with the series of videos:


In recent years LeetCode has been to main resource for technical interview preparation. The following are curated lists of top questions to practice:

Specific Companies


TODO: Process (recruiter contact, schedule phone interview, schedule on-site interview, interviewers submit feedback, recruiter decides whether to send review packets to committee, committee makes a hiring decision, review packet is sent to Larry (or a VP?) for a quick last check, offer is extended).

TODO: Practice in a Google Doc for phone interview. Tools, Preferences..., Uncheck: “Automatically capitalize words” and “Use smart quotes”.

TODO: On-site: 5 interviews of 45 mins each. 1 hour for lunch with a Googler, free to ask anything, you don’t get evaluated.

TODO: Google Hiring Process videos: