Mechanics of reasoning during programming interviews
- by user129506
This is not the usual "I don't want to write code during an interview", in this question the assumption is that
I need to write code during an interview (think about the level of rewriting the quicksort or mergesort from scratch)
I know how the algorithm work or I have a basic idea of how I should start working from there, i.e. I don't remember the algorithm by heart
I noticed that even on a whiteboard, I always end up writing bugged code or code that doesn't compile. If there's a typo, whatever I usually live with that.. but when there's a crash due to some uncaught particular case I end up losing confidence in my skills.
I realize that perhaps interviewers might want to look at how I write code and/or how I solve problems rather than proof-compiling my whiteboard code, but I'd like to ask how should I approach the above problem in mental terms, i.e. what mental steps should I follow when writing code for an interview with the two bullet points above.
There must be a unique and agreed series of steps I should follow to avoid getting stuck/caught into particular exception cases (limit cases) that might end up wasting my time and my energies rather than focusing on the overall algorithm for the general case.
I hope I made my point clear
