Questions
2 of 10
How does the select statement work with multiple channels, including a default case?
Difficulty: 5/10
select statement, channel multiplexing, default case
select blocks until one of its cases can proceed, choosing randomly when multiple are ready. A default case makes it non-blocking, executing immediately if no channel is ready.
select patterns
Important behaviors
- 1
When multiple cases are ready, select picks one uniformly at random — no priority ordering
- 2
Nil channels are never ready — use this to dynamically disable a case
- 3
time.After creates a new timer and channel on every call — use time.NewTimer in loops to avoid leaks
- 4
default makes select non-blocking — runs immediately if no channel is ready
- 5
select with only a default case and no channels is a spin loop — avoid
Scenario Questions
0-2 years experience
- 1Suppose you have two goroutine workers sending results on channels ch1 and ch2. How would you use a select with a default case to try to receive from either channel without blocking the main goroutine?
- 2If you write a select with cases for ch <- val and a default, what happens when the channel is full? Explain the behavior.
2-5 years experience
- 1You added a select with multiple channel reads to a service that aggregates data, but sometimes the request hangs. Walk me through how you'd debug why the select isn't proceeding.
- 2When integrating a timeout using time.After in a select alongside two data channels, how do you decide the order of cases and why might moving the default case affect latency?
5-8 years experience
- 1In a high‑throughput pipeline you need to fan‑out work to several workers and also handle back‑pressure. How would you design the select logic, including default or non‑blocking sends, to avoid deadlocks and maintain throughput?
- 2Explain the trade‑offs of using a default case in a select that polls multiple channels versus using separate goroutine per channel in a large‑scale service. How does it impact CPU usage and fairness?
8+ years experience
- 1Your team is refactoring a legacy system that uses many blocking selects with default cases scattered across modules. What architectural guidelines would you set to standardize channel multiplexing and avoid hidden contention across services?
- 2If you need to migrate a Go microservice that heavily relies on select with default to an event‑driven architecture using a message broker, how would you map the select semantics to broker subscriptions while preserving non‑blocking behavior?
Follow-up Questions
- What happens if more than one channel is ready at the same time?
- Can you guarantee the order in which cases are selected?
- How does the presence of a default affect fairness among channel operations?