Interviews can be daunting and technical interviews are no exception. With back-to-back rounds and complex problems and several pairs of eyes on you during the whiteboard sessions, it can be a nerve-wrecking experience.
With that said, it's often not the most hardworking ones who nail the interviews but the "smartworking" ones. We all have limited time and optimising the time to prepare is key in acing these interviews.
The following post aims to provide some actionable tips for those preparing for their next technical interview.
Preparation is key. But the difference lies in how you prepare.
The main advice is this: Target a few problems from every major concept (Arrays, Linked Lists, Depth First Search, Sorting etc.).
Once again, the trick is to prepare a few good ones and not many easy ones. Go hard and it will train you to think better.
The following is a good resource to start off with: Tech Interview Handbook. The handbook lists recommended questions for practice at the end of each section.
GeeksforGeeks is another great community-driven platform to learn and understand both questions and problem-solving techniques.
Please do not memorise. When I interview candidates, memorising solutions is such a put-off because interviews are never about the correct answer. It is always about how you arrive at the correct answer.
Candidates need to emphasise and vocalise their thought process on:
- Clarifying the requirements of the given problem
- Deconstructing the problem
- Thinking about the various possible approaches starting usually with a brute force approach
- Optimising the time and space complexities
Without doing the above, candidates should not jump into a problem, solve it with a memorised approach and expect to land a job.
When preparing for technical interviews, the right tools makes a difference. For me, Python is my tool. It's my strength as I know which methods and data structures are available in Python and I know the time complexities of the method calls too.
It is not necessary to use Python, but it is best to use a language that you are most comfortable with. Be it C, C++, Java, Scala, Go, Swift or anything else, make sure to be familiar with the method calls and the relevant libraries and techniques you can use. Be a master of your weapon (or tool).
This is crucial because in a technical interview, it is rare that you can run your code in an IDE to debug it. You will be expected to analyse your own code for errors.
Speaking of which, when practicising, use a code editor and not a code IDE. Use editors like Textmate and Notepad++ for Windows. This trains you not to use auto-complete and method helpers which is exactly what you need to do in an interview setting.
Technical interviews don't always mean data structures and algorithms. Software engineering interviews often include system design interviews. And it makes sense, because you are, after all, going to build new products and systems.
To ace this round of the interview, some key concepts and knowledge is required on the following:
- What is the frontend?
- What is the backend?
- How does the frontend and backend communicate?
- What APIs are required?
- What database is to be used?
- How is the database structured?
- How can we apply SOLID principles when designing the system?
- How can the system scale with increasing number of users?
- How to overcome points of failures in the system?
These can be the guiding questions when it comes to design a system. Of course, the design needs to be optimised and relevant to the given system you are designing.
System design techniques often are picked up through on-the-job experience, but the following resources are a great way to start:
Impress with your confidence.
You can be the smartest person who can solve the problems. But if you are missing that confidence, be it in your body language or your conversations, you cannot communicate effectively.
Communicate your thoughts confidently. If you are unsure of your next steps, always trace the problem from the roots. Vocalise your thought process and speak aloud. This allows the interviewers to jump in and help you if you are on the wrong path or if you have misunderstood the question.
It's totally normal to be stuck. Being quiet and non-expressive about your thought process only harms you as the interviewer will not know how or where to help you.