Design speaking scenarios and auth/profile API
Company: Speak
Role: Software Engineer
Category: System Design
Difficulty: hard
Interview Round: Onsite
Part A — Design a speaking-scenario practice feature for a language-learning app (e.g., Speak):
- Functional scope: Let users browse/search/select any real-life scenario (e.g., ordering coffee, job interview), receive prompts, speak responses, and get real-time feedback and a score. Include progress tracking and the ability to resume sessions.
- Architecture: Propose services/components (content service, session/orchestration, speech-to-text, LLM feedback, scoring, personalization, analytics), their APIs, and data flow.
- Data model: Define schemas for Scenario, Turn/Prompt, UserSession, Attempt, and UserProgress. Describe indexing for fast scenario discovery and session retrieval.
- LLM/ASR integration: Choose ASR and feedback generation models. Describe prompt strategy, guardrails, latency targets, token/cost budgets, and fallback behavior when models fail or rate-limit.
- Personalization: How would you adapt difficulty, vocabulary, or pace per user? What signals and features would you log?
- Scale and reliability: Estimate QPS, concurrency, and storage growth. Propose caching, streaming, and backpressure. Handle timeouts, retries, idempotency, and partial failures.
- Safety & compliance: Content moderation, PII handling, data retention, privacy controls, and localization. Describe offline/poor-network considerations.
- Experimentation & metrics: Define success metrics (learning outcomes, engagement), guardrails, and how you’d A/B test variations of prompts/feedback.
Part B — Design an MVP API for user authentication and profile management:
- Endpoints: Register (email+password), Authenticate (login), Retrieve profile, Update profile, Delete account. Specify request/response shapes and status codes.
- AuthN/Z: Choose session vs. JWT, token TTL/refresh, and secure cookie vs. header usage. Describe password hashing (can be mocked) and account lifecycle.
- Storage: Use in-memory data structures for users, sessions/tokens, and profiles. Define keys and concurrency handling.
- Non-functionals: Rate limiting, input validation, error handling, idempotency for register/delete, logging, and minimal observability.
- Constraints: MVP first, edge cases later; AI tools allowed; optimize for development velocity while maintaining clear, usable APIs.
- Evaluation: Explain trade-offs, data modeling decisions, and how you would evolve this into a production-ready service.
Quick Answer: This question evaluates a candidate's ability to design scalable, real-time speaking-practice features and a minimal authentication/profile API, encompassing system architecture, service decomposition, data modeling, ASR/LLM integration, personalization, security and privacy, and operational concerns like scaling and observability.