While this is important to avoid bugs in your algorithm, I've had candidates who spent way too long on this and it comes across as inexperienced. I don't really care that you know how to check null-ness, if you just mention "assume the parameter is not null", it's more than sufficient to me.
In reality it might be risky to do this, but I’d like to see that change.
So in terms of writing flow, it usually goes something like core work function/code, often as helper functions -> control flow structure -> guarding, edge cases, etc.
This also works well for a conversation: how do we model/solve the core problem? how do we want this to actually execute? what are our constraints, special cases, etc? You're moving from the general (abstract problem) to the specific (guarding bugs in my code).
This has worked out reasonably for me.
Does it? Why?
I had a question about something with a distance formula, and the choice to either explicitly check the length of the points coming in, which were a list of coordinates, (either to ensure a particular dimension or a matching dimension) or another option to iterate over the components, which has a sane "dimension extension" behavior.
It wasn't until I looked up the available floating point math functions that I knew their limits and could decide on how to implement the dimensionality handling.
So in that case, my thought process went:
Figure out the math -> Figure out how to apply it, eg map to a list of pairs of points (which also constrains math implementation) -> implement guarding on input to match contract
First, depending on the situation I can find myself practicing "Paranoid Programming". It's an approach I picked up in my C days when I had to deal with network protocol code. Essentially: switch-case with every conceivable error condition handled and then the happy path as the final, unlikely edge case (Also: "default" case always triggered an error.)
On the other hand it's a really depressing way to write code. When 80% or more of your dispatcher logic is dedicated to error handling, following the actual logic can be really cumbersome. On the positive side, once you are in the proper code, you have far less edge cases to worry about.
I am the same way. But some ppl seem to care about that stuff. Perhaps, asking in advance may help. not sure.
Unless one is already intimately familiar with interviewing, it's hard to distinguish the do and don't.