Explain Go struct embedding vs inheritance and method promotion

WHAT THIS TESTS: This question probes whether you understand the difference between subtyping and composition, and if you can explain Go's specific embedding rules without falling back to classical OOP vocabulary. Interviewers want to see that you know method promotion is syntactic sugar, not a runtime mechanism, and that you can spot collision behavior.

A GOOD ANSWER COVERS: First, define struct embedding as declaring a field with only a type name, which makes that type an anonymous field whose implicit name is the unqualified type name. Second, contrast this with inheritance by stating that embedding creates a has-a relationship where the embedded type becomes part of the embedding struct, but no value of the outer type is a value of the embedded type, meaning there is no substitutability. Third, explain method promotion: the method set of the embedded type is promoted to the embedding type, so you can call outer.Method() directly if the embedded type has Method(), and this works for both value and pointer receivers depending on how the field is embedded. Fourth, discuss collision resolution: if the outer type defines its own method with the same name, it shadows the promoted method; if two embedded fields at the same depth both have the same method name, the call is ambiguous and causes a compile error.

COMMON WRONG ANSWERS: Calling embedding "inheritance" or "subclassing" is the biggest red flag. Another mistake is saying the outer type can be used wherever the inner type is expected, which is false because Go lacks implicit conversion for embedded types. Some candidates also forget that embedding a pointer versus a value affects which receiver methods are promoted, or they claim collisions are resolved at runtime rather than compile time.

LIKELY FOLLOW-UPS: An interviewer might ask what happens when you embed a type with a pointer receiver method but embed it as a value, or vice versa. They might also ask how embedding interacts with interfaces, such as whether an embedding struct automatically implements an interface if the embedded type does. Another follow-up is asking about embedding interfaces in structs.

ONE CONCRETE EXAMPLE: Imagine a struct Logger with a method Log. If you embed Logger into a struct Server by writing type Server struct { Logger }, then Server gains the Log method automatically and you can write s.Log() where s is a Server. If Server also defines its own Log method, calling s.Log() invokes Server's version, not Logger's. If Server embeds both Logger and Auditor, and both have a Log method, then s.Log() is ambiguous and fails to compile.