I read through this and am really skeptical. There's a focus on optimization, but it only does a first order analysis of efficiency in GoL. Anybody coming in knowing about hashlife is going to have a huge mental advantage over a naive programmer, in a way that tells you NOTHING about the applicant's ability.
When I did a GOL demo (for my own pleasure because: why not?)[1] I quickly got frustrated by the idea that you need a 2D array to store the current state, and a second array for the next state. My thinking was that we only need to know the index positions of the live cells (row * width + col) which can be stored in a 1D array. Identifying neighbour state then resolves into checking whether the currentState array includes the index of the neighbour cell (== alive).
I have no idea whether this approach is more, or less, efficient - but it was an interesting thing to model. Sadly I would've failed the Reddit interview because getting to that solution took me 3-4 hours; I was still fighting with 2D arrays at the end of the first hour.
when I hire I'm looking for folks who spend hours exploring, not the person who finds a local optimum fastest. Failing these sorts of interviews is not a sign you aren't a good programmer.
