This post is a continuation of “Applying for Microsoft as a developer“. Tips and tricks for answer coding questions definitely needed another post.
You will find so many different answers and opinions online. Look them up! I will most likely not be your only kind of interviewer, go check out what people are expecting out there. I can give you an idea of what I was expecting.
Most questions are answered on a whiteboard. If there is one thing you should remember after an interviewer asks a question: DO NOT START CODING.
1. Verify the question
My question might be ambiguous on purpose. Or maybe you just didn’t understand it. If you start coding without knowing important details, your design will be flawed. Verify the question and make sure you have everything you need.
2. Think about it
Seriously? Did I have to write this as a step? YES. People start coding immediately even without thinking. Just pause for 2 minutes and think out loud. Once you’ve thought about it, you should have this information:
- Inputs
- Output
3. Write test cases
You will be able to uncover blurriness in my question. Write a table with a series of inputs/output. The normal cases, the weird cases, the impossible cases, etc.
Too many people do this last. Do it before coding!
4. Start coding
At this point, you should have a fair idea of how your code should look…
I DO NOT CARE if you write 10 lines of argument assertions and lose a few precious minutes. In real life, sure people care that argument 0 is not null, argument 1 is non-negative, and so on. However, in an interview question, that’s not what we are evaluating. Tell your interviewer: “Here I would have my pre-requisite checks, such as …, do you want me to write them down?” Most interviewers will answer NO.
Write your code with SMALL VARIABLE NAMES. Of course, ask your interviewer if it’s OK, but if you start with a variable name called “numberOfElevators”, you will hate yourself later. Just call it “noe“. If you tend to forget, make a table with what your variable mappings are.
As you are coding, explain what you are doing. Talk out loud. It’s complicated, but your interviewer might want to know what is going on in your head.
I don’t care about syntax errors. A missing semi-colon, double quotes, etc. I might call you out at the end, but I don’t really care. However, the important thing is to not confuse the following:
- <= instead of <
- == instead of =
- && instead of &
- && instead of ||
- Missing the first/last item in a for loop
- Going out of bound of an array
- Not returning anything??
Just to be clear, it’s alright if your code doesn’t “compile,” but don’t leave areas empty by saying, “here I would loop around the array and do X Y Z.” Just code it.
5. Verify
With your test cases written at the beginning, go line by line with each input to see if the function is returning the corresponding output. Adapt your code. If you change a core line, “re-run” your test cases even if they were passing earlier.
6. Improve the speed
Your code might be a little slow somewhere; try to analyze what could be done faster. Sometimes you don’t need to code it – just mention it. You can DEFINITELY skip the ++i or i++ idea.
Conclusion
Each interviewer is different. Go check out what people are looking for and adapt to your interviewer. Good interviewers will try to adapt to you as well.
Web Architect Consultant - Passionate about web projects! Expert in barcodes, automation, and JavaScript