If I were asked to write code for a problem that I thought was particularly finicky or had edge-case complications, I would definitely write notes on the board first. For a simple example, let’s say I was asked to write the method Arrays.toString(int[] array) in Java. I would write, on the board, something like:

• If the input is null, return "null"
• If the input is an empty array, return "[]"
• Otherwise, I must:
  • Output a "[" for the first element
  • Output a "]" for the last element
  • Output a ", " between elements
  • If there is exactly one element, don’t print a ", ".

Then, I would tell the interviewer that normally I would write test cases first to test each of these bullets, and ask them if they want me to do that here. Assuming they say no, as I write the code, I would keep each of these bullets in mind, and check them off as I am fairly certain they work.

Doing this planning step is something you could and should definitely practice yourself with some of the easier problems on Project Euler or from the Elements of Programming Interviews book.

I noticed that even on a whiteboard, I always end up writing bugged code or code that doesn’t compile.

I’ve seen this happen in interviews and it often is followed by a statement of denial. The candidate will struggle to write effective code, and then make statements like “I write better code than this”. The problem here is that the candidate just demonstrated that he/she does not.

While you can counter argue that the problem is context. That solving problems in an interview is not the same as in the quiet private space of your own desk. It is the interview context that matters to successfully get the job for that quiet desk.

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

There is no solution to a problem if it does not compile, and interviewers can see how you write code once you’ve put it on the whiteboard.

Your argument is this: My problem solving abilities with this programming language are not relative to my understanding of the languages syntax and compiling rules.

If you want to demonstrate only your problem solving abilities, then ask to solve the problem in a different programming language. One that you will not make mistakes in.

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

Practice:

Google popular programming challenges for interviews, and then practice solving them. If the whiteboard presents a challenge then buy a whiteboard and practice on one.

Practice writing source code on paper with a pen. Review your work for compile accuracy and then work on improving it.

Study the rules for the compiler you are using.

There is no easy answer other than to work on improving oneself in the areas they are weakest.

Good luck on your interviews.