Hacker News Reader

Comment by johnfn | Hacker News Reader

OP's solution seems a little clunky to me. He does this thing where he loads the first day into a hashmap, and then he queries it as he loops over the second day. But why? That just overcomplicates your algorithm, and the memory used by O(2) days is roughly the same as O(1) days. It's also overly specialized to solving the very precise problem that's posed in the interview; what if tomorrow Big Boss wants you to aggregate over 3 days?

A cleaner solution would be to load both days 1 and 2 into the same hashmap. Then you can iterate the map and count whatever condition you want.

View on HN

I agree. I hate how these interviews always focus so much on algorithmic time at the expense of flexibility of the code. I agree with the first part about avoiding the n^2 algorithm by using hash maps. However, making your algorithm use half the memory but hardcoding the requirement that a user visited on two days is bad design, especially when it's only halving the memory used. Also not only does it hardcode the requirements, it also makes it much more complex logic wise as you need that "if pages from day 1 >= 2 or first page from day 1 != page from day 2".

My design was to create two hash maps, one for customer to a list of days and one for customer to list of pages, though after reading the article I realized my lists should really be sets. Then you can easily account for any change to the definition of a loyal customer, as all you need to do is use two O(1) lookups and then check the size of the lists. Easy, flexible, and little room for error.

> I agree. I hate how these interviews always focus so much on algorithmic time at the expense of flexibility of the code.

Especially when the question scenario is generating "business metrics" which tend to see a lot of tweaking and iteration.

Having engineers who make contextually appropriate designs and architectures is at least as important as having engineers who are math-whizzes.

Reply on news.ycombinator.com