This is a great interview question. It's very easy to formulate and explain, and yet the interviewer can gauge the depth of a candidates os knowledge by digging deeper into any solution, with no easy 'perfect solution'.
I'd argue this has the same problems as many existing interview questions: It relies on arcane knowledge that won't be used day to day at the job in question, and rewards the candidate who is lucky to know the answer or answers.
Can we stop with the silly/trick/arbitrary interview questions? I know we cannot, but I dream for the day.
It's a good question because even supposing that you have no prior knowledge of the problem at hand you should be able to think of some obvious problems if you have any programming experience.
You have N number of writers, those writers can write X sized data to location A.
How would those writers go about writing to "A" in a performant manner without causing issues? Whether those issues are interleaved data, slowing down the N writers or having to keep outsized buffers on the OS level.
Even if you have no knowledge of POSIX filesystems you should be able to reason about this in an intelligent way in an interview.
Do we go for locks? That has its own set of problems, what are those? Do we go for fixed sized non-interleaved guarantees? What problems does that cause? Do we buffer arbitrarily sized output and and merge it later etc.
