Start preparing
Now that you know what to expect in a technical interview, it's time to practice. Our CICS Careers team has evaluated numerous resources and strategies to provide these recommendations so you can focus on preparing.
First things first
Framework for practicing: Read about the algorithm canvas introduced by HiredInTech. You want to train yourself how to connect a set of properties/constraints to a potential approach to solving the problem, instead of hoping that you do enough questions to get lucky and see a problem you've done before.
Pick up a book: You could start by solving questions from the Cracking the Coding Interview book. The initial section gives great advice on different strategies for tackling questions in a real interview. Additionally, it has 10-15 questions per topic and the quality of questions is superior to most other resources. It is the most frequently recommended resource by employers.
CICS Careers resources: Read through the problem-solving approach and suggested list of problems to start with put together by our Career Developers.
Practice Makes Perfect
Practice online: It is good idea to practice on paper or a simple editor. However, it is highly recommended that you later submit the code on an online judge platform. It helps you not only identify missing testcases, but also gives you access to comparative analysis of your performance and code of other people on the platform.
Practice strategically: It is a good strategy to pick few questions from different topics in algorithm and DS rather than thinking of exhaustively solving all questions of 1 topic first. Check out the Leetcode learn section that can help you pick topics to get started.
Track time: Try to track how much time you spend on each question. You should also have a limit on how much time you will spend on a single question. As you keep practicing, you can keep decreasing your limit and effectively increase the number of questions.
Gather advice: Technical interview vary based on the employer and even the interviewer. Spend time exploring tips from companies like Google and Microsoft to figure out what matters most. Talk to you friends and classmates after their interviews to learn from their mistakes and success.
At The Interview
Do
-
Set the stage: State the problem as you understand it and any assumptions you might have taken about it. Use specific examples to try to figure out the general solution. Break problems down into steps and explain along the way.
-
Take hints: If you're stuck, vocalize your thoughts on where exactly you're stuck and maybe ask the interviewer something like "this approach should/shouldn't work right?". Usually, they'll try to step in and guide you the right way. If the interviewers rule out an approach for the presented problem, follow the instructions and try something different. When given hints, make sure you respond well and demonstrate your ability to work with others. Being able to respond to a hint is mostly seen as a positive signal.
-
Think about speed, accuracy and optimality: While optimality is important, you want to make sure you have working code in the given time that completely solves the problem. Always try to build up from a brute force solution that is easy to code. If you end up overcomplicating things by focusing on optimality, try to snap out of it and ensure you have working code to show at the end. Remember: working code wins.This shows your coding skills and also allows the interviewer to give hints if there is time left. The best solutions usually require less than 30 lines of code. Always remember to explain the complexity when you are confident you have a solution (without prompting from the interviewer is better).
Don't
-
Jump to code: When a new problem is presented, make sure you communicate your solution and get a clear go ahead from your interviewer before you hastily attempt to code.
-
Wait to test: You should come up with interesting test cases yourself instead of holding out until the interviewer provides test cases that break your code. Your ability to proactively dry run test cases on your code to identify bugs is a key part of the evaluation.