I've conducted a fair number of interviews. At least one of the problems I pose to candidates are to test if they will ask questions that clarifies what I am asking for. Because being able to articulate both what you want to accomplish and what the non-negotiable constraints are, is a key skill. The more senior you are, the higher this part of the interview gets weighted.

This is also how a candidate can get to know the interviewer and possibly the company he is interviewing at. What does the interviewer say when you start picking apart what they are actually asking about.

The way this problem is posed has two main issues. The first is that it is unclear what the interviewer actually wants. The second is that the problem to be solved isn't well defined. This is later confirmed when we read the blog posting and it is revealed that rather than designing a solution to a problem, the interviewer expects the candidate to hack their way to a solution. Not to recognize what you are trying to accomplish and reason about how to solve such problems, but just peck at the problem. Mess with the code.

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.

It gets further confused by adding poorly motivated extensions to the problem while misusing nomenclature. It appears he is asking for how to solve a difficult problem in messaging systems, but he isn't. He is asking for convenient ways to implement something much simpler. Which even makes me question if he would have recognized someone smarter than him misunderstanding and solving a harder problem -- someone who is capable of solving the kind of problems his use of nomenclature hints at, but apparently wasn't after.

Now, think about your reaction to this problem formulation from my perspective. From the perspective of someone who wants to hire senior developers. When I hire people I need people who can solve problems. Lacking that, I need someone I can train to solve problems. I have no need for people who dig themselves out of holes brute force. This is why some portion of my interview questions will only work if the candidate asks questions. Some of these interview questions are really easy to solve from a technical/algorithmic point of view, but only if you can identify the underlying problem.

If I had presented the problem as stated to a candidate and they did what the interviewer seemed to want, I'd probably have added them to the reject pile for lack of ability to take a step back and point out that this is a bit silly.

> 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?