Packages And Imports
Fast recall
Quick revision
Core answer
Whether you understand Packages And Imports 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
The mechanics, executed:
// package example.com/mymod/db — the path
package db // the package NAME — what callers say
func Query() { ... }Importing:
import "example.com/mymod/db"
// now: db.Query()The two identities: the import PATH (example.com/mymod/db — module path + subdirectory, unique) and the package NAME (db — the package clause, what you reference). They usually match (the convention), but an import can alias: import mydb "example.com/mymod/db" — now mydb.Query().
The rules: one package clause per directory (all files in a dir are one package); the package name is the identifier (short, lowercase); imports are per-file (you import what each file uses); the main package is the binary entry point (func main).
The visibility coupling: imported = the package sees only EXPORTED identifiers (the topic's uppercase rule). The import itself must be USED — an unused import is a compile error (Go's strictness — no accidental dead imports).
The structure pattern:
mymod/
go.mod
main.go (package main)
users/ (package users)
users.go
users_test.go
db/ (package db)
postgres.goPackages And Imports
Direct Answer
A package is a directory of .go files sharing a package clause. Imports resolve to package paths (module-path + subdirectory). The package name (the clause) is what you call; the import path is how you find it.
Deep Dive & Architecture
The import resolution: the path is module-path-relative — example.com/mymod/db means the db directory under the module root (example.com/mymod in go.mod). The go tool maps path → filesystem → the directory's package, loading its compiled form (or compiling it).
The cycle rule: package A imports B, B imports A — a compile error. Go has no cycle tolerance (unlike some languages). The fix is extraction: the shared dependency moves to C (A→C, B→C, no cycle). This shapes architecture: cycles indicate conflation — the extraction is the discipline that keeps packages single-purpose.
The _ and . imports: _ "pkg" — the blank import (for side effects: driver registrations like _ "modernc.org/sqlite" — the init runs, the name isn't used). . "pkg" — the dot import (everything in the current namespace — test-only, the practice from the earliest Go tests; now rare and frowned upon outside tests).
The vendor directory: the module-aware build can read dependencies from ./vendor instead of the cache — vendoring for hermetic builds. go mod vendor creates it; -mod=vendor uses it. The complete-module-in-your-repo approach for maximum reproducibility.
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 Packages And Imports in a real project?
- How would you compare Packages And Imports with an alternative?
- What is a common mistake when using Packages And Imports?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.