Practice coding + communication
Questions will cover data structures and algorithms and will be short enough to be explained and solved reasonably quickly, yet challenging enough that not everyone can solve them. Often these problems will include constraints and may require algorithmic tricks. Online assessments (OAs), in-person (whiteboard), or virtual (editor screen share) are all common.
You should have thorough knowledge of the use and syntax of mainstream languages like Java, C++, C, and Python, or languages specifically required for the job. Know standard libraries, read files, parsing inputs, implementations and complexity of common tasks like sorting, and object oriented programming (OOP) best practices.
Think out loud. If you’re silent, interviewers don’t know if you're making headway or if you're just stuck. If you communicate well, they might say, "Looks good! Go ahead and code it," or "That might work but there is a more efficient solution." Communication takes practice – start with yourself, a friend, and even alumni.
prepare Early And Often
Don’t overwork yourself. Dedicate a few hours in the weeks leading up to potential interviews. Instead of hoping that you do enough questions to get lucky and see a problem you've done before, practice a wide variety and focus on weak topics. For basics (CS187), try Leetcode learn or Leetcode Easy and Medium questions. For advanced (CS311, MS), try Leetcode Medium and Hard questions.
Practice on a whiteboard for in-person interviews, and with a code editor for virtual interviews. Time is a factor so you may want to track time as you practice and try to improve your speed. Be familiar with the technical interview process of the company at which you are applying and try to simulate it.
Schedule Mock Interview
When practicing and interviewing, follow this approach which encourages you to “think out loud” and explain your thought process clearly to your interviewer.
Understand: Restate the problem in your own words. Ask questions. Clarify assumptions, information that is not explicitly stated, by asking yes/no questions ("Can we assume..."). If they say no to assumptions, note them as "edge" test cases. Walk through specific examples. Start drawing it out. Break problems down into steps.
Brute Force: Mention the first basic approach, algorithm or solution that you can think of. You want working code that completely solves the problem -- then optimality. If you think there is a faster way, mention there are “multiple ways to solve the problem” ask your interviewer if you should look for a faster solution.
Ideate: Think about how you can improve your brute force (Memoization? Redoing extra work?). Use data structures to your advantage like sets and hash tables with constant time lookup. Come up with test cases to try “breaking” your idea. Listen for hints and react.
Code & Test: Write your code (not pseudocode), and explain as you go along so your interviewer can be involved and follow along. Then test each line, trying to catch mistakes big and small. Own the errors and fix them.
Complexity: When you are confident about your solution, mention the runtime complexity. Interviewers will often ask, so proactively mentioning it can win you points.
When You Get Stuck
Questions are designed to be challenging. If everyone could solve them, then the employer is not going to be able to differentiate proficiency. Don't get frustrated or give up. These interviews evaluate your ability and desire to solve challenging problems. Explore a different approach. If the interviewer rules out an approach, follow the instructions and try something different. Ask for assistance, vocalizing where you're stuck so they can guide you the right way. When given hints, make sure you respond positively and demonstrate your ability to listen and collaborate.
If you start writing a lot of code, take a step back and rethink your approach. You might be heading in the wrong direction. You should ask clarifying questions and make sure you completely understand the problem before you start working on it. Forgetting syntax is normal. Ask if you can look it up. They might say close enough is good enough.
Master the programming language
Knowing how common algorithms are implemented and the complexity/cost of different operations in the implementation can help you impress the interviewer, and make you aware of which methods are “expensive” to use when calculating the time complexity of your solution.
Write "cheat-sheets" of top patterns and non-trivial data structures/library functions that you can quickly review while practicing. Create a generic template for these concepts which you can modify and apply to any new problem.
