An approach is to proactively bring up interesting aspects of the problem yourself -- eg, the last time I was writing example code on the board, I spent most of

An approach is to proactively bring up interesting aspects of the problem yourself -- eg, the last time I was writing example code on the board, I spent most of the time talking about where hooks to add more features would go or algorithmic complexity/edge cases I encounter as I try to implement a solution. If you're focusing on the trivia, you're probably too focused on the code and not on solving the problem -- my experience tends to be that there's at least one or two interesting edge cases you encounter if you try the naive approach, and those are generally what the interviewer wants to discuss. The reason is that discovering edge cases in requirements and solving them is what a lot of the job is, and so how you approach that matters (and to an extent, more than if your code on the board is "correct"). Another approach is to extend the problem by asking clarifying questions -- if there's something unspecified that might influence your design, ask about it and tell the interviewer why it matters. Again, this generally is more what they care about than the details of the coding. Finally, if those skills make you an asset -- why not apply them to the question? Even tangentially by talking about how you would (if you had more time/were doing a real assignment). Coding on the white board is more about the journey than the coding, assuming you can write vaguely correct code. (Though writing on a whiteboard is definitely a skill you have to practice.)