It’s not the ability to communicate effectively that’s at play here, it’s your ability to read your interviewer’s thoughts. Sure thing, if you work with stakeholders, you need some of that as well, but you typically can iterate with them as needed, whereas you have a single shot in the interview.
Plenty of times, at the end of the interview, I do have a better mental picture of the problem and can come up with a way better solution, but “hey, 1h has already passed so get the fuck out of here. Next!”
I've tried that approach in a couple of interviews and, no surprise, I did not get those jobs because interviewers really seem to hate it if you dare step outside the little cocoon of leet they've constructed.
It doesn't matter why you can't fix the server, you can't fix the server. It doesn't matter why it can only handle one request at a time, it can only handle one request at a time. That information doesn't change the solution to the task. Make up whatever you please - maybe it's a third party system so you can't access the code. Now try to come up with some useful questions that actually help you solve the task instead of wasting time asking pointless questions.
No wonder people reject you if this is how you approach interviews. Maybe it would make sense to ask these kinds of questions in a real work scenario, but it does not make sense in an interview where you are given a made up task. Just accept the constraints and solve the problem. You sound like a high school student being intentionally obtuse, like you came into the interview thinking you're too good to be evaluated that way or maybe you just don't have a clue how to solve the actual problem you're given so you try to stall to avoid having to admit that you can't do it.
That being said, the time spent on these questions should be minimal. It should go something like:
Candidate: It seems like we're solving the wrong problem. Why can't the server handle multiple simultaneous requests from a single client?
Interviewer: Its a 3rd-party server we don't control. (or even just a "because those are the artificial constraints for this puzzle" if the interviewer is feeling particularly lazy)
Candidate: Ah okay. <proceeds to work on the problem>I also think they're unnecessary in the first place. I wouldn't hold it against anyone in a scenario like you described but I also wouldn't expect it. Solving the task as it's posed is good enough.
I might just mention that my first instinct would be to fix the root of the problem instead of asking about it, I wouldn't expect the interviewer to have spent time world building for their made up task.
As it stands, we still don't know why the server was broken in this way and why they created a work around in the client instead of fixing the server.
what is the delay actually doing? does it actually introduce bugs into that backend? how do we check that?