These are tips on how to begin the technical interview before you start to code.
Understand the Problem
It seems obvious - but make sure you understand the problem you are asked to solve for. Ask your interviewer any questions to clarify the problem.
I find it helpful to summarize the problem back to the interviewer to make sure I can explain it in my own words. This helps to confirm that my interpretation of the problem is correct. Nothing's worse than wasting time solving a problem that wasn't even asked!
Ask About Inputs
Ask what assumptions can be made about the inputs or arguments. If the problem says it accepts an array, will that array be sorted or unsorted? If it accepts a string, will it vary in length and characters? Will the user always provide 2 arguments, what if they only give 1?
Ask About Edge Cases
Edge cases are the most extreme inputs that can be used in the problem. If the problem accepts a string as data type, what happens if the user inputs a number, or array? What if the problem accepts an array, but the user provides an empty array? These are questions to ask the interviewer to further clarify the problem, but to also give you more understanding on what you need to return.
What Should Be Returned From Your Solution?
Your solution needs to return something - make sure you fully understand what. Should it return a value, or index of a data set? What data type should be returned, a string or integer? Is the problem asking to return the count of duplicates or does it want the pair values themselves?
Here, you can also think about what to return based on particular inputs. If the input is empty, or null, what should your solution return?
Time to code, but first... Write Pseudocode!
Writing pseudocode is helpful because it allows you to quickly organize your thoughts before spending time writing perfect, working code. If you draft your solution in comments, this gives you time to think about the Big O of your solution incase you want to try a different approach. It also gives you space to see if there's anything that can be quickly refactored.
One thing to note - make sure you tell your interviewer that you are writing pseudocode! While this may seem obvious to you, it may not be to your interviewer and they may think this is what you consider real code to be. Don't leave any room for interpretations and tell the interviewer this is only used to draft your ideas, and that you will live code shortly after.
Stuck on Part of the Problem? Code What You Can!
After you've pseudo-coded and drafted your ideas, start where you can. If you can confidently solve for part of the problem, do it! Maybe you only know how to code the return value - that's ok! You have a limited time to solve for the problem, and it's better to show for something than to get stuck on one small area of the solution and not present anything.
Above Anything Else - Think Out-loud!
The interviewer wants to understand your thought process - so narrate it! Sure, you can code in silence and let your solution speak for itself, but being quiet doesn't allow you to show off your extensive knowledge. You're trying to impress them for the job, after-all.
For example, you know that array indexes start at 0 and that's why you started your loop at i = 0, but make it known and say it out-loud! This also highlights your communication skills to the interviewer.
Don't Forget to Refactor!
While this last part typically comes when you're done with the coding challenge, talk with you interviewer on what could be refactored. If you have the time - code it. If not, quickly explain where your mind is headed next and where you'd look to improve your code.
Lastly - Be Confident and Trust Yourself!
If you've landed a technical interview, you're doing something right. Push out negative thoughts or self-doubt. You've studied, you've practiced, and you're going to do great so long as you keep a positive mind set.
It's ok if you can't fully solve the problem - just show what you can. The interviewer will appreciate how communicative you are by asking questions and narrating your thought process. They'll think you have strong attention to detail if you ask about edge cases. And they'll see you as a problem solver if you're able to use Google to supplement your solution. These are still valuable traits to display even if you get stuck on the solution. Code what you know and you'll do fine!
Top comments (0)