gRPC Interview Questions

Analogy categoryAnalogies

Fundamentals Interviewers Commonly Probe

A near-universal opening question is 'why choose gRPC over REST/JSON?' A strong answer covers three concrete pillars: Protocol Buffers give compact binary serialization and a strict schema contract enforced through .proto files, HTTP/2 provides multiplexed streams over a single connection eliminating head-of-line blocking at the connection level, and code generation produces strongly typed clients and servers across languages so API contracts are enforced by the compiler rather than by convention or documentation. Interviewers are usually listening for whether the candidate understands that these are trade-offs, not free wins, since gRPC's binary format is harder to inspect with a browser or plain curl, and it needs a proxy like grpc-web or Envoy to be called directly from browser JavaScript.

🏏

Cricket analogy: Explaining gRPC's trade-offs is like discussing why a team picks a specialist fast bowler for a pink-ball Test, real advantages in swing and pace, but a real cost in stamina management across a five-day match.

Deep-Dive Questions on Streaming and Errors

A frequent follow-up is to describe all four RPC types with a concrete use case for each: unary for simple request/response like a GetUser lookup, server-streaming for a large or continuous result set like tailing logs or downloading a report, client-streaming for uploading a large file or a batch of telemetry readings in chunks, and bidirectional streaming for real-time two-way interaction like a chat service or a live collaborative editing session. Strong candidates also know that gRPC errors use a status code plus a message, not HTTP status codes directly, and can name several codes correctly: NOT_FOUND, INVALID_ARGUMENT, PERMISSION_DENIED, UNAVAILABLE, DEADLINE_EXCEEDED, and explain that structured error details can be attached via google.rpc.Status and the errdetails package rather than just a plain string message.

🏏

Cricket analogy: Describing the four RPC types is like categorizing cricket deliveries, a single unary yorker for one clean outcome, versus a rain-delayed session that streams updates continuously like a server-streaming rain-interruption commentary feed.

// A commonly asked follow-up: how do you return a rich error from a gRPC handler?
import (
	"google.golang.org/grpc/codes"
	"google.golang.org/grpc/status"
)

func (s *orderServer) GetOrder(ctx context.Context, req *pb.OrderRequest) (*pb.Order, error) {
	if req.Id == "" {
		return nil, status.Error(codes.InvalidArgument, "order id is required")
	}
	order, found := s.lookup(req.Id)
	if !found {
		return nil, status.Errorf(codes.NotFound, "order %s not found", req.Id)
	}
	return order, nil
}

A question that separates junior from senior candidates: 'How do you handle backward compatibility when evolving a .proto schema?' The expected answer covers never reusing or renumbering existing field numbers, always adding new fields as optional (proto3's implicit optional semantics), using reserved to block accidental reuse of removed field numbers/names, and preferring new RPC methods over breaking changes to an existing method's request or response shape.

Be ready to justify gRPC over REST with concrete pillars: Protobuf, HTTP/2 multiplexing, and generated strongly typed clients.
Know all four RPC types cold with a realistic use case for each: unary, server-streaming, client-streaming, bidirectional.
gRPC errors use status codes (e.g. NOT_FOUND, INVALID_ARGUMENT, DEADLINE_EXCEEDED) plus a message, not raw HTTP status codes.
Structured error detail attachment via google.rpc.Status/errdetails is a strong signal of depth beyond basic usage.
Schema evolution rules (never reuse field numbers, use reserved, additive-only changes) are a common senior-level question.
Be able to explain gRPC's real trade-offs, not just benefits: harder browser access, needs grpc-web/Envoy, less human-readable on the wire.
Practical questions often probe channel reuse, deadlines/context propagation, and interceptor use for cross-cutting concerns like auth and logging.