A good coding interview is more than writing code
Coding interviews exist to gather more signals than just whether you can write code to solve a problem. If they were pure assessment of your ability to write code, these would be take home assignments (probably with a timer).
Coding interviews can also gather whether the candidate can navigate ambiguous questions/requirements – this is more common for senior engineers than for new grads and more common in design interviews than coding interviews but may still happen for your coding interview. I personally try to avoid ambiguous problems for coding interviews as design interviews are better fit for this signal in my opinion but this isn’t the standard in our industry as far as I can tell.
The other (and most important) signal is whether the candidate can explain their thought process and their code. This is especially important as it reflects:
- How structured the candidate’s thoughts are – candidates who have a good grasp of the problem and their solution will write better code, e.g. the code will be broken down in logical units
- Their communication skills – this isn’t just your ability to speak clearly but also how you will present your work. Senior engineers tend to write smaller pull requests because they have a clear multi-steps solution to the problem and will build a narrative around the change (e.g. building the skeleton, implementing part 1, implementing part 2, connecting all the parts together).
My advice if you are training for coding interviews is to play on leetcode/hackerrank/etc. but solve the problems as if you were in an interview – i.e. explain what you are doing to someone (a plastic duck, yourself or your dog).
The best candidates I’ve seen in coding interviews can both write very crisp and well structured code all while making sure that following their thoughts/code is extremely easy.