> Last time I went in to one of these as an experienced engineer I probably said all sorts of things they didn't want to hear like there's no point building a s

> Last time I went in to one of these as an experienced engineer I probably said all sorts of things they didn't want to hear like there's no point building a scalable system until you're sure your product has traction. So.. you argued with the interviewer about their question being 'invalid'. That's not going to be a winning strategy. If you have to insist on making comments like these, a better way to express it would be: "Well, I know the context here is that we're designing a new, small-scale system. In cases like these, I think it's normally most helpful to get an MVP out-the-door, and not worry about scalability. However, in a situation where we _were_ concerned about scalability, I'd start by..." > That and I kept trying to extract imaginary requirements. This is more on the interviewer. If you ask for requirements, they should provide them. If they've done it a while, they might have a generic set, but they should at least be willing to make them up on the spot. In lieu of that, there's no rule that says you can't make them up on your own. E.g.: You: "How many concurrent clients do we need to support?" Them: "I dunno, just make it scalable." You: "Ok, let's assume it's 10k and we want to make sure we can scale that horizontally in a roughly linear fashion up to 100k.."