Struct Definition
Fast recall
Quick revision
Core answer
Whether you understand Struct Definition 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 struct definition names a group of fields, each with its own type:
type User struct {
Name string
Age int
}Creating values: the composite literal with field names (the only style that survives field reordering), positional (fragile — don't), or the zero value:
var u User // zero: Name "", Age 0 — both executed-verified
u2 := User{Name: "Al", Age: 30}The zero value is fully usable — no constructor needed, no nil state, no 'uninitialized struct' concept. A User with empty name and age 0 is as valid as any other. That design choice (zero values are meaningful) shapes Go: functions document whether the zero value works (bytes.Buffer: yes; strings.Builder: yes) and constructors are the exception for types needing setup, not the rule.
Structs are the only way to bundle heterogeneous data in Go — no classes (methods attach separately), no records, no unions. What they give up in expressiveness they return in simplicity: comparable when fields are comparable (verified: User{Name:"a",Age:1} == User{Name:"a",Age:1} is true), copyable wholesale (assignment copies all fields), and laid out predictably (the compiler orders fields to minimize padding, but you control it by ordering fields yourself).
Struct Definition
Direct Answer
type Name struct { fields }. A struct is a composite of named fields with independent types — Go's only user-defined aggregate. Zero value: every field at its zero value.
Deep Dive & Architecture
The two mechanics interviews probe for:
Field layout: Go stores fields in declaration order, inserting alignment padding as needed — but (unlike C) the compiler MAY reorder to optimize... actually Go's spec guarantees NO reordering: fields stay in written order with padding between. Two consequences: (1) identical field sets in different orders can differ in size — order large-to-small to minimize padding; (2) you can predict the layout for binary formats (with fixed-size types) — though encoding packages exist for that.
Struct literals and the unnamed-struct trick: anonymous structs (struct{ X, Y int }) are valid types — comparable, usable in APIs — and appear in JSON fixtures and tests. The position dependence of unnamed literal fields makes them a maintenance hazard in real APIs (adding a field breaks every positional literal at compile time, which is the safe failure; the unsafe one is silent misalignment when types match).
The zero-value design has an exception worth knowing: maps and slices inside structs are nil after zero-value creation — the struct itself is 'ready' but its reference-typed fields need their own make(). The composite ready-check (reflect or manual) distinguishes 'struct zero' from 'struct ready', and constructors exist exactly to bridge that gap for types whose reference fields are load-bearing.
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 Definition in a real project?
- How would you compare Struct Definition with an alternative?
- What is a common mistake when using Struct Definition?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.