I think you're over-thinking this. Andrew, my company has asked me to assess *coding* skills and has given me 45m to do so. No, you should NOT spend the entire hour asking clarifying questions or over-thinking how you would do this "in the real world". This is NOT a systems design interview. This is NOT a leadership interview. It's good to ask some questions and show you're thinking about different tradeoffs, but I have a very specific signal that I'm expected to gather, and at the end of the day you do need to have working code.

Honestly, I'm not that convinced that you need to introduce multithreading "in the real world" either, but I think at this point is more of an academic discussion that has two possible legitimate paths (yours or mine). I've written extensive multithreaded code in my life, as I created Amazon's load generation infra that runs at 40 million transactions per second, and I've dealt day in and day out with everything you just mentioned. Multithreading introduces a huge amount of complexity and if your algorithm is already running at O(n) that might be good enough to not bring in the extra complexity of multithreading.

If you wanted to write a multithreaded version of this, and finish it within the 45m limit of a *coding* interview, by all means go for it :)