---
title: gRPC Interview Questions and Answers (2026)
description: Real gRPC interview questions — protobuf schema evolution, the four RPC types, HTTP/2, deadlines and gRPC vs REST — with code and a prep plan.
url: https://usegreenroom.app/blog/grpc-interview-questions
last_updated: 2026-07-31
---
← Back to blog
Backend
# gRPC interview questions and answers
July 31, 2026 · 12 min read
"Someone removed a deprecated field from the proto and renumbered the rest to tidy it up," the interviewer said. "What happens?" The candidate said the schema was cleaner now. It was. It was also completely incompatible with every service still running the old build, because protobuf serialises by field number, and every one of them had just changed meaning.
gRPC interview questions concentrate on that kind of thing — the contract, and what breaks when it changes. gRPC is the default for internal service-to-service communication at scale, so backend and platform loops ask about it constantly. This guide covers protobuf and schema evolution, the four RPC types, what HTTP/2 buys you, deadlines and errors, and the gRPC-versus-REST question.
## What gRPC interviews actually test
- Protobuf — the wire format, field numbers, and backward compatibility rules.
- The four RPC types — unary, server streaming, client streaming, bidirectional.
- The transport — HTTP/2 multiplexing, and why that matters versus HTTP/1.1.
- Reliability — deadlines, cancellation, status codes, retries.
- Tradeoffs — gRPC vs REST vs GraphQL, and browser limitations.
The five bands of gRPC interview questions, with schema evolution the most common source of real incidents.
## Protocol buffers and the rules that actually matter
gRPC uses Protocol Buffers as its interface definition language and wire format. You define messages and services in a .proto file and generate client and server code for every supported language. The result is a strongly typed contract that is compact and fast to parse — a binary format rather than JSON text.
```
syntax = "proto3";
package orders.v1;
message Order {
string id = 1;
string customer_id = 2;
int64 amount_paise = 3;
// Field 4 was 'legacy_status'. NEVER reuse the number.
reserved 4;
reserved "legacy_status";
string status = 5;
}
service OrderService {
rpc GetOrder(GetOrderRequest) returns (Order);
rpc WatchOrders(WatchRequest) returns (stream Order);
}
```
The compatibility rules, which is what the intro's question was testing:
- Field numbers are the identity. Names are for humans; the wire format carries numbers. Renaming a field is safe on the wire; renumbering is catastrophic.
- Never reuse a retired field number — use reserved to make the compiler enforce it. An old client will happily decode the new field as the old one and get silent corruption rather than an error.
- Adding a field is backward compatible. Old readers ignore unknown fields.
- Removing a field is acceptable only if you reserve the number.
- Changing a type is usually not safe — some conversions are wire-compatible (int32/int64/bool share a varint encoding) but most silently corrupt.
- proto3 default values are indistinguishable from unset for scalars, which is why optional (reintroduced) or wrapper types matter when you need to tell "zero" from "not provided". This is a favourite follow-up.
Also expect "why binary rather than JSON?" — smaller payloads, much faster parsing, and a schema that makes breaking changes detectable at build time. The cost is that you cannot read it with curl, which is a real ergonomic loss and worth conceding honestly.
## The four RPC types
- Unary — one request, one response. The normal case, and functionally similar to a REST call.
- Server streaming — one request, a stream of responses. Live price feeds, tailing logs, large result sets delivered incrementally rather than in one enormous message.
- Client streaming — a stream of requests, one response. File uploads in chunks, batched telemetry.
- Bidirectional streaming — both sides stream independently over one connection. Chat, real-time collaboration, long-lived sync.
A good practical point to volunteer: streaming is also how you avoid gRPC's default message size limit (commonly 4MB) — you chunk rather than raise the cap. And bidirectional streaming is not request-response with extra steps; the two streams are genuinely independent, so ordering between them is your responsibility.
## HTTP/2, and what it actually buys
gRPC runs on HTTP/2, and the properties that matter:
- Multiplexing — many concurrent requests over one TCP connection, so you avoid HTTP/1.1's head-of-line blocking at the application layer and the cost of a connection pool.
- Binary framing — cheaper to parse than text headers.
- Header compression (HPACK) — significant when you make many small calls with repetitive metadata.
- Server push and full-duplex streams — what makes the streaming modes possible at all.
The honest caveat, and interviewers like it: HTTP/2 multiplexing does not remove TCP-level head-of-line blocking, since a lost packet still stalls every stream on that connection. And a single long-lived connection interacts awkwardly with L4 load balancers, which is why gRPC usually needs L7-aware load balancing or client-side balancing — a common real-world gotcha and a strong thing to raise. Our Kubernetes interview questions guide covers the service-mesh layer that usually solves it.
## Deadlines, cancellation and error handling
This band separates people who have run gRPC in production.
Deadlines, not timeouts. A gRPC deadline is an absolute point in time propagated across the whole call chain — if service A sets a 2-second deadline and calls B, which calls C, they all share the same expiry. That is what prevents a slow leaf service from tying up resources all the way up the stack. The interview-worthy statement: always set a deadline; the default is effectively infinite, and unbounded calls are how cascading failures start.
Cancellation propagates — if the client disconnects, downstream services learn the context is cancelled and can stop work, which is a genuine advantage over naive REST chains.
On errors, know that gRPC uses its own status codes rather than HTTP ones, and the distinctions that matter for retries: UNAVAILABLE (transient, safe to retry), DEADLINE_EXCEEDED (retry only if idempotent — the work may have completed), RESOURCE_EXHAUSTED (back off), FAILED_PRECONDITION vs ABORTED (the latter implies retrying at a higher level may help), and INVALID_ARGUMENT (never retry; the request is wrong). Being able to say which codes are retryable and why is a strong senior answer.
## gRPC vs REST vs GraphQL
Asked in every loop. Frame it by use case rather than declaring a winner:
- gRPC — internal service-to-service, high call volume, polyglot services needing a strict contract, streaming requirements, low latency. The generated clients and schema enforcement are the real wins at scale.
- REST — public APIs, third-party consumers, browser clients, anything that benefits from being debuggable with curl and cacheable by standard HTTP infrastructure.
- GraphQL — client-driven data fetching where varied consumers need different shapes of the same data, particularly mobile clients avoiding over-fetching.
The browser point is important and often missed: browsers cannot speak native gRPC, because the required control over HTTP/2 frames is not exposed to JavaScript. You need gRPC-Web with a proxy such as Envoy, and gRPC-Web does not support client or bidirectional streaming. That single limitation is why most public-facing APIs stay REST or GraphQL while the internal mesh runs gRPC. Our GraphQL interview questions guide and REST API guide cover the alternatives, and the microservices guide covers where this fits architecturally.
## The docs, Buf, ChatGPT — where each fits
- The official gRPC and Protocol Buffers documentation — the proto3 language guide and the compatibility rules page answer most interview questions directly.
- Buf — modern protobuf tooling with breaking-change detection. Naming it is a strong signal, because it is the practical answer to the intro's incident.
- Building a service in two languages — highest yield. Generate a Go server and a Python client from the same proto; the value of the shared contract becomes obvious immediately.
- grpcurl and grpcui — the debugging tools that partly replace curl. Worth knowing they exist, since interviewers ask how you debug a binary protocol.
- Deliberately breaking a schema — renumber a field and watch an old client misread data. You will never forget the rule afterwards.
- ChatGPT — good for generating protos and explaining status codes. It will not ask what happens to the running services when the numbers change.
- Greenroom — the spoken layer. Ari, the AI interviewer, runs the round out loud and pushes the compatibility and failure follow-ups. Fair tradeoff: Ari will not generate your stubs.
> The core truth: gRPC interviews are contract interviews. Field numbers are the contract, deadlines are the contract with time, and status codes are the contract with failure — get those three right and the rest of the round is straightforward.
## How to prepare for a gRPC interview
- Week 1: protobuf. Write protos, generate code, and rehearse the compatibility rules — especially reserved fields and proto3 default semantics.
- Week 2: the four RPC types. Implement all four, including a bidirectional stream, and explain when each is appropriate.
- Week 3: reliability. Set deadlines across a three-service chain, cancel a call mid-flight, and map status codes to retry decisions.
- Final week: rehearse the gRPC-versus-REST comparison including the browser limitation, then run two full spoken mocks.
Building the rest of the stack? The microservices guide covers the architecture, the WebSocket guide covers the other real-time transport, the Kafka guide covers async messaging, and the Go guide covers the language gRPC is most associated with.
## Frequently asked questions
### What are the most common gRPC interview questions?
The most common questions cover how protocol buffers serialise data and why field numbers rather than names are the contract, the rules for backward-compatible schema changes including reserved fields, the four RPC types and when to use streaming, what HTTP/2 multiplexing provides over HTTP/1.1, how deadlines propagate across a call chain, which gRPC status codes are safe to retry, and how gRPC compares with REST and GraphQL.
### Why can you never reuse a protobuf field number?
Protocol buffers serialise by field number rather than field name, so the number is the actual contract on the wire. If you retire field 4 and later assign that number to a different field, any service still running older generated code will decode the new data as the old field, producing silent data corruption rather than a clear error. Use the reserved keyword for both the number and the old name so the compiler enforces it.
### What are the four types of gRPC calls?
Unary is one request and one response, which is the common case and resembles a REST call. Server streaming sends one request and receives a stream of responses, suiting live feeds or large incremental result sets. Client streaming sends a stream of requests and receives one response, suiting chunked uploads or batched telemetry. Bidirectional streaming has both sides streaming independently over one connection, suiting chat and real-time sync.
### What is a gRPC deadline and why does it matter?
A deadline is an absolute point in time by which a call must complete, and gRPC propagates it across the entire call chain, so a service and everything it calls downstream share the same expiry. This prevents a slow leaf service from holding resources open all the way up the stack. The default is effectively infinite, so you should always set one — unbounded calls are a common cause of cascading failures.
### Can browsers use gRPC directly?
No. Native gRPC requires control over HTTP/2 frames that browsers do not expose to JavaScript. Browser clients use gRPC-Web, which needs a translating proxy such as Envoy, and gRPC-Web does not support client streaming or bidirectional streaming. This limitation is the main reason most public-facing APIs remain REST or GraphQL while internal service-to-service communication uses gRPC.
### When should you use gRPC instead of REST?
Use gRPC for internal service-to-service communication, especially with high call volumes, polyglot services that benefit from a strictly enforced generated contract, streaming requirements, or tight latency budgets. Use REST for public APIs, third-party consumers and browser clients, where being debuggable with curl and cacheable by standard HTTP infrastructure matters more than payload size and parsing speed.
gRPC rounds turn on the contract and what breaks when it changes. Greenroom runs mock backend and system design interviews with Ari — compatibility and failure follow-ups included — and scores structure and clarity. Free to start. Curious how it works? See how AI mock interviews work.