It’s important to note that I’m not a mental health expert. This is based on my personal experience. If you’re experiencing any serious mental health issues, please reach out to someone you trust or a mental health expert immediately.
Unfortunately, the technical interviewing process for software developer jobs is deeply flawed. According to a research study conducted by North Carolina State University and Microsoft, white board technical interviews assess test anxiety rather than coding skills and resulted in women and minorities scoring worse.
I’ve personally experienced anxiety during technical interviews that has negatively impacted my performance and led to many rejections. In response to this, I created a set of steps that I use to practice for technical interviews and then use during interviews. Having a routine has immensely helped me perform much better during technical interviews. Let’s begin!
First, breathe. Inhale, exhale. Breathe as many times as you need to. Center yourself. Believe in yourself. You got this!
This step can be repeated as many times as necessary throughout the process.
It’s easy to jump right in and start coding right away. However, understanding the problem fully before coding can save you from wasting time later.
If you’re taking a live interview, ask questions. Ask the interviewer to repeat the problem as needed. You can even restate the problem to the interviewer to make sure you understand the problem before you start coding.
Before you start coding, gather the following pieces of information:
- What’s the program supposed to do?
- What’s the input and data type of the input?
- What’s the output and the data type of the output?
This will help you understand the problem, identify any missing info, and focus on the solution.
During this step, write down some possible solutions while speaking your thoughts out loud. If you’re in a live interview, this will help the interviewer understand your thought process, and they can provide further insight as they see fit.
If there's more than one solution, choose the solution you're most comfortable coding, even if it's not the most efficient solution or a brute-force solution. It’s better to have a solution than none at all. You can always optimize your solution in the end if there’s time.
Run a few test cases. Check if there are any edge cases or bugs. Refactor as needed.
If you have time, look for ways to improve your solution. This is where Big O notation comes into play.
If you’re someone who suffers from test anxiety, know that you can succeed. Having a problem solving routine may help you manage some of that anxiety during technical interviews, as it has for me. I hope my problem solving routine helps you in some way, and feel free to change it to fit your needs.