4 ms·

> Defensive coding. Check for nulls, empty collections, etc. While this is important to avoid bugs in your algorithm, I've had candidates who spent way too lon

> Defensive coding. Check for nulls, empty collections, etc. 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.

munchor 9y ago
Which is why the best thing is to ask. I always tell my candidates that the most important thing is how they approach the problem and not how careful they are with their coding. However, if the interviewer doesn't explain that, the best thing is not to do "Defensive Coding" as per the linked article, but instead to _ask_.
- eradicatethots 9y ago
  I think it’s be better if interviewers and interviewees wrote code like they would in the job - no excessive commenting/checking ... just write effective, clean concise code and minimize time wasted In reality it might be risky to do this, but I’d like to see that change.
abhishekpathak 9y ago
Defensive coding always breaks my flow during problem-solving. However, thinking of edge cases reflects a programmer's maturity. I usually trade off by writing a short comment (# check for null) during the flow and then revisiting that part later.
- bostik 9y ago
  I'm somewhat of two minds here, to be honest. 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.
yangshun 9y ago
Thank you for the feedback, I have tweaked the wording accordingly (:
- user5994461 9y ago
  Just my 2 cents: It would be nice to start all the don't sentences with "Don't ..." Unless one is already intimately familiar with interviewing, it's hard to distinguish the do and don't.
SomeStupidPoint 9y ago
I generally don't know where in the code to "defend" until I've actually written the algorithm -- I don't start writing during whiteboard coding or coding sessions with a solution in mind, I start with the first (okayish) thing to come to mind and iterate from there as I run into problems or edge cases. (Example: do I need to guard empty lists or not? Well, it depends on if I for-all over the list or try to index explicitly.) 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.
- tome 9y ago
  > Example: do I need to guard empty lists or not? Well, it depends on if I for-all over the list or try to index explicitly Does it? Why?
  - SomeStupidPoint 9y ago
    An actual example of this concept coming up: 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
dominotw 9y ago
>if you just mention "assume the parameter is not null", it's more than sufficient to me. I am the same way. But some ppl seem to care about that stuff. Perhaps, asking in advance may help. not sure.
- cakes 9y ago
  I usually am explicit in saying something along the lines of "Can it be assumed that I know how to do argument null checking, if possible, and not pollute the whiteboard?" and I've gotten a "Yes" and then after writing the function on the whiteboard: "Well what about <something relating to argument nullability>?"...so you should ask but YMMV

munchor 9y ago

Which is why the best thing is to ask. I always tell my candidates that the most important thing is how they approach the problem and not how careful they are with their coding. However, if the interviewer doesn't explain that, the best thing is not to do "Defensive Coding" as per the linked article, but instead to _ask_.

eradicatethots 9y ago
I think it’s be better if interviewers and interviewees wrote code like they would in the job - no excessive commenting/checking ... just write effective, clean concise code and minimize time wasted In reality it might be risky to do this, but I’d like to see that change.

abhishekpathak 9y ago

Defensive coding always breaks my flow during problem-solving. However, thinking of edge cases reflects a programmer's maturity. I usually trade off by writing a short comment (# check for null) during the flow and then revisiting that part later.

bostik 9y ago
I'm somewhat of two minds here, to be honest. 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.

yangshun 9y ago

Thank you for the feedback, I have tweaked the wording accordingly (:

user5994461 9y ago
Just my 2 cents: It would be nice to start all the don't sentences with "Don't ..." Unless one is already intimately familiar with interviewing, it's hard to distinguish the do and don't.

SomeStupidPoint 9y ago

I generally don't know where in the code to "defend" until I've actually written the algorithm -- I don't start writing during whiteboard coding or coding sessions with a solution in mind, I start with the first (okayish) thing to come to mind and iterate from there as I run into problems or edge cases. (Example: do I need to guard empty lists or not? Well, it depends on if I for-all over the list or try to index explicitly.) 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.

tome 9y ago
> Example: do I need to guard empty lists or not? Well, it depends on if I for-all over the list or try to index explicitly Does it? Why?
- SomeStupidPoint 9y ago
  An actual example of this concept coming up: 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

dominotw 9y ago

>if you just mention "assume the parameter is not null", it's more than sufficient to me. I am the same way. But some ppl seem to care about that stuff. Perhaps, asking in advance may help. not sure.

cakes 9y ago
I usually am explicit in saying something along the lines of "Can it be assumed that I know how to do argument null checking, if possible, and not pollute the whiteboard?" and I've gotten a "Yes" and then after writing the function on the whiteboard: "Well what about <something relating to argument nullability>?"...so you should ask but YMMV