API Developer Interview Questions for AI Training Work

I model resources around the actual domain concepts the API represents rather than around the underlying database tables, since those don't always map one to one and exposing database structure directly tends to create an API that's confusing to consume. I keep naming consistent and predictable so consumers can infer endpoints they haven't seen yet.

I enforce authentication and authorization checks at every endpoint rather than assuming a gateway-level check covers everything, validate and sanitize all input server side regardless of client-side validation, and make sure sensitive data is encrypted in transit and not overexposed in response payloads beyond what the consumer actually needs.

I introduce a new version rather than changing behavior under the existing version, giving consumers a clear migration path and a deprecation timeline for the old version, rather than breaking existing integrations without warning. I document exactly what changed and why.

I profile the request path to find where time is actually being spent, since assumptions about the bottleneck are often wrong, and a slow endpoint is frequently caused by an inefficient database query or an unnecessary synchronous call rather than the application logic itself. I fix the actual bottleneck rather than optimizing code that isn't the real cause.

I default to cursor-based pagination for large or frequently changing datasets, since offset-based pagination can produce inconsistent results when data changes between requests, and I add filtering so consumers can request only what they need rather than pulling the full dataset and filtering client side. Rate limiting protects the API from both accidental and abusive overuse.

I'd fix the authorization check immediately and treat it as a priority security issue rather than a normal bug, assess what data may have already been exposed, and communicate the issue to whoever owns security or incident response so the exposure can be properly evaluated, rather than quietly patching it without escalation.

I'd check whether a query that used to be fast is now scanning a much larger dataset without adequate indexing, since that's a common cause of performance degrading as volume grows even when the code hasn't changed. I'd add the missing index or restructure the query, and consider caching or pagination if the underlying data volume itself is the real driver.

I'd design endpoints that let consumers request only the fields they need, through field selection or separate lightweight and detailed endpoints, rather than returning a single fixed payload shape for every consumer. That avoids forcing the bandwidth-constrained client to pay the cost of data it doesn't use.

I found that an endpoint was returning more fields in its response than the consuming client actually needed, including some internal fields that shouldn't have been exposed externally. I trimmed the response to only what was necessary and audited other endpoints for the same pattern, since it turned out to be a recurring oversight rather than a one-off issue.

An endpoint needed a performance improvement that would have required a much more complex caching layer for a relatively modest gain. I opted for a simpler optimization, like adding a targeted index, that got most of the benefit without the added complexity, since the more elaborate solution wasn't worth the maintenance burden for the actual performance gain.