They were probably looking for an answer which went along the lines of a linked list and then what to fix - the ratio of pointer sizes to data (16-item nodes), sorted insert optimizations, the ability to traverse to the 500th element faster etc (skips with pow-10 or a regular skip list etc).
I bombed a similar soft-ball interview question in the past, because I was asked to build out a work item queue using a database in SQL & I got stuck failing to explain why it was a bad idea to use an ACID backend for a queue.
Some constructive feedback from the person who referred me came back as "dude, you just wouldn't let go of the topic and the interviewer gave up on you".
That was definitely true for me, but I remember that feedback more than the actual technical correctness of my opinion.
That was a clear failure of fit in multiple ways, but it didn't matter whether I was right or not, I had failed to persuade someone who would be my team lead on a topic which I had deep knowledge on.
Even if I was hired, it wasn't going to work out.
If you already have an ACID database at hand, and your queue requirements are not that big, using the database and NOT having to have someone around who knows exactly how Rabbit MQ was set up is better than to require everyone around you to know the piece of specialized software that you happen to be a domain expert on.
Conversely if your needs are demanding enough, then it is best not to let your team discover the hard way why people build dedicated queueing systems.
If you are unable to accept that this tradeoff even exists, then I wouldn't want to be your team lead.
Why do you think so? It completely depends on the utilization of their ACID backend, and how well it handles independent data.
