Databricks Software Engineer Interview Experience — Hit Counter Question, Rejected Over an Edge Case

The question was hit counter. This question isn't very clearly documented on the boards in terms of the exact requirements and follow-ups, so let me share what I remember as a reference.

They started by giving 3 APIs and said I could ask clarifying questions:

• put(key, value)
• get(key)
• get_load() # this gets the QPS for get and put separately — I actually wrote two separate ones for each

The requirement was QPS over a fixed window of 5 minutes, using system time as the timestamp. I used time.time() and confirmed that was OK with him, but I said this would make testing inconvenient, and he said it was fine.

I proposed two approaches:

• a queue storing (timestamp, count) pairs, maintaining a running total count
• a ring buffer / time bucket, also maintaining a running total count

After hearing my explanation, the interviewer just said, let's write the ring buffer code.

So I started writing. While I was writing, he had me explain what the point of recording last_second was.

After I finished, I wrote a simple test case and ran it. Just as I was about to write more test cases, he said the code was fine, but told me to look at what problem there might be with how I was computing QPS. What I had written was total_count / time_window (300). We went back and forth on this for a while. He hinted that if the server only ran for a few seconds before crashing, then time_window should be the server's actual running time, not 300... So it should be total_count / min(server_running_time, 300). I asked, then where does server_running_time come from? He said you could take it as an input, start_time = 0....

Follow-ups:

• If the time window isn't fixed and can be very long, e.g. 300 days? I answered with a hierarchical bucket approach; the interviewer didn't commit either way.
• What if the API calls are very concentrated in time, or very sparse? I said the queue approach would be more suitable then, because it doesn't need fixed memory; the interviewer still didn't commit either way.

Four days later I got the rejection. I think it's probably because I failed on that edge case — honestly, I hadn't thought of that case when I was preparing.