Go Practice Questions: Types, Errors, and Concurrency

These are original Go programming exercises. They are not collected interview reports, a statement about a particular employer, or a salary guide. The public Go documentation provides the technical guidance used as the basis for language details; consult the documentation for the toolchain version you use when runtime behaviour matters. The page does not claim a hiring trend, a question frequency, a candidate outcome, or an employer process.

Make a small type boundary explicit

Design a function that accepts a text value and returns a normalised identifier. Decide which inputs are valid, how an invalid input is reported, and whether an empty value differs from whitespace. Write a caller that handles the error instead of silently continuing.

The key practice is to name the contract. A reader should be able to tell what the function promises, what it refuses, and what the caller must do next. If you use a custom type, explain what mistake it prevents compared with passing a generic string everywhere.

Separate a value from its ownership

Consider a function that receives a slice and removes duplicate entries. Explain whether it should mutate the supplied slice or return a new one. Demonstrate the consequence of the choice with a small test. Then describe how you would document the behaviour so a caller does not accidentally rely on a side effect.

This question is less about reciting implementation details than about choosing an interface whose behaviour is easy to verify. A small test table can show ordinary input, an empty input, and repeated values.

Build an error path deliberately

Imagine reading a configuration file that may be missing, malformed, or valid but incomplete. Sketch a function that distinguishes those cases and returns enough context for the caller to decide whether to retry, stop, or use a documented default. Avoid converting every error into the same message.

In a review, ask whether an error has been wrapped with the operation that failed and whether the caller has a meaningful decision to make. The goal is diagnosable behaviour, not an artificially cheerful success path.

Coordinate work before introducing concurrency

Take a task that transforms independent records. First write the sequential version and test it. Then identify the shared state that would make concurrent processing unsafe. If you add a worker and a channel, explain who closes the channel, how cancellation is observed, and how a failure reaches the caller.

Do not use concurrency as decoration. It should serve a measurable requirement or make a clear boundary safer. If no requirement exists, the simple version may be easier to maintain.

Read code for invisible assumptions

Choose a short Go function and ask whether a zero value is meaningful, whether a nil map can be written to, and whether an exported identifier describes its own contract. Add a focused test for the most surprising case. This review habit helps uncover assumptions before they become a production incident.