Logging Framework — OOD Interview Walkthrough

Phase 1: Requirements & Use Cases

Interviewer: "Design a logging framework."

Candidate: "Let me clarify scope. I'm designing an in-process logging library — something like Log4j or Python's logging module — that application code can use to emit log messages at different severity levels, filtered and routed to one or more output destinations like console, file, or a remote endpoint. I'm not designing a distributed log aggregation system like ELK or Splunk. Does that match your intent?"

Interviewer: "Yes. What are the core use cases?"

Candidate: "Core use cases:

1. Application code logs a message at a severity level (DEBUG, INFO, WARN, ERROR, FATAL)
2. Log messages are filtered by minimum level — DEBUG messages don't appear in production
3. Log messages are routed to one or more appenders (console, file, remote)
4. Log messages are formatted consistently — timestamp, level, logger name, message
5. Multiple loggers can exist with independent configurations (per-class or per-module logging)
6. Logger hierarchy: a child logger inherits its parent's appenders if not configured"

Interviewer: "What about async logging, log rotation, and structured JSON output?"

Candidate: "Log rotation and async delivery are infrastructure concerns — I'll design appenders with a clean interface so async wrappers can be added, but async isn't in the core model. Structured JSON output is a formatter variant — I'll design Formatter as an abstraction so JsonFormatter is just another implementation. Log rotation would be a concern for FileAppender — I'd note it as an extension point but not implement it in the core design."

WHY: Keeping infrastructure concerns…