How do you initialize and manage Go dependencies?

WHAT THIS TESTS: This question checks if you treat Go Modules as the default, production-grade workflow rather than legacy GOPATH patterns. Interviewers want to see that you know the exact roles of go.mod and go.sum, that you understand the difference between a manifest and an integrity log, and that you can describe the day-to-day command workflow without guessing.

A GOOD ANSWER COVERS four things in order. First, initialization: you run go mod init example.com/mymodule to create go.mod, which establishes the module path used as a prefix for all packages in the module. Second, routine dependency management: you add or upgrade dependencies with go get example.com/pkg@version, you remove unused requirements with go mod tidy, and you can vendor with go mod vendor if you need offline or hermetic builds. Third, the purpose of go.mod: it is a manifest that declares the module path, the minimum Go version directive, and the set of required dependencies with their minimum semantic versions, including indirect dependencies that your direct imports pull in. Fourth, the purpose of go.sum: it is not a lockfile in the traditional sense but an integrity log that stores cryptographic checksums for every module version downloaded from a proxy or VCS; the go command uses these hashes to verify that subsequent downloads produce bit-for-bit identical content, preventing supply-chain tampering and ensuring reproducible builds.

COMMON WRONG ANSWERS include saying that go.mod pins exact versions like a lockfile, when in fact it specifies minimum versions and the go command may select newer compatible versions during minimal version selection. Another red flag is claiming that go.sum is optional generated noise that should be gitignored; in reality, go.sum must be committed so that every developer and CI pipeline verifies the same module content. Mentioning dep, glide, or GOPATH-based vendoring as the modern default also signals outdated experience.

LIKELY FOLLOW-UPS: the interviewer may ask how minimal version selection works, when to use go mod vendor, how to handle a major version upgrade past v2 which requires a /v2 suffix in the module path, or what happens when a dependency is retracted.

ONE CONCRETE EXAMPLE: suppose you are building a service and need github.com/gin-gonic/gin. You run go get github.com/gin-gonic/gin@v1.9.1. The go command downloads the module, records the requirement in go.mod, and appends the expected cryptographic hashes to go.sum. A teammate cloning the repo later runs go build; the toolchain checks the downloaded module against the hashes in go.sum and refuses to build if the bits do not match, catching a compromised proxy or network issue.