I agree with what you've said, though you have some mistaken assumptions. They aren't exact duplicates. Instead, the code to send an impression was firing repe

I agree with what you've said, though you have some mistaken assumptions. They aren't exact duplicates. Instead, the code to send an impression was firing repeatedly, so it'd be more like that person refreshing the page once per second thousands of times (except the page content never changes if they don't refresh). At it's most basic, you're essentially just finding chains of impressions based on lag from the last impression. In practice, we also need to maintain data integrity (foreign keys) and deal with several other issues stemming from common cases where the assumption 'if they are within X seconds, count as duplicate' doesn't hold. So you could completely ignore performance and still have a question that could prompt a lot of discussion with a candidate (though performance should be part of that discussion). I'm not sure if we'll end up using it due to the relatively large amount of baggage associated with the problem (table layout and business requirements), I've just been toying with reducing the problem down to a simpler prompt that would be feasible. I'm fairly new to interviewing/hiring, but I really like questions that cut across multiple 'areas of competency' and are amenable to asking followup questions ('what if we wanted to add X?'). Algorithmic questions have their place, but have less day-to-day relevance. We can teach algorithmic stuff on the job.