Server-Side Developer Interview Questions for AI Training Work

I model endpoints around the resource itself and use nested routes or query parameters for relationships, rather than creating a tangle of endpoints that mirror every possible relationship combination. I keep the API predictable so consumers can reason about it without needing detailed documentation for every edge case.

I centralize error handling through middleware rather than scattering try-catch blocks with inconsistent responses across routes, and I return structured error responses with consistent status codes and messages so client applications can handle failures predictably.

I denormalize selectively where read performance genuinely matters and the data doesn't change often, since normalized data is easier to maintain consistently but can create expensive joins at scale. I avoid denormalizing prematurely before actual performance data shows it's needed.

I move CPU-intensive work off the main event loop, either through worker threads or an offloaded background job, since a blocking operation in Node.js stalls every other request being handled at that moment. I profile to confirm where the actual bottleneck is before restructuring code around it.

I introduce the breaking change under a new version while keeping the previous version running for a defined deprecation window, rather than forcing all consumers to update immediately. I communicate the deprecation timeline clearly so downstream teams have time to migrate.

I'd check the database query behind the endpoint first, looking for a missing index or a query that's scanning more rows than necessary as the table has grown, since that's a common cause of gradual slowdown that wasn't apparent at smaller scale. I'd also check for N+1 query patterns that only become visible at higher volume.

I'd identify the specific shared resource being accessed concurrently and use appropriate locking or transactional guarantees at the database level, rather than trying to patch it with application-level workarounds that don't actually eliminate the race condition. I'd write a test that reproduces the concurrency scenario to confirm the fix actually holds.

I'd design the core resource endpoints to be general-purpose rather than tailoring them to one client's exact needs, and use query parameters for filtering or field selection where the clients genuinely need different data shapes. I'd avoid building separate endpoints per client unless the divergence is significant enough to justify the added maintenance.

A service started returning intermittent errors after a deployment, and the logs weren't immediately clear on the cause. I added targeted logging around the suspected area, reproduced the issue in a staging environment, and traced it to an unhandled promise rejection that only surfaced under a specific input pattern.

An early schema stored a frequently changing status as a free-text field rather than a constrained set of values, which caused inconsistent data once multiple developers were writing to it. I migrated it to an enum-backed column with validation, which took some coordination but eliminated a recurring source of bugs.