Typical follow up questions also were also answered well and GPT-4 was able to think of different features etc that a cache implementation may support. Good!

Next, the interviewer and interviewee finalize the requirements to go ahead with for the coding part. So we finalized these. Note that it was able to figure out each of these in the above section. So we filtered these for today's interview. Let's see if it is able to code!

Umm! It started by saying that because of complexity of the problem and limitations of the response format, it can't provide the complete code. Not good. But then asking it to implement completely worked! Now we are getting the code.

We got the code for DistributedCache, CacheNode, ConsistentHashing, EvictionStrategy (interface as well as LRU and LFU implementations). Brilliant!

For some reason it decided not to write the code for Request Collapsing, Async Processing and Prefetching in the first go. Asked it to extend the code to support those and ta-da! Done.

Now time to write test cases. It knew what all use cases to test and also wrote correct test cases. Didn't write for pre fetching as its logic was not defined. So I asked it to define some logic itself and then implement tests. It did, updated earlier classes and wrote tests!

As often an interviewer asks on how does your implementation support xyz, I asked how is Read your own writes supported in the implementation.

I noticed that one of the test case it had written was flaky! Because of concurrency it was producing non deterministic output. Asked about it and it corrected its mistake quickly.

I asked it to implement stickiness of requests for a key to given thread to ensure no consistency issues. It suggested a non optimal ExecutorService but told what an optimal solution will be and also coded that.

Somehow it started going berserk here. Started repeating itself instead of completing the code. 🙃 Also BTW The ExecutorService implementation was wrong. It didn't extend the superclass and didn't implement all methods of it. Asked it to fix that.

But now it had gone berserk. Created a new Cache class which was basically doing the same work as CacheNode. I initially thought it may be doing that to have better code quality. But seems like it was starting to lose context. Defined many of the classes defined earlier again.

To bring it back on track, I copy pasted the code of CacheNode it had written earlier and asked it to modify it for the new ExecutorService. Made some errors, but on prompts got fixed.

I was satisfied with the implementation till now. So asked it to write some more test cases to test comprehensively. Especially concurrent requests. But as it had already started to lose context, did mistakes and I had to tell it the code it had written earlier.

It corrected those and the interview was over. How would you rate it on a scale of Strong Reject to Strong Hire? You can check the complete code with all test cases here: github.com/Naman-Bhalla/llda…