So, you’ve spent weeks preparing for your technical interview.
You’ve brushed up on the fundamentals, spent weeks learning how to solve programming problems, and can write code with your eyes closed.
It’s time to take all that prep and crush your technical interview.
It should be obvious, but remember, it’s possible to derail your interview before it begins, and it has nothing to do with programming.
Make sure you have dressed appropriately (yes, I know, programming interviews are super casual, but still, making a good impression won’t hurt), show up early, and if you are doing the technical interview online, you’ve tested and understand all the programs you’ll be using.
Don’t make the mistake of assuming you can figure things out during the interview.
Don’t leave anything to chance. When your interview begins, you don’t want to struggle with technology or figure out how to sign on. You want to be entirely focused on doing as good as possible.
The two keys to success in your technical interview are preparation (before you show up) and focus during the interview. You can’t be focused and do your best work if you show up late or are stressed because you can’t get something to work.
After the pleasantries, your interviewer will give you the programming challenge you are supposed to solve and the parameters for solving the problem. No doubt, you’ll be eager to begin solving it right away. Your first instinct will be to jump up to the board (or whatever you are working on) and begin to write the code as fast as possible.
Before writing code, stop, think, and clarify the problem. Make a plan about how you think you’ll solve it, structure your code, and think about how much space you need once you begin working.
- Do you have enough space to write the code?
- Will you need additional space to work?
- Do you need to write smaller than usual?
- Should you ask clarifying questions?
- Do you have all the information you need to solve the problem?
These things seem trivial until you run out of room halfway through or realize after you’ve been working for 20 minutes that you are approaching the test with the wrong assumptions.
Remember that 50% of the complexity relies on understanding the problem, the other 50% is on solving it. So don’t rush through the steps and communicate with the other side all the time what you are thinking.
Check with the interviewer to ensure you are clear about necessary inputs and values, duplicates, how the inputs are stored, or if you need to know anything about a dictionary of terms (if you are given one).
The last thing you want is to realize that you’ve written code to solve the wrong problem or gotten something wrong because you’ve misunderstood critical information from the outset.
Your first impulse will be to start writing the code. However, you’ll save time and come out with a much better result if you stop and prepare before diving in.
As you write your code, explain your work to your interviewer while you are working. Many candidates will just start working, expecting the interviewer to understand what they are doing. Hopefully, they will, but that’s not the point.
Talking them through your thoughts and explaining how you’ll be working on solving the problem is about more than making sure they understand you.
The problems you’ll receive in a technical interview may have multiple paths and solutions. The interviewer will undoubtedly know the answer and may even have their preferred way to solve the problem. Talking through your approach helps them understand how you are processing the problem.
Explaining your approach also demonstrates that you know how comfortable you are talking about programming challenges and how effectively you can communicate.
There are a lot of good programmers, but not all of them can explain how they work.
Talking with your interviewer demonstrates that you have more than the technical skills to do the job. You have communication skills as well. Good companies recognize that a good programmer possesses more than simply technical skills.
While you write, explain your steps and ensure your interviewer understands how and why you are working the way you work.
When you need to name variables, assign them meaningful names.
First, it’s just polite to ensure they understand your code.
But. You don’t want your interviewer puzzling over an abbreviation or unclear about what “input” means.
If the interviewer doesn’t understand something you do, they could misjudge your solution, impacting their assessment of your work.
You don’t want to leave any questions about what something means or why you did something.
Before you finish.
It’s such a relief to finish writing the code that you are tempted to step back and let your interviewer take over when you finally write that last character.
You took a few critical moments to review everything when you first started. Now that you’ve finished, stop and recheck your work.
Review the entire code for syntax errors, and run a few test cases through the code you’ve written to see if you find any simple issues or problems in the code.
Take a moment and review your work, testing it to see if you can find any flaws before turning it over to your interviewer.
Reviewing your work can help you alleviate all kinds of silly mistakes and embarrassing issues. It will also help you clean your code up one final time before it’s formally evaluated.
If you follow these steps, you’ll maximize your chances of finishing strong with your technical interview.
The people who do the best are the ones who have prepared, know their stuff, and work methodically through the problem they’ve been asked to solve.
Working fast and finishing early doesn’t guarantee success.
Doing it right by getting clear before you begin, working slowly and methodically, and reviewing your work puts you in the best place to succeed.
So, go out and crush your technical interview!
Thanks for reading!