Designing an API for power vs novice personas

WHAT THIS TESTS The interviewer wants to see that a persona is an input to design, not a slogan. A senior engineer should map proficiency and goals onto concrete choices in the API surface, the documentation style, and the error contract.

A GOOD ANSWER COVERS For the power user, prioritize granular control, batch and asynchronous endpoints, filtering and pagination, idempotency keys, fine-grained scopes, and machine-readable errors carrying stable codes and field-level detail for programmatic handling. Provide complete reference docs, an OpenAPI spec, and SDKs. For the novice, prioritize sensible defaults, convenience or higher-level endpoints that bundle common flows, strong guardrails and validation, and human-readable error messages that suggest the fix. Provide tutorials, quickstarts, and copy-paste examples. Then call out the shared backbone: consistent naming, predictable status codes, and a clear versioning policy benefit everyone.

COMMON WRONG ANSWERS Claiming a single design fits all consumers. Stripping power features to keep it simple, which alienates the integrators who drive depth. Or over-engineering for power users so the novice cannot get a first success. Treating documentation as one monolithic style instead of layering reference and tutorial content.

LIKELY FOLLOW-UPS How do you serve both personas without forking the API? How should error responses differ for human versus machine consumers? When do convenience endpoints become a maintenance liability?

ONE CONCRETE EXAMPLE A payments API can expose low-level charge and refund primitives with idempotency keys and coded errors for power users, while also offering a hosted checkout flow and a quickstart that gets a novice to a first successful test charge in minutes. Both consume the same core, the errors share one schema, and each persona reaches their goal through the layer suited to them.