What is the difference between GOPATH mode and Go modules?

GOPATH required all Go code to live in a single workspace directory with no versioning. Go modules introduced go.mod for explicit versioning, reproducible builds, and support for any directory structure.

GOPATH mode (legacy)

1
All Go code must live under $GOPATH/src/
2
No versioning — go get always fetches the latest commit
3
No reproducible builds — different developers could get different dependency versions
4
Cannot have multiple versions of the same dependency
5
Effectively deprecated — only use for very old codebases

Go modules (current standard)

1
go.mod declares module name, Go version, and direct dependencies with versions
2
go.sum contains cryptographic hashes for all dependencies — guarantees reproducibility
3
Module proxy (proxy.golang.org) caches modules — works even if the original repo is deleted
4
Private modules: set GONOSUMCHECK and GOMODCACHE for internal packages
5
Minimum version selection (MVS): Go always picks the minimum satisfying version, not the latest

go.mod example

Difficulty: 5/10

Topics: dependency management, workspace layout, build reproducibility

Scenario Questions

0-2 years experience

1
You need to add a new third‑party library to a small Go project that currently uses GOPATH. How would you fetch and import it, and what would change if the project used Go modules instead?
2
If you run go build inside a directory that contains a go.mod file, what does the Go toolchain do differently compared to a directory without one?
3
Your CI script sets GOPATH and runs go get ./.... After adding a go.mod file the build fails. Why does this happen?

2-5 years experience

1
Your team is adding a new microservice that lives in a GOPATH‑based repo, but management wants to adopt Go modules for better versioning. What migration steps would you take and what pitfalls would you watch for?
2
During a release a dependency version conflict appears only when building with modules enabled. How would you diagnose and resolve it?
3
A build that succeeded on a developer’s machine using GOPATH started failing on the CI server after the CI switched to module mode. What could be causing the discrepancy?

5-8 years experience

1
You are designing a shared library that will be consumed by dozens of services across the company. How would you structure its repository and choose between GOPATH and Go modules to ensure reproducible builds and easy upgrades?
2
Our monorepo contains many legacy packages that still rely on GOPATH. Introducing modules caused duplicate import paths and version skew. How would you architect a migration strategy that minimizes disruption and supports incremental adoption?
3
Discuss the performance and caching implications of using a module proxy versus GOPATH vendoring in a large CI pipeline that runs thousands of builds per day.

8+ years experience

1
The organization plans to deprecate GOPATH entirely and enforce module usage across all teams. What organization‑wide policies, tooling, and migration road‑map would you propose to handle legacy code, vendor directories, and external dependencies?
2
Consider multiple teams needing to share internal packages with different version requirements. How would you design a versioning and publishing strategy using Go modules that balances stability and flexibility, and what governance model would you put in place?
3
If you had to support both Go 1.13 (module‑aware) and older Go versions that only understand GOPATH, how would you architect the build system and repository layout to serve both without duplication?

Follow-up Questions

❓How does vendoring interact with Go modules versus GOPATH?
❓What challenges have you faced when migrating a legacy codebase to modules?
❓When might you still choose GOPATH over modules in a new project?