SeattleDataGuyTechnical interviews don’t just test your understanding about data structures and algorithms for calculating the probability of events occurring.
These interviews attempt to understand your level of responsibility in your previous projects, your communication abilities, as well as gauge your past experiences to see if you can make good decisions independently. This is why companies like Amazon have their 14 leadership principles. They don’t want to just hire another data scientist or software engineer.
For many interviewees who are only on their first or second interview, this might not be as apparent because you are so focused on answering the technical part of interviews. However, as you are going through your technical interviews, there are some tips we would like to provide to help you better prepare for what lies ahead.
Technical Interview Dos
Do be ready with numbers
Photo by Mika Baumeister on Unsplash
I recall my first interview with a FAANG.
After my first technical portion of the interview, I was interviewed by a TPM — Technical Project Manager. They started asking me about my experiences and the projects I had done in the past. At first, this wasn’t so bad. Then they started to ask about the impact I had in my current role.
After my initial answer, he asked a question which I had never thought about prior to that moment.
“How much time did that project save?”
I had never thought about this question before. At that point in my career, I had pretty much just been doing what I was told. Thinking about big picture concepts like impact and time-saved never came to mind. I was still a young developer, and I had only thought about programming and how to meet the needs of the people I supported. Suddenly, that was all thrown out the window.
The rest of the conversation followed a similar pattern. Every question I answered would be poked and prodded to gauge what my skills were beyond just programming. They were looking for ownership, and independent thinking, but I honestly hadn’t spent much of my time doing that at my current job.
My tip here is do be ready with numbers. Companies like Amazon are very metrics driven. They want developers and engineers who go beyond just developing. That means you need to be ready. When you are going for an interview, be ready with more than just an anecdote or two about what you have done. Make sure you are ready to explain the impact.
Think about your past projects, even if your company didn’t directly calculate the impact and/or estimate how much time it saved. You should take some time to estimate it yourself.
Having some metrics ready shows you think about the big picture and have ownership of your tasks. This can separate you from the pack and help you better understand how to operate at a FAANG.
Do talk through your problem before you start
Most people’s first few whiteboard interviews are rough. You might freeze up because you are trying to get the perfect answer in your head before you even start. Or perhaps you start writing out the answer without communicating with your interviewer what your plan is.
It can be tempting to just start finding a solution right away. But this could send you in the wrong direction early on. You might find yourself 15 minutes into answering your first problem and no where near finding the answer.
So take a few minutes early on to frame your answer to your interviewer. Outline what methods, data structures, and algorithms you will use to get to your solution. This not only helps you solve the answer, but it also lets your interviewer know your thinking process.
Even if you don’t answer the question with the best answer, sometimes an interviewer will look on this more favorably. Communication is very important, and being able to talk through your process can demonstrates your ability to convey solutions.
In addition, if you have a stellar interviewer, they will often guide you to the answer. We are not saying they will spell it out for you, but they might ask questions that make sure you are thinking of possible edge cases and avoid major pitfalls.
Honestly, one of the best interviews I recall was one where it didn’t feel like an interview at all. It felt like two engineers working together to solve a problem. Of course, there are some interviewers on the other side of the fence who won’t help you at all.
Do have questions ready to ask
This might be a cliché tip, but there is something off-putting about an interviewee with no questions about a job. Sadly, for your first job, you probably don’t care about the work.You just want the job. So coming up with genuine questions is difficult.
That doesn’t mean you shouldn't have a few questions prepared to show interest in the role.
I wouldn’t recommend you ask broad, company level questions that you can find out with a quick Google search. Instead, focus on trying to ask questions to your interviewer about their role. For example:
What has been the biggest technical challenge you have faced lately?
Do you feel like you have good growth opportunities here?
How would you describe the engineering culture here?
And so on.
These questions show you are personally interested at the job level. They also help you connect more with your interviewer.
Now that I have gotten older, these are the questions I would ask because I know it’s not just about the paycheck. I really need problems and projects that are challenging as well as impactful to the company.
Sure, working on the coolest technologies are fun. But there will always be cool new technologies. I care more about the impact the projects have than the tech stack that is used.
Do Practice with a friend or at your school
Some people reading this might still be in university. Some may not. For those in school, your school might provide practice interviews services. If so, then you should take them up on it. For those not in school, get a friend.
These services usually have tutors and employees who constantly provide practice interviews and have a good sense of how interviews go. That means you will get the closest thing to a real interview.
If you don’t have that, then, hopefully, you either have other computer science friends, or friends who are already employed at tech firms that can help you. The more comfortable you get talking through problems and doing them on whiteboards instead of doing them on computers, the better you will be.
One of the assumptions interviewees make is that they are good at programming, so they will be good at interviewing. Sadly, these skills don’t always translate.
So do practice up!
Technical Interview Don’ts
Don’t let one bad round beat you
Once you finally get invited for an in-person interview, it usually involves several rounds. They can vary from data structures, system design, behavioral, and whatever other new methods of torture these large companies have decided to put us through.
The point is, there are a lot of opportunities for things to go well and a lot of opportunities for things to go wrong.
You might get stuck on one problem for an entire round.
You could have no idea what object oriented design they are referencing.
The tech field is broad, so it is hard to know everything. It is not uncommon to have a question you were unprepared for.
The key is not to let one bad round define the rest of your interviews. Even if you know deep in your heart that you bombed that round, keep up the positive attitude.
This is for multiple reasons.
One, if you do well enough in the other interviews, the company will be inclined to interview you again in a couple months, or maybe even for a different position. It can be difficult to stay positive, but you never know how it will impact you.
Two, it’s just good practice. Yes, we all wish technical interviews weren’t part of the process, but they are. So the more you practice, the more ready you will be for the next interview.
Even if you bombed one round, you need to stay positive.
Don’t assume you know what types of questions will be asked
In our recent piece about data science interviews, we discussed how different companies and teams are looking for different traits when it comes to data scientists.
The same thing goes for software engineers.
You never really know what types of questions will be asked at your interview, so it is always a good idea to ask your recruiter. Most of the FAANGs will provide some sort of study materials, which is great. But if you are about to head in to your on-site and you haven’t got any hints from your recruiter, then you should ask them what you should expect.
Some companies focus very heavily on data structures and algorithms only. Others mix it up with object oriented and system design questions. The last thing you want to do is be a data scientist who has only worked with decision trees and get questions that involve reversing a linked list or traversing a tree.
It’s awkward and frustrating. Truthfully, everyone’s time was wasted, and if the company didn’t prepare you for those questions…then I put a good portion of the blame on them. But you still should ask!
You want every advantage possible when going in for an interview.
Don’t get too stuck on a solution
One bad habit that some of us have is to over commit to a solution. When you are talking through a problem, your interviewer may be trying to provide hints along the way to make sure you continue in the right direction.
However, when we are in the zone thinking through a problem, we often keep down the same path. Even when it is clearly the wrong one.
Be open to hints. If you haven’t gotten anywhere on the same problem for 15 minutes, consider taking a breathe and trying to make sure you are going the right direction.
If you haven’t found the correct solution for an abnormal amount of time, and you know that you still have three or four problems that you need to answer, then consider taking a minute or two to make sure you really are going down the right path. It’s hard to do, but you don’t want to over commit to the wrong solution.
Don’t talk badly about technology stacks
Look, we get it. You love Hadoop, or Go, or some other specific language or infrastructure. You might even hate other ones.
That doesn’t mean you need to let all your hate for a specific language be known. It often comes across as elitist. Like you know better than other people because your language is obviously the best and everyone else is programming in the stone ages.
Teams and companies use a variety of languages. If you start to talk down about a specific tech stack, you might be talking down about their tech stack.
Now, if you have languages you love, then feel free to bring that up. But generally speaking, having negative opinions can come across wrong.
Don’t let one bad interview ruin your next few
This sounds somewhat similar to not letting one round define you, but this goes bigger. Don’t let one bad interview define you. Many of us will have gone through multiple interviews and failed multiple interviews.
It never feels good to get an email or phone call that comes across as:
“Sorry, you’re not good enough”
It feels terrible.
But, you can’t let one or two bad interviews beat you down. We have seen people get interviewed by the same company multiple times in the same year until they got the job. Letting one interview define the rest is a mistake.
We honestly noticed some negative sentiment when we recently posted our software interview guide on Reddit. All we wanted to say to everyone interviewing is don’t give up.
There is a lot to study and you probably won’t get through all of it. It’s OK. Just keep positive and the right door will open.
Conclusion
Technical interviews are tough. Interviewers aren’t just looking for programmers, they are often looking for independent thinkers who can take ownership of projects and work. Job descriptions seem to want programmers with over five years of experience, who can code in 30 different languages, and who know how to work with every cloud technology under the sun.
Don’t let it rattle you or dissuade you. Keep applying!
Don’t Give Up!
If you are interested in more videos and posts about data, software and tech, then read the below!
Dynamically Bulk Inserting CSV Data Into A SQL Server
7 Habits Of Highly Effective Programmers
How To Get Your First Consulting Client As A Data Scientist
How Algorithms Can Become Unethical and Biased
Data Science Consulting; How To Get Clients
How To Develop Robust Algorithms
4 Must Have Skills For Data Scientists
SQL Best Practices — Designing An ETL Video
