How does GraphQL differ from REST?
Assesses fundamental understanding of GraphQL conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
GraphQL exposes a single endpoint and a typed schema rather than many resource URLs. The client sends a query describing exactly the fields it needs, so it avoids the over-fetching and under-fetching typical of fixed REST payloads. One request can traverse relationships that would take several REST round trips.
query {
user(id: 42) { name orders(last: 3) { total } }
}
Trade-offs: HTTP caching is harder because everything is usually a POST to /graphql; the server must defend against expensive or malicious queries; and file uploads, long-running jobs and simple CRUD often map more directly to REST. REST also has richer tooling for status codes and content negotiation.
In practice GraphQL suits product UIs with varied data needs, while REST remains strong for public, cacheable, resource-oriented APIs. Many teams use both.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.