Design Patterns (GoF and modern) Module 9
Patterns in standard libraries interview questions
Interview questions on patterns in standard libraries: short warm-ups, then what each harder question tests, the first step of a good answer and its follow-ups.
Warm-up questions
Short questions with short answers, each answered in full.
-
Fresher to mid
Which design patterns does Go's io package use? Give two examples.
The io package is built on two one-method interfaces, io.Reader and io.Writer, so a value that wraps a reader or a writer can itself be one. That makes most of the package decorators: bufio.NewReader adds buffering to any reader, io.LimitReader stops a reader after n bytes, io.TeeReader copies everything it reads into a writer, and gzip.NewWriter compresses on its way to another writer. io.MultiWriter is a composite: it writes each buffer to several writers and looks like one writer to its caller. Because every piece speaks the same interface, they combine in any order, and a type of your own joins a chain by writing a single method.
From the lesson Patterns inside the Go standard library
Questions with model answers
What each question tests, the first step of a good answer and the follow-ups to expect.
-
Mid to senior
A Go service streams server-sent events. After a logging middleware was added, clients receive the events only when the handler returns. Explain why, fix the middleware, and say how you keep the other optional methods of the response writer working.
- What it tests
- How embedding an interface hides methods, optional interfaces in net/http, ResponseController and Unwrap, and testing middleware with streaming responses.
- First step
- Look at how the middleware wraps the response writer, and at how the handler flushes: a type assertion to http.Flusher or a ResponseController. Then check which methods the wrapper's type actually has.
- Follow-ups
-
- Why not add a Flush method to the wrapper and stop there?
- Which other optional methods can a wrapper hide?
- How would you test that the middleware streams?
From the lesson Patterns inside the Go standard library
Model answer, Pro. Model answers open with any pass; prices are in the notice on this page.Opening the model answers with your pass…
Model answers open with any MySmartCoPilot pass.
- Pro pass · 1 week₹79$2.99
- 30 days₹179$5.99
- 1 year₹1,699$45
One payment; nothing renews unless you choose to. The price shown is the total you pay: no fees or charges are added at checkout.
Passes can’t be bought right now, so the model answers can’t be opened at the moment. If you have a pass, enter your licence key.
It also opens every other in-depth part in Learn and every Pro tool. Sales are final, except where the law gives you a right to withdraw, for example in the EU and the UK (refund policy).
In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Senior to staff
Design the errors of a Go payments package so that callers can tell a declined card, a provider timeout and an invalid request apart, and still see the underlying cause. What do you export, and how do callers check for each?
- What it tests
- Sentinel errors, error types, wrapping with %w, errors.Is and errors.As, and which details become part of a package's API.
- First step
- List what callers need to decide, such as retry, show a message or fix their input, and give each decision one exported error value or type. Then decide which underlying errors you wrap with %w and which you keep private.
- Follow-ups
-
- When is a sentinel error enough, and when do callers need an error type?
- Should a provider timeout match context.DeadlineExceeded?
- What breaks for callers if you later stop wrapping the provider's error?
From the lesson Patterns inside the Go standard library
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
-
Mid to senior
A Go service creates its database client lazily with sync.OnceValues on first use. One morning the database was down for a minute while the service started, and the service kept failing for hours after the database came back. Why, and how would you fix it?
- What it tests
- The failure semantics of sync.Once, OnceValue and OnceValues, lazy initialisation that can be retried, and how database/sql connects.
- First step
- Check what the one-time function returned the first time it ran, and what sync.OnceValues returns on later calls. Then compare it with when database/sql actually opens connections.
- Follow-ups
-
- Would sync.Once with a package variable behave any better?
- Write initialisation that retries after a failure but never runs twice at once.
- Does this client need lazy initialisation at all?
From the lesson Patterns inside the Go standard library
Model answer, Pro.In the answer:
- Model answer
- Follow-up answers
- Common mistakes
- Rubric
- Variants
- about 3 minutes
All Design Patterns (GoF and modern) interview questions · The Design Patterns (GoF and modern) track