Question 1

What should you actually log, and what should you never log?

Accepted Answer

Log **what you would need to diagnose a problem you cannot reproduce** — and never log anything that turns your log store into a liability. Most logging is written for the moment it is added rather than for the incident where it will be read, which is why so little of it helps.

**What to log:**

**Errors with full context** — the exception, the stack trace, and the **inputs and state needed to understand it**. An error message with no context is nearly useless.

**Significant state transitions** — order placed, payment captured, user deleted — which form the audit trail.

**External calls**, with target, duration and outcome, since other systems are where unexplained behaviour usually originates.

**Decisions the system made**, particularly where it chose between paths or applied a rule — this is what you need when asking "why did it do that for this user?".

**A correlation or trace identifier on everything**, propagated across services. **This single practice transforms debugging distributed systems**, and its absence makes it close to impossible.

**What to never log:**

**Passwords, tokens, API keys, session identifiers** — including in full request bodies and headers, which is the usual accidental route.

**Full card numbers**, and anything under payment rules.

**Personal data beyond what is necessary**, since logs are subject to data protection law, are widely readable inside an organisation, and are frequently retained longer than the systems they describe.

**Health data, credentials in URLs, and full request/response dumps** as a default.

**How to log well:**

**Structured logging.** Emit key-value fields rather than interpolated prose, so logs are queryable. **"User 4821 failed login from 10.2.1.3" cannot be aggregated; the same data as fields can.**

**Use levels meaningfully**, and resist the drift where everything becomes `INFO`.

**Do not log in tight loops**, which costs real performance and buries the useful lines.

**Make it sampleable**, and set retention deliberately.

**Redact at the logging layer**, not by remembering — the only reliable protection.

**Logs are one of three signals**, alongside metrics and traces, and each answers a different question.

Question 2

What is observability, and how is it different from monitoring?

Accepted Answer

Monitoring tells you whether the things you anticipated are behaving. Observability is the property of being able to answer questions you did not anticipate, from the data the system already emits.

Question 3

When should I use a database transaction?

Accepted Answer

The rule is simple to state: use a transaction whenever two or more writes must either all succeed or all fail. If a partial result would leave your data in a state that should never exist, those

Question 4

How do you read a stack trace?

Accepted Answer

A stack trace is a snapshot of the chain of function calls in progress when something went wrong — read correctly it usually identifies the problem in under a minute, and read incorrectly it looks

Question 5

What is a blameless postmortem?

Accepted Answer

A review after an incident that focuses on understanding what made the failure possible rather than on identifying who caused it — and the reason it works is practical rather than cultural

Question 6

What is responsible disclosure, and how do bug bounties work?

Accepted Answer

Responsible disclosure is reporting a security vulnerability to the affected organisation first, giving them time to fix it before details become public. A bug bounty programme is the formalised,

Question 7

What are effective debugging techniques for C++ beginners?

Accepted Answer

Effective C++ debugging techniques for beginners include print statements, using a debugger, static code analysis, unit testing, memory management tools, and code reviews. Each method serves distinct purposes in identifying and resolving errors.

Related Questions