What do you do if you make common mistakes during a software engineering interview?

1 Not understanding the problem

Before you start coding, you need to make sure you understand the problem statement and the expected output. If you are not clear about the requirements, ask clarifying questions to the interviewer. Don't assume anything or jump to conclusions. If you realize you misunderstood the problem halfway through, don't panic. Explain your mistake, apologize, and ask for permission to start over or modify your solution.

2 Writing buggy or inefficient code

It's normal to make some typos or syntax errors while coding, but you should try to avoid them as much as possible. Use an online editor or IDE that can help you catch and fix errors quickly. Test your code with different inputs and edge cases, and debug any issues that arise. If you find a bug or a performance issue, don't ignore it or hope the interviewer won't notice. Acknowledge it, explain the cause, and show how you would fix it or improve it.

4 Running out of time

Time management is crucial in software engineering interviews, as you usually have a limited amount of time to solve one or more problems. To avoid running out of time, you should practice solving problems under time pressure beforehand, and follow a structured approach during the interview. Start with a high-level overview of your solution, then write pseudocode or comments, and then code the solution. Don't spend too much time on one part or get stuck on a detail. If you are running out of time, prioritize the most important or relevant parts of your solution, and explain what you would do next if you had more time.

5 Not communicating well

Communication is as important as coding in software engineering interviews, as it shows your thought process, your understanding of the problem, and your ability to work with others. To communicate well, you should speak clearly and confidently, use technical terms correctly, and avoid jargon or slang. You should also engage with the interviewer, ask questions, explain your assumptions, and share your ideas and trade-offs. Don't be silent or monotonous, but also don't ramble or interrupt. Try to find a balance between being concise and being thorough.

6 Here’s what else to consider

This is a space to share examples, stories, or insights that don’t fit into any of the previous sections. What else would you like to add?