After doing some interviews, I've realized that I usually know what I want to do to solve a problem, but I often get my logic complicated (and introduce a lot of bugs) when I'm actually coding.

For example, when I tried to code up insertion into a sorted singly linked list, this is what I knew I had to do:

  1. I had to check for the case where the list is currently null
  2. I had to check if the element I want to insert is less than the current head
  3. To insert between nodes, we had to link one node to the new node, and the new node's next to the one that is supposed to be after.

I had trouble inserting between nodes because I was actually supposed to check the NEXT node's data and not the node which I had my pointer pointing to (so I could set current's next to the new node). I also struggled on this problem (note that this was coded on white board) because I was pressured under time and I think I made it more complicated in my mind that I should have. When I went back to this problem after the interview, it turns out the solution isn't complicated at all (as it shouldn't be). However, I just tend to complicate things and confuse myself.

Would anyone have any suggestions on how I could improve this vulnerability of mine?


Talk to the interviewers. Explain what you're trying to do. Ask questions. Say "does this look right?"

Interview questions about coding are only a rough estimate of ability. Most people doing interviews have been there before, and understand that coding on a whiteboard is more difficult than coding at a computer. If you share your thought process, and solicit frequent feedback from the interviewers, you redirect focus to your collaborative ability, rather than the mistakes that we all make when we're nervous.

Given the choice between somebody who stands up and does the problem without looking at me, or somebody who is a little unsure of themselves but engages me during problem solving, I'll almost always favor the latter.

  • Ah, I was actually thinking about asking asking my interviewer whether this looked right or not, but was worried because I feel like if I asked that, they would think I'm not as competent as they wanted. – user1831442 Feb 6 '14 at 0:21
  • It depends on the interviewer (a friend of mine missed a minus sign and got raked over the coals for the rest of the interview), but it can also be a way to take the temperature of the people you're interviewing with. In my friend's case, he determined pretty quickly that he didn't want to be working on a team that harped on a simple mistake during whiteboard coding. – BJ Myers Feb 6 '14 at 0:23
  • 1
    Agreed. When I am interviewing developers I am more interested in how they collaborate with me to solve problems than whether they can remember certain syntax - that's what IDEs and Google are for. – Azrael Seraphin Feb 6 '14 at 1:31
  • Also, if you silently scrawl on the board and make a mistake, there's no way for the interviewer to know if it was a simple transcription error in something you understand well, or whether you're just straight up clueless. By talking about what you're doing, you make it clear that you know what you're doing, even if you miss a minus sign here or check the wrong node there. – Carson63000 Feb 6 '14 at 5:20

Write more code, and continue to refine and improve it, with the help of outside sources of information like books and blogs. That's the only way I know of how to do it.

Put your emphasis on writing more code, not reading more blogs.

If you're good a reading code, read the code of others, to see how they solve problems. There are plenty of open-source projects that you can look at. Compare their process to the process you use to write code, and get better at doing it.

But I can't stress enough that the best way to write better code is to simply write more of it, and work on ways to make it better code.

For what it's worth, I'm not sure that interviewers are the best source of feedback on whether or not you're writing good code. You can get critiques from other peers, or post your working code at http://codereview.stackexchange.com (I've seen very good advice there).

  • +1 for practice. Programming is as much turning ideas into code as anything else. – Telastyn Feb 6 '14 at 2:45

You need to study algorithms. Lots of people know how to stamp out some code. The interviewers are looking for a person who has an understanding about what is being written, and to do that, you need to have a deep appreciation for what the code is doing.

I recommend that you take a course in algorithms. Best of all, there's one free that has just started on Coursera, and it's taught by Robert Sedgewick, the co-author of one of the best books on algorithms ever written. The course just started this week. You can still sign up, I believe.

  • This seems like a poor answer... I mean the questioner is basically saying that they understand the algorithm, but can't just stamp out code. – Telastyn Feb 6 '14 at 2:43
  • If he can't stamp out the code, it's likely that he doesn't understand the algorithm. In any event, the algorithms course that I recommend involves writing LOTS of code. Finally, the course begins with quotes from Linus and other saying that what companies are looking for is not coders, but people who understand algorithms. – vy32 Feb 6 '14 at 23:01

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