Without the background information you are not really simulating what happens. But I also took some examples from our code base, abstracted them a bit to remove

Without the background information you are not really simulating what happens. But I also took some examples from our code base, abstracted them a bit to remove dependencies on our libraries, simplified the logic and used them in interviews as a "find the bug" type question. I liked that it because you have to read the code, be able to describe what it is trying to do, and then figure out where it goes wrong. Those types of questions have served me well and I always try to ask one when I am asked to interview. But that also was not a realistic description of what happens during a regular workday, but it tries to cover one of the (many) skills you do need, so I think it was a decent proxy. I am not advocating for lots of weird trick questions or brainteasers, but simulating the entire process of design, implementation, test, debug, document, sprint planning and the like. You can't realistically do that in an interview, you pick a few proxies and hope for the best.