Technical Questions

Hello and welcome to the third post in my series, Acing the Interview! If you've already been following along, welcome back! Throughout this series, we'll be discussing topics like behavioral and technical questions, as well as design patterns, algorithms, and data structures. We will also cover areas such as mock interviews, how to discuss your projects, and what to expect during the day of the interview. If you are just joining us, I would highly recommend going back to the first post of this series and reading through it all to be prepared for your interview.

Today, we'll continue on to the next topic of discussion, once again summarizing some examples from Cracking the Coding Interview ¹ with some of my own experiences and insight. If you have the time though, I would highly recommend purchasing the book and reading it through to be prepared for your next interview. We have a lot of information to cover so let's get started with our next topic: Technical Questions.

---

"Trust yourself. You know more than you think you do."     -Dr. Benjamin Spock

Technical questions are the foundation of most interviews from top tech companies and allow the interviewers to validate the level of skill presented through your resume. While you may be intimidated by this part of the interview, remember that there are rational ways to approach these questions. The best way to identify these rational methods are to practice solving problems. I'm not talking about just reading through problems and solutions, but actually spending time to understand the problem and why the solution is the best approach. Simply memorizing the solutions won't help you during the interview. Regardless of the problem you're trying to solve, it's best to attempt to solve the problem in the following order:

1. Try to solve the problem on your own and be considerate of the time and space complexity with Big O notation
2. Use paper to write your code to get used to coding without things like auto-code completion, syntax highlighting, and debugging
3. Test the general, edge, and corner cases with your code on paper. By practicing this before your interview, you'll be able to breeze through this process in the interview
4. Take the paper code and type it as-is into your computer. If you find mistakes in your code that the IDE fixes, make a note of it to avoid during the next problem and during the interview

When it comes to the technical questions, most interviewers likely won't ask you for specific algorithms but there are some basics that you should know. It will be important that you understand when to use the following topics, how to implement them, and any applicable space and time complexity, especially hash tables:

Data Structures	Algorithms	Concepts
Linked Lists	Breadth-First Search	Bit Manipulation
Trees, Tries, & Graphs	Depth-First Search	Memory (Stack vs. Heap)
Stacks & Queues	Binary Search	Recursion
Heaps	Merge Sort	Dynamic Programming
Vectors / ArrayLists	Quick Sort	Big O Time & Space
Hash Tables

It will also be beneficial to become familiar with the Powers of 2 table. While not vital to memorizing it, you should be comfortable with it to answer questions related to scalability and/or memory limitations

Power of 2	Exact Value (X)	Approx. Value	X Bytes into MB, GB, etc.
7	128
8	256
10	1024	1 thousand	1 KB
16	65,536		64 KB
20	1,048,576	1 million	1 MB
30	1,073,741,824	1 billion	1 GB
32	4,294,967,296		4 GB
40	1,099,511,627,776	1 trillion	1 TB

During the interview, it's important to remember that their technical questions are intended to be difficult and it's okay if you don't get any answer immediately. What's critical during the interview process is that you listen to the directions of the interviewer and ask questions. Depending on your performance, the interviewer's personality, what they're looking for, and the difficulty of the question, they may help more than you expect. Using the following approach in your practice questions, and during the interview, can help you greatly in providing the answer the interviewers are looking for.

As an interviewee, it's important to understand that you don't need to answer every questions correctly or fully. It's a common and dangerous rumor that not doing so means you failed the interview and will not receive the job. There are multiple ways your performance during the interview is evaluated and none of them involve whether you got the answer "right". First, the interviewer looks for how optimized your solution is, the amount of time it took to reach that solution, how many questions you asked, and the cleanliness of your code. Good code is readable, efficient, simple, maintainable, and, most importantly, correct. Second, they evaluate your performance in comparison to the other candidates being interviewed. If you get difficult questions and have a few mistakes along the way, that could be better to the interviewer than a candidate that received easy questions and had no mistakes. Lastly, most questions provided by the interviewers are so difficult that even a strong interviewee might not be able to immediately create the optimal solution. It's okay if it takes you some time to complete the question. What is most important to the interviewer is that you don't give up. Always be eager to step up to whatever question the interviewer asks you to hit it head-on and with excitement.

---

If you enjoyed the post, be sure to follow me so that you don't miss the rest of this series, where I dive deeper into preparing for the interview, and what to expect the day of, so that you too can Ace the Interview! The links to my social media accounts can be found on my contact page. Please feel free to share any of your own experiences with the interviewing process, general questions and comments, or even other topics you would like me to write about. If this series of posts help you land that dream job of yours, be sure to let me know as well. Thank you and I look forward to hearing from you!👋

Sources