REST vs GraphQL for Placement Portfolios: Which API Design Pattern Impresses Startup Interviewers More?

A candidate lists "GraphQL" on their resume. The interviewer's first question: "Why did you choose GraphQL over REST for this project?" The wrong answer: "Because GraphQL is modern and REST is old." This answer reveals that the candidate chose a technology for signaling reasons, not architectural reasons. The right answer names a specific data-fetching problem that REST caused and GraphQL solved: "My dashboard screen needed data from 4 different API endpoints — user profile, recent orders, notifications, and recommendations. With REST, the client made 4 sequential requests, each adding 200-400ms of latency. With GraphQL, I query all 4 data types in a single request, and the client only receives the fields it needs for the dashboard — name, last 5 orders, unread notification count, top 3 recommendations." This answer demonstrates that the candidate identified a real problem, evaluated a solution, and implemented it. That is the engineering mindset that startup interviewers hire for.

The REST Implementation That Actually Impresses

A tutorial-quality REST API is a list of endpoints that all return 200 with varying JSON shapes. An interview-ready REST API demonstrates five specific design decisions that signal production API experience. Consistent error format: every error response has the same structure — { "error": { "code": "VALIDATION_ERROR", "message": "Email is required", "details": [{ "field": "email", "issue": "missing" }] } } — regardless of whether the error is a validation failure, authentication error, or server crash. The client can write one error handler instead of parsing a dozen different error shapes. Proper HTTP status codes: 200 for success, 201 for resource creation with a Location header pointing to the new resource, 400 for validation errors, 401 for missing authentication, 403 for insufficient permissions, 404 for missing resources, 409 for conflicts (duplicate email), 422 for semantic validation failures, 429 for rate limiting, 500 for unexpected server errors. Using these codes correctly tells the interviewer you understand HTTP as a protocol, not just as a transport. Pagination with a consistent envelope: every list endpoint wraps results in { "data": [...], "pagination": { "page": 1, "pageSize": 20, "total": 147, "totalPages": 8 } } so the client knows exactly how many pages exist without fetching them all. Input validation at the API boundary: every endpoint validates its input before processing and returns 400 with field-level error messages. This prevents invalid data from reaching your business logic and tells the interviewer you think about API security at the boundary. Rate limiting: a basic rate limiter using express-rate-limit or a custom middleware that returns 429 with a Retry-After header. A rate-limited API signals that you understand production API concerns — abuse prevention, fair usage, and server resource protection.

When GraphQL Is the Right Choice — and How to Implement It Correctly

If your project genuinely benefits from GraphQL (not because it sounds impressive, but because you can describe a specific REST limitation that GraphQL addresses), here is what separates a tutorial GraphQL implementation from an interview-ready one. Query complexity limits: without limits, a client can request deeply nested data that triggers thousands of database queries. Add a query complexity analyzer (graphql-query-complexity or Apollo's built-in validation) and set a maximum complexity score. Explain in your README: "I set a query complexity limit of 1000 because the nested orders → items → product query can trigger N+1 database problems at depth. This prevents abusive queries while allowing legitimate dashboard-style queries." Field-level authorization: not all fields should be visible to all users. An admin can see user email addresses; a regular user cannot. Implement this at the resolver level. DataLoader for N+1 prevention: GraphQL's resolver-per-field model creates the same N+1 problem that REST APIs face. Use DataLoader to batch and cache database queries. This is the single most important GraphQL optimization — a GraphQL API without DataLoader is slower than an equivalent REST API, and an interviewer who knows GraphQL will specifically ask about N+1 handling.