Golang engineer interview questions

As asked

You are designing a Rust library API that accepts user data, transforms it, and returns a result. When would you take ownership, borrow immutably, borrow mutably, or accept Cow?

Sample answer outline

A strong answer starts from the caller contract, not from syntax. Borrow immutably when the function only needs to read data and should not force allocation or transfer of lifetime responsibility. Borrow mutably when the function must update caller-owned state and exclusive access is part of the API contract. Take ownership when the callee must store, move across threads, or consume the value. Cow is useful when most calls can borrow but a minority need normalisation or copying. Candidates often trip by cloning to satisfy the compiler instead of redesigning ownership so the data flow is explicit.

Reference implementation (rust)

use std::borrow::Cow;

fn normalise_name(input: Cow<'_, str>) -> Cow<'_, str> {
    if input.chars().any(|c| c.is_uppercase()) {
        Cow::Owned(input.to_lowercase())
    } else {
        input
    }
}

Expect these follow-ups

• How would your choice change if the value is stored in a background worker?
• When is Clone an acceptable API requirement?
• How do lifetimes appear in the public signature and what does that communicate?

As asked

A Go service slowly grows from 200 goroutines to 50,000 during normal traffic. Walk me through how you would diagnose and fix the leak.

Sample answer outline

Start with evidence: runtime metrics, pprof goroutine dumps and stack traces grouped by blocked call site. Common causes are sends to channels nobody receives from, receives on channels nobody closes, missing context cancellation and background tickers that are never stopped. The fix should remove the lifecycle ambiguity, usually by passing context.Context through the call chain, closing owned channels exactly once, and stopping tickers or timers. The candidate should also discuss regression protection with load tests or a goroutine-count assertion around the failing path. Interviewers look for ownership of goroutine lifetimes, not just knowing pprof commands.

Expect these follow-ups

• How do you decide which side owns closing a channel?
• What does a goroutine blocked on select usually tell you?
• How would you expose goroutine growth as an alert?

As asked

You are designing an orders topic with 50,000 events per second. How do you choose the partition key, and what can go wrong?

Sample answer outline

The partition key controls ordering, load distribution and consumer parallelism, so it should match the ordering requirement first. If all events for an order must be processed in sequence, orderId is a natural key; if customer-level ordering matters, customerId may be required but can create hot partitions. The number of partitions should allow enough consumer parallelism without creating unnecessary broker overhead. The answer should discuss skew, key cardinality, compaction needs and future repartitioning pain. Candidates often say random keys for balance while missing that this destroys per-entity ordering.

Expect these follow-ups

• How would you detect a hot partition in production?
• What happens to ordering when you increase partition count?
• When would you split one logical stream across multiple topics?

As asked

Explain Send and Sync. How do they affect a Rust service that shares state between async tasks and worker threads?

Sample answer outline

Send means a value can be moved to another thread, while Sync means references to a value can be shared between threads. Most plain data structures get these auto traits when their fields are also Send or Sync, but Rc, RefCell, raw pointers and FFI handles need care. In async code, a future spawned onto a multi-threaded runtime usually must be Send because it may resume on a different worker. Shared mutable state typically needs Arc plus Mutex, RwLock, atomics, or a message-passing design. The interviewer wants to hear that thread safety is encoded in types, but not magically solved if blocking locks or poor contention choices are used.

Expect these follow-ups

• Why is Rc not Send or Sync, and why is Arc different?
• What happens if a non-Send value is held across an await?
• When would you choose channels over Arc<Mutex<T>>?

As asked

Design a Go API client method that respects request deadlines, cancellation and cleanup. What mistakes do you avoid?

Sample answer outline

The method should accept context.Context as the first parameter and pass it into network, database or RPC calls rather than inventing a separate timeout mechanism. It should not store context in a struct for long-lived reuse, and it should always call cancel for derived contexts to release timers. Cleanup should happen even on cancellation, but expensive retries should stop when ctx.Done is closed. Strong candidates mention distinguishing context.Canceled from context.DeadlineExceeded in logs and metrics. The common failure is to create a timeout but then call an API that ignores it.

Reference implementation (go)

func FetchUser(ctx context.Context, client *http.Client, baseURL, id string) (*User, error) {
	ctx, cancel := context.WithTimeout(ctx, 2*time.Second)
	defer cancel()

	req, err := http.NewRequestWithContext(ctx, http.MethodGet, baseURL+"/users/"+id, nil)
	if err != nil {
		return nil, err
	}

	resp, err := client.Do(req)
	if err != nil {
		return nil, err
	}
	defer resp.Body.Close()

	if resp.StatusCode != http.StatusOK {
		return nil, fmt.Errorf("fetch user: status %d", resp.StatusCode)
	}

	var user User
	if err := json.NewDecoder(resp.Body).Decode(&user); err != nil {
		return nil, err
	}
	return &user, nil
}

Expect these follow-ups

• When should a library create a child timeout versus trusting the caller's deadline?
• How do you test cancellation deterministically?
• What should be logged when the client disconnects?

As asked

How do you decide where to define interfaces in Go, and why do experienced Go teams prefer small consumer-owned interfaces?

Sample answer outline

In Go, interfaces are satisfied implicitly, so the consumer can define the behaviour it needs without forcing producers into a shared abstraction. Small interfaces such as io.Reader or a one-method Store make tests and substitutions easy while keeping production types concrete. Defining large provider-owned interfaces too early creates brittle mocks and hides useful methods behind an artificial surface. The candidate should connect this to package boundaries and dependency direction. A strong answer also says when no interface is needed because a concrete type is clearer.

Expect these follow-ups

• When is a provider-owned interface justified?
• How do generics change this decision, if at all?
• What is the smell in an interface with ten methods?