If you're talking pseudo-code, I'd agree. And I think all these various sketches you're talking about are comparable to psuedo-code. Those sketches aren't goi

If you're talking pseudo-code, I'd agree. And I think all these various sketches you're talking about are comparable to psuedo-code. Those sketches aren't going to tell you exactly what PSI some escape valve needs to blow at, or what temperature a reaction is going to run at, etc. If you're expecting me to write out code that can be ocr'ed and compiled, which is basically what most whiteboard tests expect, I'd disagree. I failed one whiteboard test (C#) because: (a) I didn't know the formatting for Console.WriteLine off the top of my head, because who the hell uses that when writing an app anyway? (b) Because I didn't check the List<int> parameter too see if it was null, even though I did handle an empty list correctly. With the whole interview thing going on, I didn't even argue point (b), there was too much going on. On the way home I was thinking about it, and as a design decision I actually would've just let the function throw a NullPointerException. No specification was provided to the contrary. Should I have wrapped it in a FooAppException, java-style? Or just silently done nothing even though the inputs were invalid?