Seven Mistakes To Avoid In Your Technical Interviews
Email Newsletter
Weekly tips on front-end & UX.
Trusted by 200,000+ folks.
I have failed many technical interviews. Year after year would pass and I would slowly progress in my technical interviewing skills. It wasn’t until I received my dream job offer from Spotify and had passed the Google technical interviews that I realized how much I had learned over the preceding years. Finally, my studying had paid off! This was also around the time that many developers began losing their jobs due to COVID.
“If I have difficulty passing data structures and algorithms interviews with a computer science degree,” I thought, “I can’t imagine how overwhelming these concepts must be for self-taught developers.” So for the past year, I’ve made it my mission to make data structures and algorithms approachable for everyone.
I found it incredibly difficult to find one resource for learning everything about the technical interview process. From the recruiter’s phone call to the systems design interview to negotiating a job offer, there was no all-encompassing technical interview resource, so I decided to create one.
A Note About Remote Interviews
Due to the global pandemic, many companies have gone fully remote. This is great as it allows candidates across the world to apply, but this can be daunting for candidates who have little-to-no experience with online interviews.
Here are a few tips for your virtual interviews.
- Arrive early.
There is nothing more panic-inducing than going to join an online meeting and realizing you need to download an entire package of drivers to run the program. I recommend creating an account with the meeting application ahead of time and running a test meeting with a friend to ensure you have access to the application and feel comfortable using the online controls. - Use headphones.
I always recommend using headphones for your remote technical interviews. They’ll help reduce background noise and ensure you hear the instructors clearly. - Charge your computer.
Remote meeting tools can quickly drain your computer battery, especially if you’re live coding. To combat this, have your computer plugged in for the entirety of the interview if possible. - Test your camera.
While remote interviews allow us to be in a safe and familiar environment, we can often forget to remove unsavory items from the background of our video frame. I always suggest running a test meeting to check your video frame and remove the dirty laundry from the background. You can also use a virtual background for your remote interview if your background is not ideal.
The Technical Interview Process
When you begin the technical interview process with a company, your recruiter should inform you about what you should expect from the process. One reason why technical interviews are so anxiety-inducing is the lack of process standardization. A technical interview at one company can look incredibly different from a technical interview at another company. But there are some commonalities between technical interview processes that you can prepare for.
Here is a generalized version of the technical interview process that you’re likely to see in your upcoming interviews.
Recruiter Phone Interview
Your first interview will be a recruiter phone interview. During this call you’ll discuss the job, the company, and what you can expect from the interview process. Do not take this interview lightly: all interviews in the technical interview process are vital to landing you a job offer. If you don’t seem excited about the role a recruiter might not move you forward to the next phase of the process.
If you’re applying to many different job openings, I recommend keeping a spreadsheet of the roles, companies, recruiter information, and any relevant information. You should refer back to your notes prior to the recruiter phone interview to ensure you’re well-informed and leave a great impression.
Technical Screening
If the recruiter’s phone interview goes well you will likely move into a technical screening interview. This interview may be asynchronous where you don’t interact with a human interviewer and instead complete the coding challenge on a platform with a time limit, or you may have a live interviewer.
Companies typically conduct technical screenings to ensure a candidate has the baseline technical knowledge required to thrive in a role. It can be expensive to fully interview every single candidate so a technical screening is a way to reduce the candidate pool.
You will be coding in this interview so it’s important to feel confident in your foundational programming language.
Take Home Project
Some companies require a take-home coding project in lieu of a coding challenge, or in addition to a coding challenge (again, all processes are different so consult your recruiter for the specifics).
Coding projects are a polarizing topic: some candidates love them while other candidates find them unfair. On one side, coding projects allow you to showcase your skills in a more natural environment, using the tools you love. On the other hand, these projects can be a way for a company to receive free (often unpaid) labor.
Many candidates with families, multiple jobs, or other time-consuming commitments likely don’t have the time necessary to complete a take-home coding project, which can lead to an unfair advantage for candidates without the same responsibilities.
If you’re tasked with a take-home project and do not have the time required to devote to it, you can ask the recruiter if there is an alternative. It might also be worth asking if you will be compensated for your time spent on this interview (some companies will pay you, although all of them should).
On-Site Interviews
The “on-site” interview phase is likely the last phase before ultimately receiving a job offer or a rejection. Many companies used to fly candidates to their offices for a full day of interviews, but due to the pandemic, these interviews are being held virtually.
Many candidates find the on-site interviews to be the most stressful as it requires you to take a vacation day from your current role to complete them. You will likely have three or four interviews (typically a half-day) consisting of a process/values/collaboration interview (how do you collaborate with your team, how do you resolve conflicts) and coding interviews.
The on-site interviews are stressful so remember to take breaks and decompress before each interview.
Notes On The Interview Process
The technical interview process is intense and can leave you burned out. Make sure you’re taking time to decompress after each interview and reflect on how it went. Were there interviews you struggled with more than others? If so, focus on those areas for your next interview process; some recruiters will even provide you with interviewer feedback so you can hyperfocus your studying.
You should also reflect on how you felt during the interview process. Did the interviewers make you feel safe and comfortable? Was this even a work environment you would thrive in? Remember that technical interviews are a two-way street.
Now that we’ve detailed the technical interview process, let’s dive into the seven mistakes candidates commonly make, and tips for avoiding them.
Mistake #1: Not Communicating Effectively
Technical interviews are supposed to measure your communication and problem-solving abilities, not necessarily whether you achieved the optimal, working solution to a coding challenge. Problem-solving is all about communication, but did you know that each culture has a different definition of what it means to be a “good communicator?”
There are two different types of communication:
- Low-context
Very explicit, redundant, and straight to the point. Messages are stated clearly and should be interpreted at face value. - High-context
More ambiguous where listeners are expected to read between the lines (or read the air) and interpret the hidden message.
During a technical interview, it’s imperative to practice low-context communication, regardless of how you’re used to communicating. If you need a moment to think, tell your interviewer. If you need help, ask for it!
Often candidates don’t move on to the next interview phase because they failed to communicate effectively. If you think of the interview as a conversation rather than an exam, you’re more likely to communicate effectively.
Mistake #2: Not Admitting When You Don’t Know The Answer
If you don’t know the answer to something, admit it! Interviewers appreciate when a candidate is self-aware and humble enough to admit they don’t know the answer to something. It’s much better to admit you don’t know something than to “BS” your way through it.
If you’re unsure how to answer a question you can say, “To be honest I’m not sure. If I had to make an educated guess I would say…” People don’t want to work with “know-it-all”s; they want to work with real humans who can admit they don’t know the answer.
Mistake #3: Cramming The Night Before An Interview
Let’s be honest: we’ve all crammed for an interview the night before. It’s exhausting to make time to interview but the reality is that interviewing is a skill (sadly) and it must be practiced.
Although you might feel like you’ve learned something whilst cramming the night before an interview, this learning is volatile and superficial. Our brain only encodes information into short-term memory when we cram the night before an interview. This means that all that information you just “learned” will dissipate quickly after the interview. Thus, it’s better for your long-term memory to do a little studying in the weeks leading up to an interview than cram the night before.
Additionally, you’re more likely to regurgitate information than actually understand it. It will become apparent very quickly if you’re just reciting information you memorized as opposed to working through a solution.
One strategy for effective learning is to use context-switching as a tool. While switching contexts in the midst of learning a new skill seems ineffective, it’s actually the most effective learning tool. When you context-switch during learning, it’s more difficult for our brain to recall information, ultimately strengthening the encoded information and making it easier to recall in the long run.
If you want to read more about effective learning methods here are a few resources that helped me:
- “Atomic Habits,” James Clear
- “Learning How To Learn,” Coursera course
- “Make It Stick ,” Peter C. Brown, Henry L. Roediger III, Mark A. McDaniel
Mistake #4: Memorizing Code For Algorithms & Data Structures
Candidates often feel they must memorize code for algorithms and data structures, but the reality of it is you likely won’t have to code these things from scratch. Regurgitating code is not a useful skill and your interviewer will be able to tell you’ve simply memorized a solution. Instead, you should aim to understand the process of what you’re accomplishing.
Additionally, you don’t need to learn every single sorting and searching algorithm ever invented. Instead, you can determine the optimal solution for different data structures and learn the concepts behind it. For example, if you’re asked to sort an array of integers, you might know that a divide-and-conquer algorithm like merge sort or quick sort is a great solution. If you understand the concept of how an algorithm or data structure works, you can build the solution.
Lastly, most coding interviews will be conducted in the foundational programming language (even if a company is looking for a React/Vue.js developer): you likely will not be asked to code using a framework or library, so make sure you’re confident in your foundational programming knowledge.
Mistake #5: Overlooking The “Cultural Fit” Interview
All interviews throughout the technical interview process are important, however, there seems to be a focus on data structures and algorithms. And while data structures and algorithms are an important area to study, you should give the other interviews in the process the same attention: Don’t prioritize data structures and algorithms over other “easier” interviews like the “collaboration and process.
The “culture fit” interview is meant to discern how you collaborate and handle conflicts in a team. You’ll likely receive questions such as:
“Tell me about a time a project you were working on failed. Why did it fail and how did you move forward?”
or
“Tell me about a time you had a conflict with a team member. How did you resolve it?”
Write down your responses to these questions and practice answering them out loud. You don’t want to sound rehearsed but you want to be succinct and not ramble. Keep your response to a few sentences. Additionally, eye contact and body language are important.
Try not to fidget and focus on making eye contact with your interviewer!
Mistake #6: Starting With The Optimized Solution
Unless you are 110% confident in the most optimized solution for a coding challenge, you don’t have to start with the most optimized solution. Candidates often think they have to start with an optimal solution and it trips them up. They get stuck and can’t move forward. Instead, start with a non-optimal solution and say:
“I know this isn’t the most performant solution but I would like to get a working solution and refactor it for performance later in the interview.”
Your interviewer will appreciate your honesty and regard to performance. You’ll also be able to make progress more quickly, and in an interview, small wins can have a huge impact on your self-confidence and overall performance.
Mistake #7: Overlooking Programming Foundations
Candidates for front-end developer roles neglect their HTML and CSS skills to prioritize JavaScript, but more interviews are testing knowledge of the foundational programming skills so don’t neglect them.
We often forget the foundations and skip to the more expert-level framework and libraries but this can hinder our interview performance. Interviews are conducted in the foundational languages (i.e. JavaScript, not React/Vue.js), so don’t neglect the foundations.
Conclusion
Everyone has anxiety over the technical interview process but by being mindful of these seven mistakes, you can improve your chances of landing a job offer.
Once you do receive a job offer you can decide whether or not you want to negotiate. There are many things you can negotiate: paid time off: working hours, equity, signing bonus, job title, and salary are just a few.
When negotiating a job offer it’s important to do your research. How much does someone in this role (and in this geographic location) make annually? You can use Glassdoor to do some market research.
You should also recognize that the recruiter has constraints and might not be able to get you a higher salary. Instead, you can ask for a signing bonus or equity, but be prepared for them to say they can’t increase your offer.
You should focus on “why” you should receive additional salary or benefits; what do you bring to the table that someone else won’t?
Lastly, don’t give a recruiter an ultimatum, i.e. “If you don’t give me this salary, I will walk away.” Instead, focus on the fact that you want to join the team but need an improvement/change to the offer to accept.
Here’s an example email you could use to ask for a base salary increase:
“Thank you so much for the offer. I’m genuinely thrilled and looking forward to joining the team. Before I accept the offer I’d like to discuss the base salary. I am an active member in the technical community and teach numerous courses online with X learning platforms. I know that my extensive knowledge of Y will greatly benefit the team. As such I’m looking for a base salary in the range of A to B. Please let me know if we can make this work and I’ll sign the offer right away!”
If you don’t get a job offer, don’t worry! Almost everyone gets rejected for a position at one time or another; you’re not alone! Take some time to reflect on your interviews and determine what areas you can improve for the next round of interviews.
If you want to learn more about data structures, algorithms, coding projects, culture fit interviews, systems design interviews, and more, check out my new book, “De-Coding The Technical Interview Process”. This book has been a passion of mine for the past year and has helped many developers land a job offer (including myself)!
Be patient with yourself. You can do this!
Further Reading on SmashingMag:
- Building Your Own Personal Learning Curriculum
- Improving Your Team’s Communication In The Age Of Remote Work
- Better Documentation And Team Communication With Product Design Docs
- Making Remote Work Work: Useful Tools And Resources
(vf, il)
