Writing one byte at a time may be “bad” at many levels. First, on a hardware level it is inefficient because the unit is a sector/block and the access latency kicks in hard, together with a wear leveling on ssds. Embedded low level indeed. On an os/syscall level it is inefficient because of a syscall time itself. It is a system level touching C and unbuffered writes in “middle-level” languages/libs. On an application level it may be inefficient if a stream has a processing pipeline with some expensive setup/try/teardown (e.g. a jsonl parser which “tries” the buffer at every new chunk). Is this still low level?

This is a question about streaming, buffering and latency avoidance, which you may not know in hw detail, but have to have at least a vague grasp of. If a candidate seems confused, one may ask them about other situations where one-at-a-time may become “bad”: sql select one row at a time, fetch NNN items one by one, use heavy_expr().x, heavy_expr().y repeatedly or in a loop. If nothing comes to their mind, chances are you are interviewing a completely inexperienced person, because there is no way they didn’t meet that or think of that before.

I totally agree that it shouldn’t be the reason to skip a candidate, but hiring is an analyzing process, and how do you find their limit if not asking deep open questions? I think that the issue is pushing hard on these areas as if it was laughable for a professional to not know it.