As asked
How do you decide where to define interfaces in Go, and why do experienced Go teams prefer small consumer-owned interfaces?
Sample answer outline
In Go, interfaces are satisfied implicitly, so the consumer can define the behaviour it needs without forcing producers into a shared abstraction. Small interfaces such as io.Reader or a one-method Store make tests and substitutions easy while keeping production types concrete. Defining large provider-owned interfaces too early creates brittle mocks and hides useful methods behind an artificial surface. The candidate should connect this to package boundaries and dependency direction. A strong answer also says when no interface is needed because a concrete type is clearer.
Expect these follow-ups
- When is a provider-owned interface justified?
- How do generics change this decision, if at all?
- What is the smell in an interface with ten methods?