> To make matters worse, it would appear that the interviewer is approaching the problem in a dubious manner -- solving a server problem by depending on the clients to cooperate. That should make you suspicious.
I am kind of shocked you have never had to do this, or that you think it is unreasonable to ask. Sure, it is totally reasonable to ask questions about whether this is standard practice, especially in the real world. But an interview is an environment where you are given the constraints and obviously there isn't time to explain every detail about why something is the way it is.
Yeah, we do want the server to be fixed–there is a team working on it, and they'll have it ready next week. But we need something to work now. That's the where the interview places you. If you are going to be the person who values purity instead of just doing the job when the constraints actually call for it, are you really selling yourself as a good candidate?
Turn the argument on its head: why is it reasonable to ask someone who presumably knows better to waste time trying to solve a server problem on the client side? And why would it be unreasonable for a candidate to reject the premise and suggest a better solution?
(I often pose problems to candidates where challenging the given premise IS the point. You want people who will speak up)
I've spent perhaps a couple of decades designing and implementing various forms of distributed systems, and there are good reasons to avoid trying to hack your way out of trouble by requiring clients to behave a certain way. You will always have less control, it is almost never any easier than fixing the server side, and it doesn't actually address the root problem. You start at the end where the problem is instead of introducing hacks that run the risk of becoming long-lived.
You can always put something in front of a misbehaving backend that can compensate for the problem on the server side. In fact, this common enough that there exists a rich fauna of components that are used to address these kinds of issues. From more generic load balancers to more advanced application specific middleware. I've worked on perhaps half a dozen such systems and I've designed and implemented two of them from the ground up.
So yes, when people start trying to solve server problems by hacking the client, I tend to assume that they probably don't know what they are doing. And if they're not open to the possibility that they are wrong, why on earth would I waste my time working for them? Let alone try to convince them? Life is too short.
You do understand that this is a one-hour interview, not an extended discussion about your software's architecture, right? Are you going to also call out the fact that this doesn't support a hundred million concurrent users and multi-region failover either?
I am kind of shocked you have never had to do this, or that you think it is unreasonable to ask. Sure, it is totally reasonable to ask questions about whether this is standard practice, especially in the real world. But an interview is an environment where you are given the constraints and obviously there isn't time to explain every detail about why something is the way it is.
Yeah, we do want the server to be fixed–there is a team working on it, and they'll have it ready next week. But we need something to work now. That's the where the interview places you. If you are going to be the person who values purity instead of just doing the job when the constraints actually call for it, are you really selling yourself as a good candidate?