Prompt and context
A Go team maintains several modules. Its public library must keep building with Go 1.26, while an experimental module wants to evaluate generic methods described in the Go 1.27 release notes. The team hopes to place type-related generic operations in a method namespace without changing interface compatibility, toolchain requirements, or release pipelines. Explain the language boundary, experiment design, build matrix, and exit conditions.
The Go page explicitly labels the 1.27 notes as draft, says the release is not yet available, and expects an August 2026 release. It describes methods declaring their own type parameters, while stating that interface methods cannot declare type parameters and cannot be implemented by generic methods. Treat these as pre-release constraints, not stable language promises.
What the interviewer is assessing
The interviewer is testing whether you can distinguish type parameters on a type, function, and method, and whether you understand that a seemingly more generic method does not automatically satisfy an interface. Strong answers propose a minimal experiment, compiler and go.mod matrix, public-API isolation, rollback, and a record of draft changes.
Clarifying questions to ask
- Is the goal caller expressiveness, type inference, or reuse of an internal implementation?
- Could experimental code be imported by stable modules, generators, plugins, or external consumers?
- What is the minimum Go version, interface surface, and release cadence for the public API?
- Which compilers, analyzers, IDEs, and CI platforms must be verified?
- If the draft is renamed, withdrawn, or semantically changed, can the experiment be deleted without changing stable modules?
30-second answer
“I would label Go 1.27 as draft and put the experiment in an isolated module and CI job without changing the Go 1.26 public API. A generic method may declare its own type parameters, but interface methods cannot, and a generic method cannot implement one; I would verify those boundaries with concrete interfaces and generic functions. The experiment would measure readability, inference, compile time, and tool behavior, not publish draft syntax to stable consumers. Any compiler, interface-satisfaction, or generated-code inconsistency would close the experiment and keep the stable implementation.”
Step-by-step deep answer
1. Confirm version facts and experiment goals
Record the official page date, draft status, and expected release instead of treating work-in-progress notes as a specification. Turn the goal into measurable hypotheses, such as fewer package-level helpers, clearer call-site inference, or better expression of an internal data structure. “Generic methods are nicer” is not a pass criterion.
2. Separate the three type-parameter boundaries
A type can declare its type parameters, a function can declare parameters inferred at the call site, and the draft generic-method feature lets a method declare its own parameters. Interface methods still cannot declare type parameters, and an interface does not gain a generic method merely because a concrete type provides one. Show both compiling and intentionally failing examples so the failure is understood as a language rule rather than a tooling bug.
type Box[T any] struct {
value T
}
// Go 1.27 draft syntax; do not publish from a stable Go 1.26 module.
func (b Box[T]) Convert[U any](fn func(T) U) U {
return fn(b.value)
}
type Converter interface {
// Interface methods cannot declare their own type parameters.
Convert(/* generic method is not allowed here */)
}The method syntax is shown only to frame the draft discussion. A real experiment must use the released compiler and its release notes; the commented interface is not a compilable public API.
3. Isolate draft code in a separate module
Put the experiment in its own directory and go.mod, pin the toolchain, and prevent stable modules from depending on it. The public library keeps building with Go 1.26. The experimental module may use a draft compiler, but its artifacts must not enter stable packages, generated templates, or cross-module interfaces. Removing the experiment should require deleting a module and CI job, not rewriting consumers.
4. Build a compiler and tooling matrix
Cover the stable Go 1.26 compiler, the toolchain used for the draft, go vet, static analyzers, IDE language servers, and target platforms. Check inference, diagnostics, compile time, cache behavior, cross-compilation, documentation, and generators. A generic method can compile while formatters, analyzers, or generators still lack complete support.
5. Test interfaces and functions instead of assumptions
For each case, record the expected compiling and non-compiling result: concrete method calls, package-level generic functions, interface assignment, method values, method expressions, and reflection. The tests should prove whether caller complexity actually falls. If an interface still needs an adapter, the feature may have moved syntax without reducing coupling.
6. Set exit and release gates
Stop if draft semantics change, the compiler crashes, tooling cannot process the code, a public API leaks the minimum-version change, or benchmarks show no repeatable benefit. Keep a stable implementation, a feature switch, and a comparison baseline. Do not change the main module's go directive or public API before a final release and migration review. Record compiler versions, commit hashes, and known limitations.
High-quality sample answer
I would first confirm that the Go 1.27 page is still draft, then put generic-method experiments in a separate module and CI job. The answer must state that methods may declare type parameters, while interface methods may not and cannot be implemented by generic methods. I would test concrete calls, package-level generic functions, interface assignment, method values, and tools; the stable library would continue to build with Go 1.26, and no draft syntax could enter its public API, generated code, or release artifact. Only after a final release, compiler and tool support, repeatable benchmarks, and a compatibility review would I discuss migration; otherwise I would close the experiment and keep the stable implementation.
Common mistakes
- Treating draft release notes as a stable specification → Semantics and syntax can change → Record the status and isolate the experiment.
- Assuming interface methods can declare type parameters → It violates the documented boundary → Test concrete interfaces and generic functions separately.
- Making a Go 1.26 module depend on the experiment → The minimum toolchain rises silently → Keep stable and experimental modules one-way isolated.
- Checking only compiler success → vet, IDEs, generators, or cross-compilation can fail → Run a complete tooling matrix.
- Deleting the stable implementation for new syntax → A withdrawn draft leaves no rollback → Keep a comparison implementation, switch, and exit gate.
Follow-up questions and responses
What is the core difference between a generic method and a generic function?
A generic function declares type parameters on a package-level function. A generic method declares its own type parameters on a method of a receiver type. The method namespace can match the call site better, but it does not automatically change interface rules.
Why cannot an interface method simply follow a generic method?
Interface satisfaction needs a stable, comparable method set. The official draft says interface methods cannot declare type parameters and cannot be implemented by generic methods, so the boundary must use concrete methods, adapters, or package-level generic functions.
How do you prove the experiment did not leak into stable modules?
Build the Go 1.26 module independently, inspect its dependency graph, generated packages, and release artifacts, forbid imports of the experiment path in CI, and audit public symbols and version directives.
Is compiler success enough?
No. Verify gofmt, vet, analyzers, IDE support, generators, cross-compilation, documentation, and benchmarks because a draft can land in the compiler before the rest of the toolchain is ready.
When can a production project migrate?
After the final release, stable language and tooling behavior, passing interface and build matrices, repeatable benefits, a rollback path, consumer communication, and a reviewed version policy, start with a small migration.