What is go generate and how does it differ from make?

WHAT THIS TESTS: The interviewer wants to know if you understand the scope and limitations of go generate. Specifically, they care whether you see it as a lightweight automation hook for code generation rather than a build system. The key insight from the official proposal is that go generate was explicitly designed to avoid dependency analysis, unlike make.

A GOOD ANSWER COVERS: First, the purpose: go generate automates preliminary processing such as creating Go source files from yacc grammars, protobuf definitions, or binary assets. It does this by scanning Go source files for //go:generate directives and executing the specified commands sequentially in source order. Second, the invocation model: it is run explicitly by the developer, not automatically by go build or go test. Third, the lack of dependency analysis: the tool does what is asked and nothing more, deliberately avoiding features like incremental builds or dependency graphs that make provides. Fourth, the workflow: generated files are typically committed to version control so that downstream users can build with standard go commands without needing the generator tools installed.

COMMON WRONG ANSWERS: A major red flag is claiming that go generate replaces make as a full build system or that it runs automatically during go build. Another mistake is saying it performs dependency analysis to avoid regenerating unchanged files; the proposal explicitly states this is a non-goal. Candidates also err by suggesting generated files should be gitignored; in practice they must be checked in so that go get works for consumers.

LIKELY FOLLOW-UPS: An interviewer might ask how the //go:generate directive syntax works, including the special -command flag for aliasing tools like go tool yacc. They might also ask about the special variables available, such as $GOFILE, or how the generate build tag can be used to hide files from go build while keeping them visible to go generate. Another follow-up could be when you would choose go generate over a custom Makefile or a tool like Bazel.

ONE CONCRETE EXAMPLE: Suppose you have a package with a protocol buffer file named service.proto. Inside a Go source file, you add the directive //go:generate protoc --go_out=. service.proto. When you run go generate in that directory, the protoc command executes and produces service.pb.go. You then commit service.pb.go to your repository. A teammate can run go build without installing protoc because the generated file already exists, and go build never invokes go generate automatically.