Senior Go Backend Engineer

This profile represents the systems end of the backend pool: an engineer who reaches for Go when the service has to be fast, predictable, and easy to operate.

Background

Nine years in backend engineering, the last six almost entirely in Go. Has built the kind of services other services depend on: APIs, workers, and internal platforms in infrastructure and fintech companies. Fluent with gRPC for service contracts, Kubernetes as the runtime, and PostgreSQL when the data actually matters. Writes code reviewers thank them for.

What the work actually looks like

The day-to-day at this level is less about writing new endpoints and more about making systems trustworthy. Designing a worker pool that applies backpressure instead of falling over when a queue backs up. Hunting a goroutine leak that only shows under production load. Deciding what a service should do when its downstream dependency gets slow: time out, retry with a budget, shed load, or degrade, and making that decision explicit in code rather than leaving it to whatever the client library defaults to.

In fintech-style systems the work adds a correctness dimension. Money handling means idempotent operations, exactly-once semantics built honestly out of at-least-once delivery plus deduplication, and audit trails that survive crashes mid-transaction. An engineer like this has internalized that a payment system’s worst bug is not downtime, it is doing the same thing twice.

Strengths

• Idiomatic Go. Simple, explicit code with careful error handling and honest concurrency, not cleverness. Channels and goroutines where they clarify, plain mutexes where they suffice, and the race detector run in CI rather than after an incident.
• Service design. Draws boundaries with gRPC and protobuf so teams can move independently: versioned contracts, deadlines propagated through call chains, and streaming used only where request-response genuinely fails.
• Performance work. Profiles before optimizing, with pprof and real traffic rather than synthetic guesses, and knows where Go services actually spend their time: allocation churn, serialization, and waiting on the network, in roughly that order of surprise to newcomers.
• Operability. Ships services with metrics, tracing, structured logs, and graceful shutdown from day one, so the 3 a.m. page comes with enough context to act on.
• Data discipline. Treats PostgreSQL transactions and isolation levels as part of the service contract, not an ORM detail, which is exactly what fintech systems require.

Seniority signals

Nine years shows less in vocabulary than in restraint. A senior Go engineer keeps dependencies few and interfaces small, defines errors as part of the API rather than strings to grep for, and resists the microservice split until the team boundary genuinely demands it. They can explain what their service does during a deploy, a node failure, and a dependency brownout, because they decided each behavior on purpose.

What to probe in the interview

Ask how they would design a worker that consumes from a queue and writes to a database, then push on failure modes: duplicate delivery, poison messages, slow consumers. Ask about the last performance problem they solved and expect pprof output in the story, not intuition. Ask when they would advise against gRPC or against Go itself. Seniors at this level have real answers because they have paid for the alternatives.

Typical engagement

Full time on a core backend or platform team, often taking ownership of a critical service, leading a migration to Go, or hardening a system that has outgrown its first architecture. GMT hours, strong overlap with both Europe and the US East Coast morning. Available now.

This is a representative sample of the vetted pool. Request it and we confirm real, current availability for a developer with this background.