When do you log at warn and when at error, and what should you never put in a log?
Suggested answer
The interviewer wants to know whether you see logs as a tool for the next person to find a cause, and whether you know how to classify events so that real errors don't get buried.
A simple classification that is easy to remember is to ask "whose fault is it?". The info level is for normal things, for example an order was received. The warn level is for when the caller sent something wrong, such as a request rejected because the data is invalid (a 4xx status): the server did its job correctly. The error level is for when the server did something wrong or hit a situation nobody foresaw (a 5xx status), and a person needs to look.
The reason to separate them: if everything is logged as error, a website that sends five hundred bad orders creates five hundred red lines that hide the one real server error. Filtering by error at two in the morning is only useful when the error level means something.
A good log line answers four questions: what happened, when, in which request, and how important it is. That is why every request should get its own ID (a request id) attached to all of its lines. If you wrap one error in another, keep the original in cause so the log can still tell the real reason.
As for what not to log: personal data such as names and phone numbers, and secrets such as passwords, tokens and API keys. Log files get copied to many places, so anything that goes into a log should be considered leaked outside the project. When you reject a request because its data is wrong, log the field name and the reason, not the value the user sent.
Bonus points: mention that you shouldn't swallow errors with an empty catch block, and that when you return a 500 to the caller you only give a code to look up, while the internal details stay in the log.