Interview: the final checklist
The last pass before the call — what to revise, what to say, and what to ask them.
Topic 98 of 98 · 5 min to read · 45 min to build
After this topic you can
- Revise the short list of topics that come up most often.
- Answer a question you do not know by reasoning aloud from what you do know.
- Prepare questions to ask the interviewer about the team and the codebase.
How to use this last topic
This is the pass to make in the day or two before an interview. It is not new material. It is the short list of what is worth revising, how to handle a question you cannot answer, and what to ask them at the end.
The most useful part is the summary table near the bottom: one line per area, covering the whole track. Cover the right column and see how much of it you can reconstruct.
The night before: revise only these
- Zero values, and which types are nil-able.
- Slices — header,
appendreturning, shared backing arrays. - Maps — missing key returns zero, random order, nil map write panics, not concurrency-safe.
- Interfaces — implicit, small, nil-interface trap, accept interfaces/return structs, method sets.
- Errors —
%w,errors.Is,errors.As, handle once. - Goroutines — cost, leaks, the channel table, mutex vs channel.
- Context — first param,
defer cancel(), only a signal you must check, not for dependencies. - defer — function scope, args evaluated now, named returns.
go test -race,GOMEMLIMIT,GOMAXPROCS.
Note: Do not learn anything new the night before. Revising what you already half-know converts far more of it into answers than a new topic does, and it stops you second-guessing yourself mid-sentence.
How to answer anything you do not know
- Say so, immediately, then reason. "I have not used that. I would expect it to work like X because of Y — is that close?" That sounds honest and thoughtful. Bluffing sounds like neither, and interviewers usually notice.
- Never guess a confident wrong answer. One of those can undo several good ones.
- If you half-remember, say which half: "I know it changed in 1.22, I am not certain of the exact semantics."
Sentences worth having ready
- "That trade-off cost me X, and here is when I would switch."
- "I would measure before optimising — my guess would be the database, not the Go code."
- "I would not add an interface until there is a second implementation."
- "Errors are values, so I wrap with context and handle each one exactly once."
- "Every goroutine I start needs a documented way to exit."
- "The simplest thing that works, until a measurement says otherwise."
Questions worth asking them
- "How is the Go code laid out — by domain or by layer?" Their answer tells you a lot about the codebase you would inherit.
- "Do you run the race detector in CI?" A “no” means concurrency bugs are being found in production.
- "What does your on-call look like, and what usually breaks?"
- "Where does the team disagree about Go style, and how is that settled?"
- "What would my first three months look like?"
The whole track, in one screen
| Area | The one thing |
|---|---|
| Types | every type has a zero value; conversions are always explicit |
| Slices | a window onto an array — two windows see each other’s writes |
| Maps | missing key gives zero; order is random; nil map write panics |
| Strings | bytes, not characters; immutable, so += in a loop is O(n²) |
| Pointers | no arithmetic, no dangling, no manual free — just mutation and cheap passing |
| Structs | assignment copies; embedding is composition, not inheritance |
| Interfaces | implicit, small, defined where used; typed nil is not nil |
| Errors | values you return; wrap with %w; handle exactly once |
| Panic | broken assumptions only; never crosses a goroutine boundary |
| Goroutines | cheap to start, expensive to forget — every one needs an exit |
| Channels | sender closes; nil blocks; send on closed panics |
| Sync | mutex guards state, channels transfer ownership; -race in CI |
| Context | first parameter, defer cancel(), check Done() in anything blocking |
| HTTP | set your own timeouts; a handler is one function shape |
| Database | a pool, always bounded; placeholders always; watch for N+1 |
| Auth | bcrypt, short JWT, hashed rotating refresh, scope in the SQL |
| Production | GOMEMLIMIT, GOMAXPROCS, structured logs, measure before optimising |
Worth knowing: You have built a real API with authentication, a database, file uploads, tests and a container. Talk about that project concretely, with its costs, rather than reciting definitions. It is the strongest material you have.
The short version
- Revise the nine mechanics above and nothing new the night before.
- "I do not know, but I would expect X because Y" beats a confident wrong answer.
- Have five questions ready — what you ask says as much as what you answer.
- Talk about your project concretely, with the costs of each decision.
Remember: They are deciding whether they want to read your code for the next two years. Clear beats clever, and honest beats confident.
Build this before moving on
Take the mixed MCQ test. Anything you get wrong, reread that topic and write the answer in your own words before moving on.Then try these in your own editor
- 1Cover the right column of the summary table and reconstruct it from the left.
- 2Record yourself describing your project for three minutes, then listen back and cut a third.
- 3Write out the five questions you will ask them, and pick which two you will use if there is only time for two.
Official documentation