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.
Practice what you learned
1. When asked to justify choosing gRPC over REST/JSON in an interview, which three pillars form the strongest answer?
2. Which RPC type is the best fit for uploading a batch of telemetry readings in chunks before receiving one final acknowledgment?
3. How does gRPC represent errors, distinct from plain HTTP status codes?
4. What rule about .proto field numbers is essential for safe schema evolution?
5. Why can't a browser directly call a gRPC service the way it calls a REST API?
Was this page helpful?
You May Also Like
gRPC Quick Reference
A condensed cheat sheet of gRPC RPC types, status codes, .proto syntax essentials, and CLI/tooling commands for fast lookup.
Testing gRPC Services
Strategies and tools for unit testing, integration testing, and manually exercising gRPC services, including grpcurl, in-process servers, and mocking generated clients.
gRPC Performance Considerations
Key factors that determine gRPC throughput and latency: connection reuse, message size, streaming versus unary trade-offs, and serialization overhead.
Related Reading
Related Study Notes in Web Development
Browse all study notesWebSockets Study Notes
Web Development · 30 topics
Web DevelopmentWebAssembly Study Notes
WebAssembly · 30 topics
Web DevelopmentSpring Boot Study Notes
Java · 30 topics
Web DevelopmentFlask Study Notes
Python · 30 topics
Web DevelopmentDjango Study Notes
Python · 30 topics
Web DevelopmentNext.js Study Notes
JavaScript · 30 topics