This is far from a great engineering interview question, let alone the best. 1. This question is heavily biased towards specific software experience and famili

This is far from a great engineering interview question, let alone the best. 1. This question is heavily biased towards specific software experience and familiarity with the domain and tooling, while at the same time too shallow in terms of algorithmic and logical depth. It is like asking how to parse a CSV file in Fortran. The difficult part is not the problem per se, it is picking up an unfamiliar language and tooling on the spot. For example, someone from Windows background who wasn't familiar with the memcached / Linux environment and tooling / Messy open-source codebase might find it difficult to adapt within the time limit. That doesn't automatically make them bad coders. It is like requiring Emacs and DVORAK keyboards for coding at interviews -- In theory it's all the same, but it's cumbersome and slows you down if you are not familiar. Challenges like this during interviews can lead to high false negatives. People might get stuck on small side things and not working on the main thing enough. 2. This question takes too much time to set up and complete. Interviewers don't have three hours to wait. Interviewees can probably only do one such problem during an onsite and nothing else. Are you going to make a judgement and decision solely based on the performance of this one challenge? I don't think that's a good idea. Also the interviewer needs to explain everything. For a three-hour challenge, this is at least 15 minutes time doing nothing but setting the problem up. 3. This challenge is actually not that great to identify senior / great coders while mediocre coders with specific experience can pass easily.