Struct Literal And Fields
Fast recall
Quick revision
Core answer
Whether you understand Struct Literal And Fields beyond memorized syntax.
Giving a definition without explaining a practical trade-off.
Connect the concept to a small production example and state its complexity or failure mode.
Interview-ready guide
Interview answer
A field is a named slot of a declared type inside the struct:
type Node struct {
Value int // builtin
Children []*Node // slice of pointers to THIS type — linked structures
Meta map[string]any
Action func() error // function field
Clone interface{} // interface field
}Every type in the language is field-eligible: builtins, user structs (nested — and self-referential via pointer, which is how trees and lists exist: a struct cannot contain ITSELF by value (infinite size) but can contain a pointer to itself — fixed size), pointers, slices, maps, channels, functions, interfaces. The only layout rule: field types must be known sizes — which the pointer-to-self rule satisfies.
Zero values compose: a zero Node has Value 0, Children nil, Meta nil, Action nil, Clone nil — each field independently at ITS type's zero value. The struct is 'ready' with all fields zeroed — the zero-value design cascades into struct fields.
The promoted/exported rules: capitalized field names are exported (visible outside the package); lowercase are package-private. Unlike Go methods, there's no 'promoted field' mechanism beyond embedding's promotion — regular fields are accessed only through their name at the depth declared.
The layout fact interviewers probe: fields are laid out in DECLARATION ORDER (Go guarantees no reordering — unlike C compilers). The compiler may insert padding for alignment; you minimize it by ordering fields large-to-small. Two structs with identical field sets in different orders can have different sizes — and unsafe.Sizeof proves it.
Struct Literal And Fields
Direct Answer
Named, typed slots — any type: builtins, other structs, pointers, slices, maps, channels, functions, interfaces, even the struct itself via pointer (for linked structures).
Deep Dive & Architecture
The declaration-order guarantee is the deep one, because it's what Go REFUSES to do that C-family compilers do: no field reordering. The spec pins the layout: fields in written order, with implementation-defined padding. The result is (1) you can reason about memory use by reading the definition top-to-bottom — unsafe.Offsetof/Sizeof confirm the arithmetic; (2) struct types are interchangeable with C structs via cgo when layouts are written to match; (3) the size optimization is YOUR manual job — the govet fieldalignment check exists precisely to flag structs whose field order wastes padding (a struct with 1 bool, 1 int64, 1 bool uses 24 bytes: 8 (bool+pad) + 8 + 8; reordered int64-first-bools-last: 16 bytes — the optimization is real and mechanical).
Self-reference mechanics, one layer down: the compiler computes struct size bottom-up; a field of the SAME type by value would recurse infinitely — compile error 'invalid recursive type.' A pointer field is a fixed-size word whose pointee's size is irrelevant to the struct's own size — the recursion is broken by indirection. That's why every linked structure (lists, trees, graphs) in Go is built from pointers-to-self, and why the pattern type Node struct{ next *Node } is instantly recognizable as the shape.
The function-field distinction worth naming in interviews: a func FIELD (Action func() error) is data — assignable, nil-able, swappable per instance. A METHOD is on the type — fixed, promoted via embedding, part of the method set. The two compose the strategy pattern without interfaces when per-instance behavior is needed (each Node carries its own Action — set at construction, changed at runtime), while method sets handle per-TYPE behavior. Confusing them leads to 'I made a method but each instance needs a different one' — the field is the answer.
Common Mistakes & Pitfalls
Giving a definition without explaining a practical trade-off.
Check your understanding
Answer these without looking back at the article.
- When would you use Struct Literal And Fields in a real project?
- How would you compare Struct Literal And Fields with an alternative?
- What is a common mistake when using Struct Literal And Fields?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.