Pro-Tips to Ace the Technical Phone and On-Site Interviews
Welcome back! If you just stumbled upon this article, I recommend reading Part 1 How to land interviews because it offers the background and context needed in this article.
In this article, I will discuss techniques for phone and on-site interviews. I will assume you already have:
- A personal project under your belt and you have showcased it online
- Practiced enough LeetCode and some System Design questions. (In reality, you can NEVER do enough LC problems)
- Connected with a few recruiters via our multi-channel approach.
Step 4. Interviews
4.1 Phone Interviews
Initial HR Calls
Usually, the first contact with a company is a recruiter’s email. The recruiter would ask you for a time for an initial phone call, which is usually a “fit” call, where you discuss your interests and background and why you would be a good fit for the role. Don’t stress too much over the detail, as most likely, this would be a short call, and the recruiter would want to move you to the next stage, which is the Technical Phone Interview.
Before the Technical Phone Interview
One or two days before the technical phone interview, be sure to read up on Glassdoor and Leetcode for previously asked interview questions for this company. For big companies, such a Google and Facebook, this does NOT work well, as there are hundreds of previously asked questions. But for smaller companies, this is somewhat effective. I would scroll through many posts on Glassdoor and copy down any specific technical questions. Then I would try to solve all of them. During the phone interviews, it is pretty rare to bump into the exact questions posted online, but doing this company’s past problems better prepares you for this company’s phone interview . This is analogous to practice doing past years’ final questions before taking the final exam of the same professor — the questions may be different, but the style and type of questions would be similar.
Technical Phone Interviews
Technical phone interviews are where the rubber meets the road. The stage is designed to separate the capable candidates from the less-capable candidates. I have read that only about 10–20% of the candidates can pass the technical phone screens of top tech companies. The measuring stick is simply a coding test, NOT how well you talk, NOT how experienced you are at your current job, NOT how many programming languages you know, NOT even your personal projects. Most interviewers simply want you to complete a coding exercise in whatever programming language you are most comfortable in. Personally, I don’t quite agree this is the best way to find the best engineers. For example, I worked with many very experienced software engineers, some are expert GUI/app developers, some are C++ experts, others are low-level Linux gurus, but many of them tell me that they would fail miserably in a timed Algorithms and Data Structures (A&DS) coding test. But since this is the only game in town, in order to break into the tech industry, you have to “Crack the Coding Interview”…
The coding exercise is always done via a shared online notepad, such as CoderPad or Google Docs, where both you and the interviewer can type at the same time. While some companies, like Google and Facebook, only ask you to write down the correct algorithms and won’t ask you to run your code, many companies expect you to come up with fully working code within the 45–60 minutes time window. In addition to the shared notepad, most companies conduct voice-only calls, while some companies conduct phone interviews via Zoom/Skype video calls.
Personally, phone screens are the hardest part of the interview process for me. For reference, I passed about only 50% of my technical phone screens. They are difficult because:
- The 45–60 min time window is usually tight for me, as I am not fast at typing. (Believe it or not, I am faster at whiteboard coding for reasons I will discuss in on-site interview section)
- You need to code while talking with the interviewer throughout the call. Most people, including myself, prefer to discuss a design/approach first, and then type the code and debug in silence. But if you don’t talk for 20–30 min during your implementation stage, it would be very awkward.
- Online notepad is text-based and is not a whiteboard. So it is hard to draw a diagram or illustrate your code workflow graphically.
- Online notepads are NOT IDEs. While most of the online notepads, such as CoderPad, can do decent syntax highlighting and indentation, they are not full-blown IDEs. For example, they can not do word auto-completion. They can not highlight obvious syntax errors while I type and they certainly don’t support line-by-line debugging. So a lot of times, I had to resort to the “old faithful” print statements for debugging, which is very slow and clumsy.
- Voice calls are non-visual. As I try to explain my approach over the phone, I can’t draw a picture and can’t look at the interviewer’s facial expression or body language to gauge if I am on the right track.
Here are what I do to combat the above difficulties:
- Use a good phone headset. This should be very obvious because you want to free both of your hands to code! So invest in a good Bluetooth headset and make sure it is fully charged before phone interviews.
- Keep “Chit-chat” to a minimum. In my first couple of interviews, I would try to give the interviewer a good impression of myself. So I would spend about 5–7 min talk about my background, my experiences, and then my self-driving car. Sometimes, the interviewer would ask me a few questions, and it could drag on to the first 10 minutes! What I quickly discovered was that all these “chit-chat” time ate into the total 45 min allotted for my interview, which means I have less time to work on the coding problem. In fact, most interviewers are here to gauge your coding skills ONLY, and your strong work experience is not relevant to them at this time. So I learned to shorten the “chit-chat” to about less than 2 min at the beginning, and leave my questions to the end of the interview. In fact, if I finish the coding problem successfully, the interviewers usually are more willing to talk with me a bit longer than the 45 min slot. On the other hand, if you “bombed” the coding interview, chatting won’t change the outcome of the interview, anyways. Note that this tip applies to on-site interviews as well.
- Use two monitors. One monitor would be for the shared notepad, and the other monitors would be for googling and IDE, etc. Most laptops nowadays have ports for external monitors. Be sure you connect your laptop to at least one external monitor when you code, so you won’t have to flip back and forth between windows.
- Use an external mouse. If you use a laptop, be sure to invest in an external mouse. For me, using an external mouse significantly improves my ability to select, copy and paste code.
- Use an IDE. Even though you are coding in the shared notepad, sometimes, to troubleshoot, it may be better to copy-paste the code into your IDE, fix syntax errors and bugs, and then copy the working code back into the shared notepad. Most interviewers won’t mind, as long as you can get the code working within the allocated time. They want to see you succeed as well! Before your phone interview, be sure to set up an empty project where you can quickly paste in code and run. You don’t want to spend precious interview time to create a project and set up run parameters. Having an IDE open also means that you can directly paste in your code at the end of the interview so you can save a copy of the questions and your solution for further analysis.
- Use a programming language that saves you from typing. Most of the tips here are designed to help you save time TYPING, so you can spend more time THINKING about the solution. So try to choose a language that can do a lot with very little typing. My best languages are C++ and Python. I choose Python for all my interviews, unless an interviewer specifically requests C++, because it is so much more expressive compared with C++.
- Make good use of Google. This is one advantage of a phone interview over an on-site interview because you can google! If you are not too familiar with the API of a function, or certain syntax of a language, feel free to google it. It is understood you can google during a phone interview. Heck, if your interviewer is lazy and grabbed a problem verbatim from LC, then congratulations! ;-)
- Talk through your approach thoroughly with the interviewer BEFORE you start implementation. For my first few interviews, I would start coding after having a rough idea of what to do, thinking I can flush out the details as I code. This is NOT a good idea. Try to flush out as much as detail during your initial discussion with the interviewer will actually save you lots of time later on. The interviewer obviously is very familiar with all the good and bad approaches to the problem. If you present a suboptimal or incorrect approach, he/she may steer you towards a more optimal and/or may point out bugs/corner cases you forgot to consider. This would save you tons of implementation time down the road. But be sure to cover as many corner cases as possible on your own, you will get points deducted if the interviewer has to point out the missing corner cases.
- Solving the problem is better than not solving the problem. This statement may not be that obvious when you are searching for the most optimal solution. Sometimes, if I couldn’t conjure up the most optimal solution, I would propose and finish implementing a suboptimal solution. In any case, the fact that I came up with some working solution (albeit suboptimal) gave the interviewer a decent data point to compare me to others. In some instances, the interviewers told me, after the fact, that the “optimal” solution that I thought was possible does not exist! As I learned from my own failed experiences, not coming up with a working solution would certainly be a FAILED interview.
Remember, at this point, you should NOT be focusing on Systems Design questions, as they are only asked during on-site interviews because it requires a whiteboard to draw diagrams.
Online Coding Tests
I have encountered very few tech companies that still give online coding tests, such as HackerRank or Codility, although quite a few finance companies still give those. The reason to give these tests is to save hiring companies’ manpower. Usually, you would get a link to an online test from a company’s recruiter, there are usually 3–5 coding questions, which you need to complete within a 2–3 hours window. You need to complete it anytime within 7–10 days of the recruiter’s email. No human is overlooking you while you take the test, and you need to pass most test cases to pass this stage.
Here are some tips for online coding tests:
- Use an IDE: you can write and test your code entirely in your favorite IDE and then paste into the online test page to run the official test cases.
- Read all the problems before you start. Some online tests are designed so that most people can’t complete all questions within the allotted time. So be sure to read all the questions before you start any problems and start on the easier questions first so that you can finish as many questions as possible.
- Get it working first. For most of the online tests, time is a scarce resource. So the goal is generally to pass as many test cases as possible, not necessarily ALL the test cases. If you have a working solution, it should pass most of the test cases. If your solution is not the most time-optimized, you may time out on a few test cases, which is fine. Just move on to solve the next problem, come back if you have more time left. (Note: DO NOT do this when you are writing production-level code. For production-level code, DO spend the time to get your algorithms right and cleaned up, and add enough documentation so that you and others can maintain your code in the future.)
- Save a copy of the questions and your solutions for future analysis. This should be routine that you save ALL your interview questions regardless it is phone/online/on-site questions.
A few companies give take-home projects before, or in lieu of, a technical phone screen. I had two companies that gave me take-home projects, both of which are Machine Learning related. I have found these projects much more enjoyable and more relevant to the job that I was applying for. So I wish more companies would give take-home projects in lieu of technical phone screens. But I do understand that it may not be as effective or as fair because 1) companies don’t know if you or your ML expert friend did the project, and 2) even if you did it yourself, how long did it take you.
For take-home projects, since you typically need to spend a lot of time on it, make sure you are using your time wisely. For a company that you are really excited about, yes, do spend the 8–10 hours do a nice job coding and documenting your approach and design decisions. For Scale.ai’s project, I spent at least 10 hours to work on their project — even though the instruction tells me to only spend about 2–3 hours — because I thought it was fun and I learned a lot by exploring different ML approaches. For companies you are not so excited about, don’t spend that much time, and save the time for more LC problems, so you can be better prepared for coding interviews in general.
Once you have done a few phone interviews, you should be getting some on-site interview invitations. In the beginning stage of your phone interview, your success rate will be somewhat low. I literally failed all of my first 4–5 phone interviews. Then I realized that I needed to focus on practicing more dynamic programming and recursive algorithms. Your experience may be different, but don’t be discouraged when you get rejection emails in your interview process. Ask the recruiters for feedback and study more. There are a lot of companies out there for you to try.
Here are some interview scheduling tips:
- Keep a detailed interview log: This is the same log mentioned in Part 1. Now it is the time to start to keep track of when and what was discussed in each interview.
- Put all interviews in your calendar and set reminders/alerts. You don’t want to miss a single interview because you forgot about it. Also, make sure you confirm the interview time zone. For simplicity, I always communicate to recruiters in their time zone (usually this is Pacific Time).
- Schedule back-to-back phone interviews with at least 30 mins in between. This is because some interviewers may call 5–10 min late, and some interviewers may allow the interview to go over the time limit by 5–10 min. So if you set two phone interviews back-to-back, you may have to cut one short or miss the other call. Plus you need a 5–10 min break to clear your head and write down the interview notes.
- Ask for a Second Chance. This may be a little known fact. If you fail the first phone interview, many companies would allow you to have a second chance. Most won’t offer it automatically, but would if you ask nicely. So always ask, but schedule it a few weeks after the first interview, so you have enough time to study. There usually won’t be a third chance unless you wait for 6 months.
- Stagger your interviews. I staggered my interviews in phases. I put the companies I believe are easier to pass in the earlier phase, and the harder-to-pass and more well-known ones in the later phases, which is about 2–3 weeks later. This way, if you discover you are weak in some topics, you have 2–3 weeks to study them.
- Cluster your on-site interviews. Because most of the companies that I interviewed with are in the Bay Area, I tried to schedule all of the on-site interviews within a 1–2 weeks span, so I could fly out once and get all these on-site interviews done. For example, my Bay Area on-site interviews lasted 2 full weeks, during which I interviewed with 6 companies — 3 interviews per week. Some companies would be more willing to bring you on-site if they know you would be in town for other interviews. Also, they don’t have to pay for your plane ticket. Various companies paid for some of the hotel nights, and I had to cover the other nights. This was fine for me, since it saved me a lot of time, and I was able to cluster all on-site interviews together, so I could hear back the decisions from all of them around the same time.
4.2 On-Site Interviews
2–3 weeks before the on-site interview, start to focus on System Design questions. Many companies allow you to schedule on-site interviews up to 4–6 weeks after you pass the phone interview. This should give you ample time to prepare for both A&DS and System Design questions.
Normally, there are 4–5 45 min interview sessions for each company’s onsite interview — 2 in the morning, lunch, and 2–3 in the afternoon. There would be 1 System Design, 1 Behavior and 2–3 A&DS coding interviews. Very few companies would ask you about math or brain teasers, so I wouldn’t spend a lot of time to prepare for them.
System Design Interviews
This was covered in Part 1’s Step 2: Interview preparation. If you watched all the system design YouTube videos I recommended and can generalize it to a framework similar to what I outlined, you would be in pretty good shape.
Clarify the spec. One important technique of the System Design question is to clarify the features and functionality of the system early on. You want to define a set of features that is not too trivial and not too complex that you can’t finish within the 45 min time frame.
For example, when asked to design an Instant Messaging App, be sure to mention essential features such as:
- User authentication (this should be in most systems)
- One-to-one messaging
- Group messaging
- User active status
- Offline messages (if you have time)
For a 45 min session, I would not mention these non-essential features:
- voice calls
- video calls
- multi-person calls
- personal timelines (i.e. Facebook Stories)
Of course, if you are asked to design Skype, you would have to design for voice and video calls, but I wouldn’t include sharing computer desktops just to limit the feature set to a manageable scope.
Watch for curveballs. During the interview, watch out for odd questions and be able to respond intelligently.
For example, when I was at the Facebook interview, I was asked how to design a simplified version of Google Search. I proceeded by drawing a pretty good high-level design on the whiteboard. Then the interviewer threw me a curveball:
Interviewer: “So how many servers do you think you need?”
Me: “Well, this depends on how many people are using it and how beefy the servers are…”
Interviewer: “Why do you need to know how beefy the servers are?”
Me: “My thinking is that the actual usage is sort of like the numerator, the server hardware capability is like the denominator, and the number of servers depends on these two numbers.”
Interviewer: “NOPE, the hardware spec of a server is irrelevant.”
Me: “Surely hardware spec matters. If I can host a service with 10 beefy servers, I would probably need 100 laptops to host the same service”
Interviewer: “Hardware spec is irrelevant.”
At this point, I was at a loss, because I thought he was being quite unreasonable. After some long and awkward pause, I almost gave up.
Me: “So what do you mean by hardware spec don’t matter”
Interviewer: “Pretend you don’t know the hardware spec of a server, how do you figure out how many servers you need?”
OH, THAT’S WHAT HE MEANT??!! He didn’t mean hardware spec is irrelevant, he just meant we don’t know the exact hardware spec.
Me: “Oh, in that case, I would have to benchmark the throughput of the servers, and the number of servers required is roughly the maximum usage divided by the throughput of a single server. Am I on the right track here?”
I could see him slightly nodding his head.
This moral of the story is to illustrate how important it is to clarify what the interviewer is asking/telling you. You can do this by repeating the question/statement back to them in your own words. If you are really stuck, ask them what they meant by what they just said. Maybe they will rephrase the questions/statements in a different way, so you can understand and proceed. Remember many interviewers are not native English speakers, so what they say and what they mean to say may not exactly match, similarly many interviewees (yours truly included) are not native English speakers either, so what they hear and what they think they hear also may not exactly match. Having the interviewers say the same thing in different ways may greatly help interviewees understand what the interviewers truly mean.
Whiteboard A&DS Coding Interviews
On-site A&DS questions are almost exclusively done on whiteboards. Many people, including myself, are scared of whiteboard coding initially, because who in real work setting write detailed code on whiteboard?! But as I went through all these onsite interviews, I have found that whiteboard coding is, in some sense, easier than phone interviews. I will cover some techniques specifically for whiteboard coding below.
Illustrate your algorithm with diagrams/charts/tables. There is an old saying, “A picture is worth a thousand lines of code.”, or something like that. Before you write code, try to illustrate how your code would work with diagrams/charts/tables. This will give your interviewer a road map of what your code might look like, and allow the interviewer to point out any potential issues that he/she sees. Once you are done coding, try to walk through your code line-by-line with the diagrams on the side, so that you can show the interviewer that your implementation matches what you intend to do. Be sure to watch Tushar Roy’s LeetCode Hard Solutions YouTube videos to learn how to present ideas on a whiteboard.
Split the whiteboard into sections. For reasons mentioned in the previous tip, I recommend splitting the whiteboard into at least 2–3 vertical sections. One section would be reserved for diagrams, and other sections would be for code. This way, you can always refer to the diagrams before/during/after you code.
Don’t sweat the syntactic details. If you are allowed to code in any programming language (as this is the norm), then the interviewer would not be very picky on the syntax of your code. For example, if you miss a trailing semicolon in C++/Java, or trailing colon in Python, it is not a big deal, as long as your indentation is correct. Or if you misspell or shorten the name of a built-in function, it is also not a big deal, as long as the interviewer understands what your intention. On the contrary, you are not afforded the same luxury in phone interviews.
Use shortened variable/function names. Because writing out long names with a marker can take a long time and a lot of space, tell your interviewer the full name and meaning of a variable, and then use the shortened name in your code. This will save you a lot of precious time as well as precious whiteboard space.
Constantly Seek Feedback. This is one of the many benefits of an on-site interview because you can quite easily gauge the feedback of an interviewer. When I present my design or approach, I would regularly check the facial expressions of the interviewer and ask casually, “Am I on the right track?” or “How does it look?” Usually, the interviewers are pretty helpful and would give you some feedback, or at least nod or frown. If you are way off, they would surely let you know, if you ask. As I found out the hard way a few times, when I didn’t seek feedback, some interviewers would let me finish the whole implementation and then point out some major flaws in the end. As a result, I failed all those interviews miserably. So try to flush out your design as much as possible before coding and seek feedback.
Other On-site Interview Tips
Some of these non-technical tips may be common sense, but I will list them as a reminder.
Ask good questions at the end. You probably won’t have a lot of time to ask questions at the end of each interview session. So keep these questions short and impactful. The interview is a two-way process, companies are trying to extract information from you for their evaluation process, and you need to do the same to these companies, so you can make the most informed decisions when you get offers.
Here are the typical questions I like to ask:
- Can you tell me about your background and what you do in your current group?
- Can you tell me about the technology stack and development process in your group/company? Once the interviewer mentions a few programming languages or tools, you can echo by saying you also have worked with these technologies.
- What would be an ideal candidate for your group/company? Once the interviewer mentions a few characteristics of the ideal candidate, you can echo by saying you also have some of these characteristics and give a quick example to back it up.
- Sell yourself a bit. This may not work for everyone. I also used the “questions” time at the end of the interview to show my self-driving robotic car and a couple of YouTube videos of the car to the interviewers. I think it worked out surprisingly well because I saw most interviewers were quite pleasantly surprised when they held the actual car in their hands.
Stay hydrated. You will be talking a lot during the interview, and you will be sweating a lot (unconsciously), so you always want to be hydrated at all times. This means refilling your cup after every interview session, and taking a sip whenever you are not writing on the whiteboard. I find caffeine (coffee/tea/Coke) to be quite effective at keeping me at peak performance.
Take washroom breaks. After each interview session, be sure to take a washroom break. Unfortunately, these 45–60 min interview sessions are usually back-to-back with no breaks in between. So be sure to ask for one before the next session starts. You want to be able to walk and stretch your legs a bit and more importantly, wash your hands and face, so you can go to the next interview refreshed. Don’t take too long a break though, because the break time eats into your next 45 minutes.
Take notes. I always keep a detailed log of my interviews. Since most of your interview sessions are back-to-back, so the only time you can take notes is during bathroom breaks. :) Bring your phone and quickly jot down a few notes of the questions and your approach so you can remind yourself after you are done for the day. This should take no more than 1 min.
Eat a light lunch. This is pretty hard not to overeat at lunch because many top tech companies have awesome free food! Facebook even has free ice cream! While it is tempting to try all the free food while you are there, you need to remember you are not there to eat just once but to interview and get the job, so that you can eat there every single day! Two obvious reasons for not overeat: first, you want to stay alert in the afternoon session and not feel drowsy, second, you want to spend most of the time chatting with your lunch buddy. While for some companies (Google/Facebook), your lunch buddy’s feedback is not part of the offer decision, many times, they are senior folks in the firms so their opinions may matter and you want to leave a good impression.
Pack some snacks. On the flip side to the last point, for some of my on-site interviews, either by design or due to time conflicts, the lunch is scheduled at 1:30–2 pm or skipped altogether! I would be so hungry by then and would be running on fumes. So I learned to always pack a granola bar and a few pieces of chocolate with me so that I can take a few quick bites in between interviews.
Bring a few resumes: Yes, most interviewers would indeed bring a copy of your resume with them. However, occasionally I encountered interviewers who didn’t bring a copy of my resume with them, so I just give them a copy. For tech interviews, it probably doesn’t matter that much, but it is a nice gesture.
Post mortem analysis. After you are done with the interviews for the day, don’t relax right away. While your memory is still fresh, go back to the hotel/home and immediately jot down as much detail about the interviews as you can, including interviewers’ names/background, all the questions asked, your approaches, interviewers’ answers to your questions, etc. Do this electronically (not on a paper notepad) so it is easier to search and archive later. Also, at a later time, revisit all the interview questions, get optimized solutions, and think about how you can improve your performance next time. If you find the interview questions on LC, be sure to tag the questions with the company names, so others can benefit from your experience.
The above are just tips and tricks that help you tip the scale in your favor a little. You still need to practice the A&DS problem intensively and learn to quickly identify an approach to each problem. For example, know when do use BFS or DFS in a tree/graph, when to use recursive vs iterative algorithms, when to sort or index data before processing, etc. And ALWAYS know the big O time and space complexity of your algorithms. I started interview preparation in late May, did my first phone interview in late June and finished my last onsite interviews in late-August — three of the most intensive months of my life.
If any of you ask me for specific interview questions that I encountered, unfortunately, I can’t disclose them here. But I have tagged all relevant interview questions on LeetCode, as a way to give back to the online community anonymously. I hope you would as well after your interviews.
Thanks for reading thus far! Hope these tips are useful during your interviews. I will discuss Offer Negotiation and Team Matching in Part 3, which is the final article of this series.
Best of luck with those technical interviews!