Emerger Tech: Golang Developer

• Jobs channel, N goroutines ranging over it, sync.WaitGroup, results/errors channel.
• Sender closes the jobs channel; workers exit on range end; a separate goroutine closes results after wg.Wait().
• select on ctx.Done() so cancellation stops in-flight work.
• Mentions backpressure (buffered vs unbuffered), how to pick N (I/O vs CPU bound), and testing with -race.

func run(ctx context.Context, jobs <-chan Job, n int) <-chan Result {
    out := make(chan Result)
    var wg sync.WaitGroup
    for i := 0; i < n; i++ {
        wg.Add(1)
        go func() {
            defer wg.Done()
            for j := range jobs {
                select {
                case out <- process(j):
                case <-ctx.Done():
                    return
                }
            }
        }()
    }
    go func() { wg.Wait(); close(out) }()
    return out
}

• Blocked on send/receive with no counterpart; missing ctx cancellation; HTTP calls without timeouts.
• Detect: rising runtime.NumGoroutine() metric, /debug/pprof/goroutine?debug=2 to see stacks; goleak in tests.
• Fix: every goroutine needs a defined exit path — usually ctx.Done().

• Channels for transferring ownership / coordinating work between goroutines; mutex for protecting shared state (a cache map, a counter).
• sync.RWMutex for read-heavy; sync/atomic for simple counters; sync.Once for lazy init.
• Strong answers avoid dogma: "share memory by communicating" is a guideline, a mutex around a map is often clearer.

• How it was measured (p95 before/after, which endpoint, what tool).
• The query problem: N+1? missing index? seq scan? Show you used EXPLAIN ANALYZE and what changed in the plan.
• Redis: what was cached, key design, TTL, invalidation on write, what happens on cache miss storm.
• The trade-off you accepted (staleness window). Prepare this with real numbers before the interview.

• pg_stat_statements to find it; EXPLAIN (ANALYZE, BUFFERS) to read it.
• Seq scan vs index scan, composite index column order, covering indexes (INCLUDE), partial indexes.
• Avoid SELECT *, functions on indexed columns, OFFSET pagination on big tables (use keyset).
• Go side: connection pool sizing (SetMaxOpenConns), N+1 from ORM loops, context timeouts on queries.

• Resource naming, correct verbs and status codes (201 + Location, 400, 404, 409, 422).
• Idempotency-Key header stored with the response so retries don't double-create.
• Cursor/keyset pagination, filtering, versioning (/v1), consistent error envelope.
• Auth (JWT — you've done this: validation, expiry, refresh), rate limiting, input validation at the edge.

• Wrap with context using %w; inspect with errors.Is/As; sentinel errors for domain cases (ErrNotFound).
• Map domain errors to HTTP status in one place (handler/middleware), not throughout services.
• Never leak internal error text to clients; log with request ID. No panics in request paths.

• Depend on small interfaces defined by the consumer; inject fakes/mocks (gomock or hand-written).
• Table-driven tests with t.Run; httptest.NewRecorder / httptest.NewServer for the third-party.
• For DB: real Postgres in a container (testcontainers) for integration tests rather than mocking SQL.
• -race, -cover, and testing error paths, not just happy paths.

• Never use the default http.Client (no timeout). Set client timeout + per-request context.WithTimeout.
• Retries with exponential backoff + jitter, only on idempotent operations; circuit breaker to fail fast.
• Always defer resp.Body.Close() and drain it so connections are reused.
• Metrics on latency/error rate of the dependency so you can prove it's them, not you.

• Aggregate in map[string]int64, then either sort (O(n log n)) or a min-heap of size K (O(n log K)).
• Implement container/heap correctly; handle ties and K > distinct merchants.
• Narrate complexity; mention money as integer minor units, not float64. (Your fintech background — use it.)

"That's right — three and a half years of Go, all in production at a fintech company, on top of about six years total. What I'd point to is the density: I've owned API design end to end, done the performance work on Postgres and Redis, and used Go's concurrency for a real async workflow. I'd rather you test me on depth than count months — happy to go deep on any of it."

Don't apologise, don't pad with PHP years. Then make sure your concurrency and SQL answers earn it.

"Not in production — I've deployed containerised services with Docker on Linux. I've labbed Kubernetes locally. For a Go service I'd make sure it has separate liveness and readiness endpoints, shuts down gracefully on SIGTERM, reads config from env, and has sensible resource limits; then a Deployment, a Service, and an HPA. The cluster-level operations I'd expect to learn from your DevOps team in the first few weeks."

"Not in production — our services talk REST through a gateway. I understand the model: Protobuf contracts, generated clients, HTTP/2, deadlines via context, interceptors for auth and logging. I've built a small server and client to get hands-on. Since the contract-first approach is close to how I already think about API design, I'd expect to be productive quickly."

"Neither in production. My database depth is PostgreSQL plus Redis — and in fintech we deliberately leaned on relational integrity and transactions. I understand when a document store fits better. On cloud, I've used basic AWS S3 and EC2; GCP I'd map across — Cloud SQL, GKE, Cloud Run — and learn on the job. If either is core to this team, I'd want to know so I can prioritise it before joining."