Common pointers mistakes
Fast recall
Quick revision
Core answer
*p or p.Field can panic. Check optional pointers at boundaries, return useful errors with nil results, use value semantics by default for small data, and choose one receiver style consistently for a type.Name a concrete pointers mistake, show its visible effect, and explain how to prevent and test it.
Saying only “be careful” without tracing the incorrect behaviour.
Show the smallest failing example and the regression test that protects the rule.
Interview-ready guide
Interview answer
A pointer stores the address of another value.
&valueobtains an address and*pointerreads or changes the value at that address; a pointer's zero value isnil. Pointers let a function or method modify shared state and can avoid copying a large value. Go does not support pointer arithmetic, and taking an address is memory-safe because escape analysis keeps the value alive when required.The common mistake is dereferencing a nil pointer or using a pointer when ordinary value semantics would be simpler. A nil pointer has no value behind it, so
*porp.Fieldcan panic. For example: IffindUserreturns(*User)(nil)and the caller immediately readsuser.Name, the program panics. The caller must check the error and pointer before use.A pointer does not automatically make code faster. Allocation, garbage collection, aliasing, and cache behaviour matter, so small structs are often clearer and efficient as values. This is why the surrounding data contract matters as much as the syntax.
Check optional pointers at boundaries, return useful errors with nil results, use value semantics by default for small data, and choose one receiver style consistently for a type. Test a valid pointer, an explicit nil pointer, a missing lookup, and whether mutations should or should not be visible to the caller.
Common pointers mistakes
Direct Answer
The common mistake is dereferencing a nil pointer or using a pointer when ordinary value semantics would be simpler. A nil pointer has no value behind it, so *p or p.Field can panic. Check optional pointers at boundaries, return useful errors with nil results, use value semantics by default for small data, and choose one receiver style consistently for a type.
Deep Dive & Architecture
For a nil-pointer panic, start at the dereference in the stack trace and move backward to the assignment or function return that produced nil.
Check constructor results, map lookups that return pointer values, optional request fields, interface values that may hold typed nil pointers, and concurrent mutation.
Test a valid pointer, an explicit nil pointer, a missing lookup, and whether mutations should or should not be visible to the caller.
The common mistake is dereferencing a nil pointer or using a pointer when ordinary value semantics would be simpler. A nil pointer has no value behind it, so *p or p.Field can panic. Check optional pointers at boundaries, return useful errors with nil results, use value semantics by default for small data, and choose one receiver style consistently for a type.
Code Example
user, err := findUser(id)
if err != nil { return err }
if user == nil { return ErrNotFound }
return printName(user.Name)
Common Mistakes & Pitfalls
Saying only “be careful” without tracing the incorrect behaviour.
Check your understanding
Answer these without looking back at the article.
- What are pointers in Go, and how do they work?
- How do pointers compare with a value in Go?
- When should you use pointers in Go?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.