My Interviewing Story
Back in 2011, I knew that I wanted to work for Google. I was astounded when I learned from a recruiter that they were interested in having me interview for a highly-coveted Software Engineer position.
I knew that if I could just pass the interview, it would fundamentally change my life. In my mind, having Google on my resume meant I’d never need to update my resume ever again.
I had done lots of research, reading stories from all across the internet from people who had tried and failed to pass what is still famed to be the most difficult interview process in all of tech.
And while stories of failure were in abundance, the stories of success were rare.
An article in Forbes by Stan Phelps claimed that “it’s almost ten times harder to get a job at Google than it is to get into Harvard,” with over
2,000,000 people applying yearly. I knew that I was up against a real challenge that I did not fully understand.
Unfortunately, I learned this the hard way when I got a call from my recruiter. After two phone screens, I was told I would not be invited to continue the interview process.
This singular defeat was one of the most important professional blows I had ever received. I struggled to understand why, despite my best efforts, I had come up short. Fear began to set in as I realized I might never be good enough.
Why This Guide
Fast forward to today. Having successfully conquered that same interview process, I know exactly why I didn’t make the cut on my first try.
I started Morgan Latimer Consulting in the hope of sharing what I know from my many years of experience with those
willing to work hard to succeed at technical interviewing with companies like Microsoft, Facebook, Amazon, Twitter, and others.
I hope this guide will help you prepare well by teaching you what not to do. As you prepare for technical interviews, think carefully about how you can avoid these fatal interviewing mistakes.
Without further ado, let me share with you the ten biggest mistakes made in technical interviews.
10. Interviewer Bias
Sometimes, the reason why you might fail a technical interview has little to do with you. Sometimes, you’re just a victim of interviewer bias.
No matter how smart you are or how well prepared you may be, the sad reality is that you are still dealing with other very imperfect human beings. These individuals may bring their own opinions, viewpoints, and biases that negatively impact your chances of receiving a fair and objective assessment.
Many companies have instituted bias training to help employees address and confront their own personal biases. Even then, the training is often optional and not outright mandatory. And there’s no policy that can erase the biases that people may have against one another.
We typically think of bias as it involves race or gender, but there are plenty of other biases that can impact how you’re assessed in a technical interview. For instance, someone who is a back-end focused engineer might not respect the technical complexity that front-end engineers deal with in their work.
Other engineers may be believe there are specific algorithms and data structures you absolutely must know to get hired. Still, others may be biased against certain personality types. It could also just be straight up racism and bigotry.
What You Can Do
While infrequent in my experience, it’s important that you understand that bias can play a real factor in whether you succeed in an interview.
If you believe that you are negatively impacted by the biases of your interviewer, keep the conversation respectful and maintain focus on the technical aspects of your work and qualifications. Once the interview is over, notify your recruiter or contact person of any inappropriate behavior you may have noticed.
9. Failing to Prepare
Some people assume that interviews at top tech companies are just like interviews anywhere else. Nothing could be further from the truth.
You might think that your resume and an impressive conversation with a hiring manager would be enough to earn you a job offer. That’s just not how it works in the big leagues of Silicon Valley tech companies.
As a tech interviewer, I’ve witnessed candidate after candidate attempt grueling technical interviews with seemingly little preparation. Some even seem astonished at the level of difficulty of coding problems that they encounter. It’s like they didn’t even prepare at all.
I’ve also run into people looking for my help just a week out from their interview date, looking to me for any tips they can find on how to begin preparation. All I can do is shake my head.
There’s no excuse for not spending time adequately preparing for technical interviews, no matter how high your IQ is. I find that many people fail technical interviews not because they aren’t smart, but because they simply haven’t prepared well.
What You Can Do
A wise man once said, “Failing to plan is planning to fail.”
When approaching technical interviews, it is absolutely essential to learn everything you can about how technical interviews are conducted at your target company. Then once you know what to expect, practice. And not only should you practice, but you should practice well. That means that the quality of what you practice matters just as much as taking the time to do it.
At Morgan Latimer Consulting, we believe that there is no replacement for using realistic mock interviews to evaluate and assess readiness for technical interviews.
I’ve seen candidates go from floundering to flourishing after just a two coaching sessions involving realistic mock interview questions and expert, 1-on-1 feedback from an experienced interviewer.
8. Studying the Wrong Stuff
Preparing with the wrong expectations is like not preparing at all. This was the primary reason I failed my big interview in 2011. I expected to be assessed largely on brain teasers, which I studied for nearly two weeks in preparation for my phone screen. When I was confronted with purely technical coding challenges, I was caught off guard and woefully unprepared.
The fact of the matter is that there is a lot of misinformation about big tech firms, how they interview, and what they are looking for in potential candidates. It can be difficult to get an accurate picture of what to expect if you don’t know someone who already works at your dream company.
Recruiters may also send you a flood of information to study, making it hard for you to get a good read on what you really need to know for a technical interview.
Which algorithms are important? Is it worth it to learn the A* graph search algorithm? Should you spend time memorizing as many interview questions as you can find? Does my dream company believe in using brain teasers or, even worse, stress interviews?
What You Can Do
Do your homework. When researching tech companies and their interviewing practices, it’s often best to go directly to their careers website to get reliable, trustworthy information. If you read information from blogs and other news media sources, consider their reliability—and their motivations.
One of the reasons I founded Morgan Latimer Consulting was to help demystify the interview experience at top tech companies.
Know that when you work with us, you’ll get reliable, trustworthy information on what top tech companies are really looking for and how you can study the right things in order to achieve the right results.
7. Don’t Know Big-O
Understanding the worst-case time and space complexity of an algorithm is essential to building systems that scale to millions of users and billions of devices. Yet so few people who interview at top tech companies actually understanding this concept, commonly referred to as Big-O analysis.
I believe the reason why this is so true is that, at many companies, developers don’t need to build the fastest, most scalable solution. They just need to build something that’s good enough, as cheaply as possible. Big-O becomes one of those things you learn in college and, after graduation, go on to quickly forget.
However, when building distributed systems at scale, Big-O is crucial to understanding what the performance characteristics of a piece of code or an entire algorithm is expected to be. Only once this is understood can one think about whether it is sufficient for achieving the desired results or whether optimizations should be made. Code that runs within a given Big-O with a small amount of input may be absolutely horrible on inputs that are substantially larger.
An algorithm that does a small amount of work on 1,000 records in memory is trivial. That same algorithm running on billions of records might be untenable, especially if the analysis of those billions of records are crucial for, say, time-sensitive financial reporting. Once you understand this, you can think about strategies that reduce the runtime complexity of your algorithm using techniques like hashing, sharding, pre-processing, etc.
In an interview situation, your interviewer will want to know if you know how to measure and assess the Big-O runtime of your code. They will also want to see if you can identify and implement the most optimal solution as measured by worst-case time or space complexity—and sometimes both.
What You Can Do
There are tons of resources online to help you understand how Big-O works. These resources range from blogs and sites dedicated to simplify explanations of worst-case analysis for common algorithms and data structures, all the way up to academic courses at top institutions like MIT. The important thing here is that you choose something that works for you, and spend time improving your understanding of Big-O.
6. Forgetting Parts of the Problem
Like I said earlier, interviewing is stressful business. It’s amazing how, no matter what you’ve studied and committed to memory, everything seems to quickly fly out the window as soon as you have to work out a problem in a real interview setting. You could be forgiven for forgetting your own name by the last interview of the day!
It can be very frustrating for the interviewer if you show a pattern of forgetting important parts of the problem statement. This leads to the interviewer having to answer the same questions multiple times while simultaneously causing you embarrassment, costing you time, and unfortunately, raising your stress level.
If unchecked, this will only lead to a downward spiral that will have you cracking like a nut and unable to make any meaningful progress for the rest of the interview.
Your interviewer has likely reviewed their chosen interview question at least a dozen times with a variety of candidates. They’ve practiced stating the problem in such a way that necessary and important details are conveyed accurately enough to give you a chance to come to an optimal solution.
They are looking to see if you can pay attention to those details and incorporate information and feedback into your approach.
What You Can Do
The solution is straightforward—write information down! There’s almost always a way for you to write down important aspects of the problem that you’ll need to remember for later points in the interview.
If you have a whiteboard, use it! An online collaboration tool? No problem. Ask your interviewer if you can type notes into it. If nothing else is available, grab a nearby sheet of paper and a pencil. Whatever you do, avoid trying to keep everything in your head. It doesn’t necessarily make you look smarter and isn’t a requirement for doing well in a technical interview.
5. Weak Coding
Top tech companies look for the best of the best, and can afford to pay top dollar to get them. This means that, when it comes to coding, they want candidates who can pound out lines of code as easily as they breathe.
One of the unique features of technical interviews at major Silicon Valley firms is live coding. Interviewers want to see you quickly write real, syntactically-correct, error-free code—and all without an IDE. I’m not talking about code as simple as FizzBuzz either. I mean that you will need to generate real code to solve some problem you’ve never seen before.
If you’re trying to figure out where the semi-colons and curly braces go, then you’ve already lost (yes you hopeful interns and technical program managers, I’m talking to you too).
Unfortunately, some candidates either don’t go in with the right expectations, or just don’t practice coding in their chosen language despite knowing that’s exactly what they’ll be tested on.
Not knowing simple things like how to use the right loops with the right conditions or how to declare simple data structures will kill your chances to progress in the interview.
Also, a failure to demonstrate strong coding abilities and good code design will both kill your efficiency and demonstrate to your interviewer that you don’t know how to code as well as you may have let on.
Bottom line, if you can’t code well, you won’t get the job.
What You Can Do
There’s two very important things you should do to avoid this issue. First, make sure that you work on getting regular coding experience.
One of the best ways to do this is by working professionally as a software engineer or developer. Code everyday, and you will get better if you make an effort to do so.
Secondly, you should make sure to incorporate exercises into your practice regimen that will help you write code freely without the need for an IDE.
For your interview prep, use a pencil and paper (bonus points for using a whiteboard) to practice code algorithms and data structures.
4. Weak on CS Fundamentals
You were probably thinking that this point would be the number one reason why candidates fail technical interviews, but it’s not even in my top three.
It’s no secret that top tech companies rely on principles that Computer Science undergrads usually learn in their first or second year of college. Most candidates that I coach have studied several of the important algorithms and data structures and know them well enough to succeed at coding up good solutions.
However, I will run across a few candidates who didn’t get the memo and are unprepared. This is an absolute non-starter.
Not everyone understands the importance of having a solid comprehension of basic algorithms and data structures theory, but those who’ve had sufficient experience building software systems at scale absolutely do.
Sure, you may not build Amazon a binary tree from scratch, but that doesn’t mean you won’t ever need to know how one works in order to solve a hard problem.
What You Can Do
Dust off that old algorithms textbook and get to studying. Focus on understanding why the algorithms work the way they do, not necessarily on memorizing how to code every single one you see in the book. Memorization is important, but go for understanding first and memorization will follow.
Plus, there really aren’t that many algorithms and data structures you really need to know to be successful, even though some lists may look intimidatingly long. If you know how arrays, hash maps and graphs work, that’s half the battle right there.
3. Not Asking Questions
Big tech companies are known for being incredibly innovative. Companies like Facebook, Google, and Amazon have invented technologies that have changed the world multiple times over. There isn’t a person in the world not impacted in some way by the technologies that these companies build.
One of the most difficult challenges when working for innovative companies is handling ambiguity. They want to be sure that candidates will be able to handle ambiguity well on the job.
The way they do this is by posing interview questions that intentional omit details (at least initially). If you don’t understand this fact going into the interview room, you may not know that you’re supposed to ask questions to get relevant details from your interviewer.
I’m astonished at how many candidates get straight to coding without asking a single question. At least 95% of the time, I’m correct in assuming that these candidates will either overcomplicate the solution or solve the wrong problem altogether.
Reading the first chapter of Programming Pearls by Jon Bentley, I remember how Mr. Bentley relayed a story about estimating a programming tasks that involved sorting a file on disk. Initially, he had made the mistake of coming up with a solution before asking questions. But once he clarified the requirements, what he had assumed would take “hundreds of lines of code and a week of programming time” ended up taking just a few hours.
What You Can Do
Again, the takeaway here is pretty simple. Make sure to ask questions before you write a single line of code. You want to ensure that you have the right understanding of the problem you need to solve before you begin trying to solve it.
This is another reason why mock interviews are an essential part of your interview prep. Asking good questions and communicating well with an interviewer takes practice. An experienced mock interviewer will assess how well you ask questions and provide feedback on how you can improve.
2. Not Thinking Out Loud
One of the most important things your interviewer needs to assess is how you think. They want to get inside your head and figure out how you solve problems. That means that you’ll need to make their job as easy as possible by thinking out loud.
If you haven’t made a regular habit of doing this, thinking out loud will seem incredibly strange to you. Many candidates spend minutes of their interview staying absolutely silent while they go off and write code. Then, when they get stuck, the interviewer has to dig into their approach to help them see where they went wrong.
This can also be especially problematic for introverts. They will often need time to think quietly to themselves before expressing their thoughts, but many neglect the second part of this equation and end up in the same trouble.
What many people don’t understand is that the interviewer is actually there to help them, not just to assess their abilities. But many candidates forfeit this help because they don’t share what they are thinking with the interviewer.
And trust me, your interviewer is probably happy to sit and watch you flounder while they think about the problems waiting for them back at their desk once the interview is over.
What You Can Do
Practice makes perfect. Make sure that you practice talking out loud as you practice solving interview questions, either to another person or to yourself (if you have to).
Not to beat a dead horse, but I’ll remind you again how important it is to actually do mock interviews that force you to practice talking out loud to another person.
The great news is that you don’t need to practice exclusively with programmers to get useful feedback about whether you’re doing a good job talking out loud. Ask your practice partner to give you feedback as you talk through a problem and make sure that they notice you speaking out loud.
1. No Problem Solving Strategy
So, it has all come down to this. The number one reason why people fail technical interviews is that they lack a consistent problem solving strategy.
The whole point of a technical interview is to assess whether you’d be able to demonstrate the problem solving skills necessary to solve difficult, real-world problems. Companies do this by making you solve difficult problems in a controlled, time-boxed interview situation. At the end of the day, your interviewer has to be convinced that you are a good problem solver.
Unfortunately, most people don’t even know what strategy they would use to approach problems. I’ve seen candidate after candidate haphazardly approach an interview question like someone groping in the dark for a light switch in the middle of the night.
Even if you know every single data structure and algorithm known to man, a lack of good problem solving skills means that you’ll either solve the wrong problem, or solve the right problem using the wrong tools.
Nothing breaks my heart more during an interview than when a candidate starts off with a good problem solving approach and then abandons it as soon as things get tough. That’s why consistency is an important part of a good interview performance.
What You Can Do
You need to identify and practice solid problem solving strategies that will help you know exactly what you need to do in an interview from start to finish. There are several great techniques and frameworks out there that you can use.
The important thing is to choose what works for you.
I’ve developed what I believe is a unique, six-step problem solving process that is uniquely well suited for technical interviews. If you’re interested, you can purchase my Technical Interviewing 101 webinar where I discuss exactly how to use good problem solving skills to conquer even the most difficult of technical interviews.