Define a User struct and map of IDs to pointers

WHAT THIS TESTS: This question probes your fluency with Go's core composite types and memory semantics. The interviewer wants to see that you can declare a struct, initialize a map correctly, and reason about pointer versus value storage. At senior levels, the focus shifts from syntax to implications: pointer values in a map enable shared mutation and affect escape analysis, while value copies are safer but isolated. You should also show awareness that map keys must be comparable, though here the key is a simple int.

A GOOD ANSWER COVERS: First, declare the struct with the requested fields: type User struct { ID int; Name string }. Second, allocate the map with make and the exact composite type: users := make(map[int]*User). Third, populate the map by taking the address of struct literals or existing variables, such as users[1] = &User{ID: 1, Name: "Alice"}. Fourth, explicitly note that because the map holds pointers, modifying the struct through one reference affects all references to that same object. Fifth, mention capacity hints when appropriate, like make(map[int]*User, 100), to reduce rehashing. Finally, show safe access with the comma-ok idiom: if u, ok := users[id]; ok { ... }.

COMMON WRONG ANSWERS: A major red flag is declaring a nil map with var users map[int]*User and then attempting to write into it, which produces a runtime panic because nil maps are not writable. Another mistake is using map[int]User instead of map[int]*User, which stores copies; updating an entry then reassigns the entire value rather than mutating a shared object. Storing the address of a loop variable inside a map is also dangerous because the single loop variable gets overwritten, causing every map entry to point to the final iteration's data. Additionally, forgetting that a nil pointer value in a map is different from a missing key can lead to subtle bugs.

LIKELY FOLLOW-UPS: The interviewer may ask what happens if two map keys reference the same underlying User struct and one is modified. They might also explore concurrency, expecting you to protect the map with a sync.RWMutex or to discuss sync.Map for high-contention caches. Another common follow-up is how to safely delete an entry with delete(users, id) or how to distinguish a missing key from a nil pointer using the comma-ok idiom. You might also be asked about memory overhead of pointers versus values in large maps.

ONE CONCRETE EXAMPLE: type User struct { ID int; Name string } users := make(map[int]*User, 10) users[42] = &User{ID: 42, Name: "Bob"} if u, ok := users[42]; ok { u.Name = "Robert" }