An important aspect of interviewing is being ready for whiteboarding exercise. Here is a few tips to remember:
Before the interview
The first advice is to ask questions about the interview before the interview. You want to know, if possible, what language you will be coding in and the code editor you will be using. If the interviewer tells you the code editor that will be used, then take time getting comfortable with it. If you are using one of your choice, it's even more important to be familiar with it.
A big issue is sometimes you forget the basics. Practice using arrays, loops, and simple algorithms. My suggestion is to use problem-solving sites like LeetCode and HackerRank to keep your skill level up. Make it a goal, 1-2 times a week, to solve easy to medium problems. I'm not saying spend all your time grinding problems, but I'm advocating to stay prepared and ready to shine.
A few coding sites to consider is:
Repeat the question
Always repeat back the instructions. Even better, write a super simple version in comments at the top of your code. That way you can reference them quickly, the interviewer will know if you got something miss-understood, and it shows that you listened.
Take the opportunity to ask clarifying questions. Think of edge cases or common issues in development that may trip you up. An example is if negative numbers or strings should be accounted for in your solution.
Body language is important
Remember to smile, relax, and try to have fun. 90% of the time, the interviewer just wants to see how you think and conversate. Let them know how awesome you are when you are solving or bombing a problem. Coding isn't about writing perfect code, it's about the journey with others to a working solution.
Life is hard. Do your best to prepare yourself to be the best version of you before the interview. Whatever it takes to get you in the happy mindset, that confident demeanor, that rock star attitude; Do It. If that is candy, ice-cream, a quick walk, watching a comedy show, or listening to a YouTube motivation channel. Do It.
Start with Pseudo-code
Using pseudo-code helps you keep things simple and to stay on track. This should be paired with great comments in your code. It helps interviewers who lean toward reading your intentions instead of listening (we all learn different).
I have been in an interview where they gave me a problem to work on a laptop and then later discussed that problem. I wasn't given the opportunity to talk during the whiteboarding to show my intent. Good comments in your code can take the place of an active conversation.
Another thing is I stutter when I talk. Great comments helped in those situations where my conversation skills wasn't the best. Commenting can show that you can code and communicate your thoughts.
If you need a refresher on Pseudo-Code
Don't forget to Talk
Talking out loud through the white boarding event can't be under-emphasized. I would say that this is the #1 important thing to do. Let the interviewer know where your thoughts are going, why you choose to do code this way, and possible alternatives to your solution.
Being able to talk through your solution line by line and to discuss how/why you use certain data structures/methods will show how well you know the material and can work with others.
The ultimate goal of whiteboarding isn't to finish the problem but to communicate your problem-solving skills. The why, what, when, where, and how.
I feel compelled to repeat: You must talk OUT LOUD, not in your head.
Remember industry standards while coding
There is hacking (hope and pray it works) and then there is coding (code with purpose and pray that it works). If possible, you want to be seen as a professional coder. Either as you code or after you have a working solution, include things like:
- Good Variable naming (worth your weight in Gold)
- Well formatted code
- Comments
- Correct variable types (ex. JavaScript Let and Const instead of Var)
- etc.
Keep your solution simple
Try not to add unnecessary or complicated code that could trip you up. You want to focus on making it work and then later, making it pretty.
Another example is someone spending lots of time importing modules or attempting to use methods that they don't know how to use. While these things are nice, if you get it wrong the "egg is on your face".
Google is your Friend
YOU SHOULD BE ABLE TO GOOGLE. Simply ask, "Can I use Google to find this syntax or fix this small bug". Searching for things is part of being a developer and should be something you can do in the interview. There is a difference between being stuck on an issue and searching for the solution.
You want to show off your Google-fu!!!
Top comments (0)