4 ms·

> The problem is that customers, PMs, and managers often don't communicate clearly either. Exactly. One of my favorite interview challenges is to write an inpu

> The problem is that customers, PMs, and managers often don't communicate clearly either. Exactly. One of my favorite interview challenges is to write an input validation that checks for a valid SSN. The actual code should be pretty trivial for a competent programmer; but the real test is if they ask for what "valid SSN" means (123-45-6789, 123456789, 123 45 6789, all of the above?) If they jump right to the code based on an assumption, without even thinking or asking about it, that signals that they're likely to make such assumptions in the field.

RandoHolmes 6y ago
This is a perfect example of what I was talking about in other parts of this thread. Developers have this really bad habit of coming to conclusions that don't actually follow from the premise. The fact that they made the assumption that an SSN would be input exactly the way it's always input everywhere is not indicative that they would make dangerous assumptions elsewhere. If someone were to bring that up to me I'd probably laugh at them and tell them to write an extra function to normalize the input first and pass that off to the validation function because they're separate concerns. Because that's exactly what I would do, assume it's in the typical format. And if it came to light that the SSN had to be normalized, I'd normalize it at the edge of the system rather than making my validation function more complicated by giving it concerns that are unrelated to validation. Which means you wouldn't hire me, despite my 24+ years of experience building software.