Prompt and when it applies
A Go repository with multiple modules, older build constraints, and generated code is preparing to adopt Go 1.26. The team wants to use go fix for modernization, such as replacing temporary pointer construction with new(expr), but cannot put 1.26 syntax into modules that still compile with older toolchains. It also cannot treat an automated rewrite as proof of correctness. How would you split the migration, review diffs, test it, and roll it back?
This tests toolchain migration and code-review judgment, not release-note memorization. The Go 1.26 notes say that go fix uses the same analysis framework as go vet and provides behavior-preserving modernizers; a strong answer still addresses version gates, generated code, dependencies, and release risk.
What the interviewer is assessing
A strong answer builds a module/version matrix, chooses explainable batches, proves safety with compilation, tests, static checks, and runtime signals, and preserves rollback boundaries. A weak answer says “run go fix, run tests, commit” without defining what may change, when automation is unsafe, or how cross-module dependencies are handled.
The interviewer is also checking whether you treat go fix as a suggestion generator rather than a permission upgrade. It recognizes code patterns, not hidden generation workflows, reflection contracts, external consumers, or business semantics.
Questions to clarify before answering
- What is each module’s minimum Go version? A module below 1.26 cannot accept source that depends on 1.26 language features.
- Is there generated or vendored code? Change generators and regeneration policy; do not batch-edit vendor copies.
- Is the goal language modernization or dependency upgrade? Separate them to shrink diffs and allow independent rollback.
- Which areas are behavior-sensitive? Serialization, reflection, interface assertions, build tags, cgo, and public APIs need extra review.
- How will downstream compatibility be checked? Define unit, integration, race, benchmark, and consumer builds instead of relying only on repository tests.
A 30-second answer framework
Say: “I would first record each module’s minimum Go version, generation source, and release dependencies, and only let code that meets the 1.26 gate enter the candidate set. I would run go fix in one small module, save the patch, and review it before formatting, compiling, testing, race checking, and benchmarking. I would expand in batches with an old-toolchain build and a rollback point. For public APIs, reflection, and generated code, I would use manual or generator changes and verify downstream builds and runtime signals.”
This covers constraints, choice, validation, and failure paths without presenting the command as the result.
Step-by-step deep answer
1. Build a version and ownership matrix
List each go.mod directive, toolchain, release path, consumer, and generation entry point. Go 1.26 modernizers use the module’s minimum version to decide applicability, so upgrading declarations and then rewriting everything would hide compatibility problems until later.
2. Limit automation to a reviewable scope
Start with one module or one fixer and produce a patch instead of overwriting the worktree. Exclude vendor, generated directories, and external mirrors; change generators and regenerate their outputs. Record the fixer, file count, module version, and expected semantic effect for every batch.
3. Understand one representative rewrite
Go 1.26 lets new take an expression that supplies the initial value:
limit := new(64)It creates a pointer to that initial value, but only when the module language version permits the syntax. Review generic instantiations, constant type inference, pointer serialization, and escape behavior. Do not mechanically replace every new(T) with new(value).
4. Run layered validation
For each batch run formatting, compilation, unit tests, race tests, and static analysis; build a downstream module for public libraries. Compare throughput, allocations, and latency for performance-sensitive packages, and add real samples for reflection or serialization packages. If validation fails, return to that patch rather than merging every automated change together.
5. Handle boundaries that go fix cannot understand
The tool cannot prove the semantics of runtime reflection strings, generator templates, ABI conventions, or external consumers. Keep a manual patch and write down the invariant. A serialization layer should compare nil and non-nil pointer output; a public API should compare exported symbols and documentation, not only local compilation.
6. Design release and rollback
Release with independent commits or a feature flag, keeping an old-toolchain build and rollback artifact for each batch. Watch error rate, startup failures, allocations, benchmark regressions, and downstream build failures. If a threshold is crossed, roll back the last batch rather than reverting the entire version adoption.
7. Keep one reusable decision rule
Remember: version before syntax, patch before batch, tests before release, generator before generated output, and metrics before “it looks fine.” go fix reduces mechanical work; it does not replace module governance or behavior validation.
High-quality sample answer
“I would inventory every module’s minimum Go version, generated-code entry point, and downstream consumer, then separate language modernization from dependency upgrades. For a small module already allowed to use Go 1.26, I would run go fix to produce a patch, exclude vendor and generated directories, and review new(expr), generics, reflection, and serialization boundaries. I would run gofmt, builds, unit and race tests, static analysis, and key benchmarks; a public library would also build an older consumer. Each batch gets its own commit and old artifact. During release I would watch errors, startup failures, allocations, and downstream builds, and roll back the last batch on a threshold breach. For generated code I would change the generator and regenerate rather than edit output. Automation handles mechanical rewrites; version matrices, tests, and runtime evidence establish correctness.”
The answer does not claim the tool proves every semantic and does not bind dependency upgrades, rewrites, and release into one irreversible operation.
Common mistakes
- Mistake → Run go fix across the whole repository → Why it fails → Old modules, vendor, and generated output get mixed in → Fix → Define candidates by module version and ownership.
- Mistake → Run only unit tests → Why it fails → Race, performance, and consumer compatibility can regress → Fix → Add layered validation for risky areas.
- Mistake → Treat new(expr) as a replacement for every pointer construction → Why it fails → Type inference or nil semantics may change → Fix → Review expression types and serialized output by pattern.
- Mistake → Edit generated code directly → Why it fails → The next generation overwrites the change → Fix → Change the generator and pin its version.
- Mistake → Commit all automated changes together → Why it fails → Regressions and rollback scope are hard to locate → Fix → Commit per module and fixer.
Follow-ups and how to respond
What if the module says go 1.25 but the build tool is 1.26?
Separate toolchain version from language version. A newer toolchain can build the module, but whether source may use 1.26 syntax depends on the module directive and build constraints. Confirm the compatibility target before changing the declaration and consumer matrix.
Tests pass, but serialized output changes after the rewrite. What do you do?
Treat serialized output as a compatibility contract. Compare old and new artifacts on the same samples, identify the exact rewrite, and roll back that batch for an unacceptable change. If the change is allowed, update the contract, consumers, and release notes.
How do you prove generated code was not missed?
Pin the generator in CI, regenerate, and require a clean worktree. Link generator source, artifact hash, and build version. Review generator changes rather than treating edited output as the durable fix.
When should you not use go fix?
Do not batch-run it when module versions are unsettled, code is externally generated, public ABI is involved, or executable validation is missing. First establish ownership, compatibility, and tests; then choose a small manual change or defer the migration.