I'm sorry, this is terrible advice. Trust me, the interviewer is never gonna pile up requirements on you. In fact, they are trained to ensure that what they as

I'm sorry, this is terrible advice. Trust me, the interviewer is never gonna pile up requirements on you. In fact, they are trained to ensure that what they ask can be completed in the time allotted (with time to spare for candidate's questions). More often than not, when you ask clarifying questions, you will end up with a much different problem (and sometimes simpler) than what you expected. > Asking too many questions sounds like you're trying to delay coding something up. No it doesn't. > If you can code a prototype as fast as asking question, why not. Code it up and then ask, "how about this: what requirements are missing from this that require changes or a rewrite?" This is terrible, you are now making the interviewer do your work. You need to tell the interviewer what the boundary conditions of your solution are. That gives valuable data about your understanding of the solution space.