I’ve been conducting a lot of interviews recently as part of hiring for one of my teams, and I’ve noticed some frustrations on both sides.
On the internal side, I created an interview packet in response at the company to help smooth some of the candidate experience and performance and I imagine it’d be good to re-iterate some of my corresponding thouhts from the candidate perspective.
Technical interviews can be a daunting aspect of the job search for software engineers. From leetcode-style puzzles to take-home tests and system design challenges, each stage tests different skills and aspects of your software engineering acumen. This blog post aims to provide candidates with practical advice for each stage of the technical interview process, helping you present your best self to potential employers.
Leetcode Style Rounds
Success in leetcode-style interview rounds largely hinges on your familiarity with data structures and algorithms. There’s no real shortcut here – practice is key. Consistently working through problems will not only improve your coding skills but also enhance your ability to think algorithmically, a crucial skill in these interviews. Focus on understanding the underlying principles rather than just memorizing solutions.
Key Points to Consider
Practice: Use leetcode.com and neetcode.io to aid you in your practice.
Prepare: Familiarize with the UI of the platform that the company sends you beforehand. Sometimes you’re able to go to the link provided beforehand and change settings to make the UI fit your working style.
Language Familiarity: Where possible, pick a language you are most familiar with. Even if you are allowed to access documentation, it is faster to already be familiar with the language constructs that you’ll be working with during the interview.
Take-Home Tests
More Than Just Code
Take-home tests are often perceived as time-consuming and, by some, as a waste of effort. However, on the flip-side, in companies serious about take home tests, evaluators will also typically spend more time reviewing submissions than in leetcode-style interview rounds.
These tests offer a broader canvas to demonstrate your capabilities as a software engineer. They assess not just your coding skills but also your ability to construct software end-to-end, understand requirements, and think about architecture, performance, and maintainability.
Key Points to Consider
Quality Over Quantity: If the test has optional sections, tackle them only if time permits and you can maintain the quality of your submission. It’s better to submit a polished, smaller project than a larger, unfinished one.
Detailed README: This is where you stand out. A comprehensive README should explain your thought process, the architecture of your solution, and any future enhancements you would have made with more time. This helps the interviewers understand your approach and can significantly reduce the time spent on testing.
Expect Your Code to Run: Interviewers will likely run your code, so include clear instructions and consider their experience when they execute your program. Try to use Docker if possible to provide simple instructions to the interviewers that are reproducible across platforms.
Use Git: You might be sending your code as a zip/tar file, but creating a git repo and showcasing iterative work on the task is almost always an unmentioned bonus.
Technical Rounds
Preparing for Follow-Up Questions
If your technical round follows a take-home test, be prepared to discuss your submission. Revisit your project before the interview, considering potential questions about future improvements or alternative approaches.
Project Discussions
You might be asked about a past project you’ve worked on, and the impact you’ve made. Choose a project to discuss in depth and consider it from an interviewer’s perspective. Anticipate questions about challenges faced, decisions made, and possible improvements.
System Design
Contextualizing Your Solution
System design questions require a different approach. If they’re based on your take-home test, think about how your solution fits into a larger architecture and its real-world applications. For roles focused on the company’s core business, tailor your system design answers to reflect the company’s products and challenges.
Broadening Your Knowledge
For more generic system design questions, resources like neetcode.io on system design can be invaluable. They are a solid complement to your existing experienece in understanding how to build scalable, reliable, and efficient systems.
Key Points to Consider
Scalability, Efficiency, and Reliability: Understand scalability, efficiency, and reliability of any solutions you present. Sometimes, your solution might head in a direction that is not ideal and you realize this too late in the interview. At that point, discuss the tradeoffs with the interviewer, present any possible problems you notice with the solution, and possible improvements even if you don’t entirely have the time to build them up.
Tradeoffs: System design is often about tradeoffs, and interviewers will want to see how you navigate these and how you think. There is often no single correct solution.
Commmunicate: The interviewer is there to help you guide through the interview. Listen to any hints they provide, and communicate with them. Approach it as if you’re solving the problem together rather than you providing them a solution.
Be positive
Despite everything, there’ll be times where you perform poorly, irrespective of the round. There’ll be times when you thought you did great but didn’t. There’ll be times when you thought your did poorly, but did great. Try not to think too much about it and have fun. Positive attitude will surely help.
In any case, reflect and learn from your mistakes.
Conclusion
Technical interviews can be challenging, but with the right preparation and mindset, they also present an opportunity to showcase the breadth and depth of your skills as a software engineer. Remember, every stage of the interview is an opportunity to demonstrate not just your technical abilities, but also your problem-solving approach, your understanding of software engineering principles, and your ability to communicate and document your work effectively.
Good luck!