Generate a Go CPU profile and visualize it as a flame graph

WHAT THIS TESTS: Whether you have actually debugged a live Go service or only read about it. The interviewer wants to see end-to-end fluency with the runtime profiling API, the pprof CLI, and flame graph semantics, not just theoretical knowledge of big O complexity.

A GOOD ANSWER COVERS: First, enable profiling by importing net/http/pprof which registers handlers on the default HTTP mux. Second, collect data by running go tool pprof http://localhost:6060/debug/pprof/profile and let it sample for 30 seconds by default. Third, generate the flame graph from the interactive pprof shell by typing png or using the modern web interface with go tool pprof -http=:8080. Fourth, interpret the graph by explaining that the width of each block represents the cumulative CPU time spent in that function and all functions it called, while vertical stacking shows call depth with the root at the bottom and leaf functions at the top. Fifth, identify bottlenecks by looking for the widest blocks because they consume the most CPU samples regardless of where they sit in the stack.

COMMON WRONG ANSWERS: Confusing block width with invocation count is the most frequent error; a narrow block called millions of times can look tiny while a wide block called rarely dominates CPU. Another red flag is claiming the topmost leaf is always the problem without considering that cumulative width higher in the stack might point to an inefficient parent orchestrating the work. Some candidates also forget that CPU profiling adds overhead, typically estimated between five and ten percent, and therefore should not be left running indefinitely in latency-sensitive production paths without measurement.

LIKELY FOLLOW-UPS: How would you profile a short-lived CLI tool instead of a long-running HTTP server. What is the difference between a CPU profile and a goroutine profile. How do you read a flame graph where cgo or kernel time appears. Would you enable all profiles simultaneously in production and why not.

ONE CONCRETE EXAMPLE: Imagine a web handler that serializes JSON. In the flame graph you see a wide block for encoding/json.Marshal near the bottom of the stack. Above it sits a narrower block for runtime.mallocgc. The width tells you that JSON serialization as a whole is the bottleneck, not the allocator beneath it, so you would look at reducing payload size or switching to a streaming encoder rather than tuning the garbage collector.