How to Ace a Technical Interview



Nothing strikes more fear into a tech professional than the prospect of a technical interview. Being challenged by the blank slate of a whiteboard while an interviewer waits for you to prove you’re a 10x-er is enough to make any developer consider switching careers to an artisan cheesemaker. In this article, we will explore how to prepare for that challenge, so you don’t have to move out to the country (where Netflix still has to buffer before each episode).


Whether you have an opportunity lined up or are merely considering a career change, properly preparing is essential to ensure a successful interview. Not only are you competing against the test, but also the other applicants who are taking it, so it is essential to stand out and perform well.


As an experienced full-stack developer who has participated in technical interviews on both sides of the table, I’ll discuss lessons learned from bombing out of Facebook’s tech screening and give you insights from an interviewer’s perspective. We’ll also cover the technical aspects of interviewing at Scalable Path.


Since this topic has been explored in depth before, we’ll take a more modern approach by providing universal advice that applies to candidates interviewing at a tech giant like Google, a fast-moving startup, or a run-of-the-mill SMB far outside of the valley. I’ll explain why memorizing algorithms and practicing coding are only part of the picture, and ultimately help you focus on the blind spots that often trip candidates up and potentially cost you an offer.


Now, let’s now take the time to dive in and get prepared for that interview.


Types of Technical Interviews


The tech industry is known for having one of the most varied and challenging sets of technical interview formats. These formats can generally be broken down into two categories, academic and practical:


Academic formats test fundamentals and concepts via abstract challenges, similar to testing in a school setting. Practical interviews evaluate candidates against more real-world problems, indicative of what they may be faced with in their actual job role.


As the industry improves its processes, it has begun shifting towards more practical formats. However, academic-style evaluations are not uncommon, especially among tech giants aiming to hire only the best and brightest.


Let’s take a look at the different ways that technical interviews are administered and what classification they commonly fall under:



  1. Call screener: During the first or second call screen, expect a series of trivia-style technical interview questions with black and white answers, serving as an initial filter. These questions will generally cover basic academic concepts plus practical domain knowledge and should be easy to answer if you’re suited for the position.

  2. Interactive coding session: You will work with the interviewer to solve challenges in real-time. These tests are typically administered online using a shared text editor or your own IDE via screen sharing. Expect to be solving a mix of academic-style programming challenges and compartmentalized real-world tasks like writing a class or function to reach a specific goal.

  3. Take-home: A practical exercise typically completed within a day or two of being given. Expect to complete a basic app or task in the tech stack used by the organization you’re applying to. With this type of test, pay attention to code quality and standards.

  4. Spot the errors: You’re given an existing code segment, and you trace through it to identify potential problems. This may mean locating syntax errors, logic problems, missed edge cases, or performance issues. This practical exercise should be familiar to those experienced in code review.

  5. Whiteboard: An in-person and often more in-depth version of the interactive coding session. This type of technical interview often leans towards the academic side, focusing on algorithms and fundamentals, but it can also cover more practical topics.

  6. Loop interviews: Common among larger firms, this is a series of one-on-one interviews with your prospective peers and managers to test your fit in the organization. It’s likely to combine several of the previously mentioned formats, along with general talk-centric discourse. They offer a great opportunity to ask questions and get a feel for where you’re looking to work.


Due to the variance in formats, it’s important to identify what you’re up against to properly prepare. As a general rule, startups and SMBs are more practical-focused and will test you on language specifics based on the tech stack they use. Industry giants are more likely to administer primarily academic-style evaluations.


When given the opportunity to ask questions during the initial screening process (or via follow-up email), get as much information as you can about how the technical assessment is conducted. Ask about the format and how it’s administered, whether it’s practiced using a specific language or pseudocode, and whether the focus leans more towards practical or academic questions. Companies generally have no problem sharing this information and want you to be prepared, so you’re comfortable throughout the process.


Once armed with this information, you can focus your preparation to match the format.


Academic Technical Interview Preparation


It’s time to brush the cobwebs off the university textbooks propping up your computer monitor. If you want to land a job at a place like Google, Apple, or Amazon, you’re going to have to nail your fundamentals. Even if you’re just out of school, it’s time for a refresher on your building blocks for whiteboard and coding exercises. This means covering the following topics:



  1. Data structures: Strings and string manipulation (especially substring operations), arrays, stacks, queues, trees, graphs, maps, linked lists, etc.

  2. Algorithms: Sorts and searches, when to use which algorithm, the algorithm itself, and its associated tradeoffs.

  3. Concepts: Big O notation, parallelism, recursion, dynamic programming, memory management, caching, and performance.


Once you’ve reacquainted yourself with these concepts and addressed any knowledge gaps you may have (hello, Wikipedia!), it’s time to put them into practice by doing some programming challenges. Try to pick some problems that cover the pure fundamentals, such as array and substring manipulation, then move on to more detailed, less abstract challenges.


Are you looking for sample questions to test your skills? In the resources section at the end of this article, you’ll find sites and tools that offer programming exercises to help you practice for the theoretical topics featured in the more academic-focused interviews.


In addition, here are some very basic tips for approaching things:



  1. Use explicit variable names, not x, y, z (though “i” is fine as a loop iterator). Remember, your code needs to be comprehensible to the interviewer.

  2. Mind your if/else structure. I know this is basic, but it’s a red flag if you write two if statements in a row that should be an if/else (if) block.

  3. Remember to break out of loops once they’ve served their purpose.

  4. Hashmaps are your friend, and can often save you from having to use nested loops. Let’s say you have two arrays of strings and are challenged to output the strings that occur in both arrays. Instead of looping through the second array for each entry in the first array, consider turning the first array into a map by iterating over it once, then iterate over the second array, performing lookups against the map. You may be able to use the language’s built-in capabilities (such as Javascript’s “map” or “reduce” functions) to do this for you.

  5. Go back and review, test, and optimize your solution. In an interview, you may satisfy the interviewer by simply stating how you would improve a solution.


How much time you spend on this area of study is a judgment call depending on the type of organization and role you’re applying for. Remember to ask your recruiter or hiring contact about the format to inform your decision. Academic exercises are only one aspect of preparation, so they shouldn’t be your sole focus.


Practical Technical Interview Preparation


Less arduous and more straightforward, practical evaluations involve testing applicants on the subject matter most relevant to their would-be role. We all know (interviewers included) that in the real world, Google and Stack Overflow are at your fingertips, and you will never have to build a red-black tree with nothing but a fistful of whiteboard markers and vague memories of your Algorithms 101 class. Instead, interviewers simply want to see that you know how to code (preferably in the language they use) and how to design solutions to practical problems.


By now, you should be familiar with the company and the role you are applying for, and the technology relevant to your position. This will guide you while preparing for the practical aspect of the technical interview.


For entry-level positions or unfamiliar technology, start with the tutorials on the official website of the language, library, framework, or technology you are studying. From there, and for more experienced individuals, seek out advanced tutorials and exercises from other sources. Then graduate to building projects you have designed. Think of an idea for a basic app using an appropriate technology stack, then wire up its views, data model, endpoints, and storage. Not only is this valuable coding practice, but it can also bolster your portfolio and GitHub pages.


Vendor sites (and other sources) cover the core principles behind their language, library, or framework. This also includes advanced topics specific to the subject matter, which can be important to know during an interview. If you are trying to become a React developer, you better know the flow of properties and state, and the dogma of immutability, before walking in the door. Take time to review this material prior to the interview.


Nice to have: For ancillary tech that you have never used before but is listed as “nice to have” on the job posting, consider giving yourself an introduction to it. A little effort along these lines can go a long way during an interview. It shows initiative and that you are serious about landing an offer. Just be sure to mention it if it doesn’t come up!


This flows into the field of Systems Design, which is especially relevant when applying for more senior roles. Be prepared to answer questions about tech stacks, architecture, and scalability, particularly relating to challenges the company has faced in the past or may currently be facing. Have an elevator pitch ready on how you would design an app for “the Uber of Lawn Maintenance” or “like Facebook but for Concert Musicians.” Consider what challenges there would be during development and how you would address them. This is a common style of question that comes up during practical interviews.


Ultimately, you need to tailor your preparation for your experience level versus the job requirements. Try to reach a point where you aren’t searching or copy/pasting from reference materials much when coding, especially while bootstrapping a language-specific project. Be ready to explain how you would architect a system from the ground up, making design decisions that cover edge cases and plan for growth. Demonstrating your competence with the subject matter is key to getting through the interview and on to the next phase.


Scalable Path’s Process


At Scalable Path, we take a more modern and practical approach to technical interviews. Our focus on remote work and close relationship with our developers led us to put aside the infamous whiteboard and replace it with a format we view as more approachable and indicative of a candidate’s fit for the role.


These interviews are virtual but should be treated in a similar way to an in-person one. Dress appropriately, and be attentive to your body language, audience, and environment. Do a tech test ahead of time to ensure that your internet connection is stable and that your microphone and webcam are working properly, with little to no choppiness. Take a look at what is in the frame of your camera and tidy up as necessary, while also minimizing any sources of background noise. Having a clear line of communication and professional engagement with your interviewer is essential to advancing forwards.


Once a candidate has reached the technical phase of the interview process, they can expect to engage in an online interactive coding session for approximately an hour. During the session, applicants use their own development environment and reference material to complete a task as similar to a real-world scenario as possible. Reference material can include a previous project the candidate has worked on, documentation, and online resources such as Stack Overflow and Google.


Basically, think of it as an open-book exam. I don’t know about you, but these were always my favorites during school.


The candidate is evaluated on their ability to do something typical, like connecting a basic front end to a set of REST endpoints and the underlying database. They may find themselves wiring up typical GET, PUT, and POST calls to cement the foundation of a basic web app, all common activities for a web developer.


Throughout the session, the interviewer observes the individual’s development process, aptitude for the task, and details like how they utilize their reference material. To conclude, they recap the result and ask a few questions about the process and design decisions the candidate made. In some cases, this may lead to a take-home component for certain positions.


We have found that this method of interviewing is a strong indicator of a candidate’s suitability for their targeted role and gives them the opportunity to perform at their best. There are no trick questions or esoteric algorithms, just straightforward and (hopefully) familiar tasks. Most developers have a story or two about such interviews, myself included.


My Interview with Facebook


Many years ago, out of the blue, I was contacted by Facebook to see whether I would consider relocating to California for a job opportunity. I hadn’t applied, and to be honest, I think they found me via some bot that was scraping Facebook profiles for keywords like “PHP,” which I had previously posted about. Although employed at the time, I decided to move forward with their interview process to see where it led.


Things moved quickly, and after passing a typical HR and tech screening call consisting of trivia-style questions, I was faced with the first real test in the form of a remote interactive coding interview, which would happen a few days later. I scrambled to prepare, cramming my head with algorithms and hacking through as many programming challenges as I could find. Soon enough, it was time for the interview.


On the call, we launched into the questions almost straight away. A series of problems were pasted into a shared editor one at a time, which I had to mentally parse and solve before moving on. Stressed and conscious of time, I quickly read each question and jumped to coding, trying to reach a solution as fast as possible. I muddled through some problems, froze up or passed on others, and before I knew it, the interview was over.


Off the call, my mental fog gradually cleared. I realized that I had missed things in the initial problem statements, made silly mistakes, and produced a poor interview result. I had also failed to listen to hints posed as questions by the interviewers, treating it more like a one-sided academic exam with real-time observers than a collaborative exercise and dialogue.


Ultimately, I missed out on the opportunity by failing to properly prepare. By this, I don’t mean that I hadn’t studied hard enough or done enough practice problems, but I had been too focused on the raw academic aspect. I had overlooked the fact that there is a bigger picture and a lot more going on during an interview than just solving problems, which is something that all candidates should consider before an interview.


The Softer Side


Like with relationships, the key to acing a technical interview is communication. You have to demonstrate to the interviewer your process of approaching a problem, clarifying requirements, engaging with stakeholders, and only then producing a solution. Think of it as a microcosm for the day-to-day life of a professional developer. This may seem obvious, but it’s easy to forget, especially coming from an academic environment, where there is often no direct engagement during exams.


Although I had the fundamentals needed to answer the questions during my Facebook interview, I overlooked the above in preparing for the format. What I should’ve done, and what I recommend to you for similar formats, is the following:



  1. Don’t curate your practice problems ahead of time; jump in straight away or have a friend compile a list for you to tackle.

  2. Run through problems on an actual whiteboard or paper, and speak out loud as if there were an interviewer in the room. It may seem silly, but Duck Debugging works for a reason.

  3. Carefully read the problem statement, distill it down, and state what is ultimately being asked. During the interview, this is a chance for you to demonstrate your comprehension of the problem and ask clarifying questions.

  4. Be mindful of the problem’s details. If it mentions that you’re given an array of unique values vs. just an array, this may be an indicator that you should be using a map.
    Ask about edge cases and scope, and state what your initial approach will be. Clarify any points you’re unsure of.

  5. Proceed through the problem while engaging with the interviewer. Explain what you’re doing and listen to any feedback or questions they give, as these may be hints.

  6. Complete the problem and review your solution with the interviewer. They will likely ask questions about the decisions you made. This is also an opportunity to state how your solution could be improved or optimized, giving the interviewer the chance to engage on that point if desired.


Basically, I’m saying you need to simulate the environment of the interview as closely as possible, but more importantly, you need to engage and communicate along the way. Speaking from experience on the other side of the table, this is key to setting yourself apart from other candidates.


As an Interviewer


After bombing my technical interview with Facebook, I stayed with the company I was at for several more years while it grew. I found myself becoming the go-to person to perform technical assessments as we looked to hire more developers, which also informed my perspective of interviews.


As an interviewer, I’m looking to judge a candidate’s general fit for the role, as demonstrated by the communication skills discussed earlier. Beyond that, I want them to exhibit a solid understanding of the subject matter and the ability to tackle the kind of problems they will face in their prospective position. It also helps when candidates show that they are passionate about technology and involved with it beyond a purely professional level.


I want you to know that the interviewer is on your side. Everyone finds this process stressful and shows up nervous, and we’re empathetic to that. Don’t think of stress as a disadvantage unique to you, because it’s something that affects every applicant’s performance. Everyone is out of their comfort zone during an interview.


If your nerves are a significant concern or you just want to be especially prepared, there are services that offer mock interviews (listed in the references section) that can help on this front. Also, keep in mind that even if you don’t get an offer, you are building a muscle that will serve you during your next interview. Try to separate your performance during the experience from how you perceive your capabilities as a tech professional. Even the strongest candidates can get caught off guard, have a bad day, and produce poor results. These outcomes are not failures but simply learning opportunities to serve you in the future.


And don’t forget, it’s okay to ask questions leading up to a technical interview — we want you to be prepared so you can perform at your best.


Final Thoughts…


Let’s recap. The most important preparation isn’t memorizing algorithms; it’s being mindful of how you conduct yourself and engage with the interviewer. Being able to nail the subject matter is a given, but what sets you apart as a candidate is demonstrating your suitability for the role beyond simply producing the requested output.


When you’re practicing technical challenges, practice in a way that mirrors how questions are likely to be administered during the interview.


Be sure to inquire about the format of the technical portion, and take time to research the employer and role. Are they a startup focused on hiring a language expert who can deliver quality code quickly? Are they an established company that may care more about fundamentals, system design, and your ability to unravel problems? This will focus your studies and prepare you to offer relevant answers to their questions.


Remember to keep the interviewer’s perspective in mind. Communicate with them during the process, ask questions, and be clear on your approach to the problem.


Now it’s time to get studying. Be sure to check out the list of resources to help you prepare, and good luck! Do you have an interesting story about your experience with technical interviews or advice to offer our readers? If so, consider leaving a comment on this article below.


Resources for Your Technical Interview



Are you searching for your next programming challenge?
Scalable Path is always on the lookout for top-notch talent. Apply today and start working with great clients from around the world!


Post a Comment (0)
Previous Post Next Post