1

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

closed as primarily opinion-based by Ampt, Dan Pichelman, Dynamic, mattnz, Tangurena Jun 25 '14 at 15:15

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 6
    If I suspected a candidate was writing code from memory during an interview, I would ask another question until I found one they haven't memorized. The more perfect the code, the more suspicious I would be. – JeffO Jun 2 '14 at 13:02
  • 2
    I've hired dozens, probably hundreds of developers in my career. Although I usually use some kind of programming challenge in the interview, I would never expect perfect code on a white board. That's just a gotcha play if you ask me. When I expect is that the candidate can think through the problem in a reasonable way, knows common syntactical things, and so on. I think the meta-question you should be asking yourself is: "Do I want to work somewhere where people expect perfect code written on whiteboards during interviews?" – Calphool Jun 2 '14 at 17:51
  • 1
    the best code interview I've ever had presented me with some rather obfuscated code and asked to explain what it did, rather than ask me to write that code. Much more practical, and doesn't expose people to my impossible whiteboard writing skills. – jwenting Jun 11 '14 at 9:53
2

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.

2

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.