I think it's funny how they say you don't need experience to pass one of the interviews. 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. That and I kept trying to extract imaginary requirements. I still have no idea what they wanted to hear so I just name-dropped architecture paradigms. Didn't get the job.
> 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.."
I don't know why you assume I was rude about it. I phrased it all equivalently to how you said. A lot of my background was in tech services so I'm very well practiced in asking these kind of questions. They pretty much waved off all of them saying it wasn't relevant.
> They pretty much waved off all of them saying it wasn't relevant.
Well, if they are asking how to build a highly scaleable system, then statements about how to build a not highly scaleable system would not be relevant.
Context is still relevant though. "Highly Scalable" means something different if you're working on core AWS infra vs an app to be used by 100k people at the same time for instance.
I'd expect the interviewer to engage and set some helpful boundaries (and the interviewee if they have the experience to talk about what changes between the two situations)
Well, the sad truth is that a lot of _interviewers_ actually suck at interviewing, so sometimes an interview devolves into a bewildering game of what this particular person wants to hear today based on their mood, especially with the open-ended questions. It is not always possible to suffer through this process politely and constructively.
If the candidate is exposing flaws in your assessment and making you think that should be a positive signal, not a negative one. Unfortunately people have egos and generally don't take kindly to situations like that.
