# Expedia SDE-2 Interview Experience — DSA Wins, Password Manager LLD Lessons Expedia Interview ## Overview A Bugfree user shared a high-score interview experience for Expedia SDE-2 (Bengaluru). Candidate profile: ~3 years of experience, interviewed via referral. The on-site/process had four rounds in total (note: no HLD round for SDE-2). The final two rounds were scheduled only after clearing the first two. Quick summary of rounds: - R1 (DSA): 2 problems — a string problem and a sliding-window problem. - R2 (DSA): A rod-cutting DP variant and a tree problem; got positive feedback. - R3 (LLD): Design a password manager (create/edit/forgot flows), token generation, password policies. Used SOLID principles and patterns (Singleton / Strategy / Observer), but feedback was weak. - R4 (Manager): Deep resume dive plus scenario questions on distributed systems. Outcome: Rejected. The stated reason: weaker LLD feedback. Key lesson: strong DSA is necessary but not sufficient — end-to-end clarity in low-level design matters. --- ## What happened in each round (details & takeaways) ### Round 1 — DSA - Problems: one string problem and one sliding-window problem. - Takeaway: Classic pattern recognition (sliding window) and careful implementation win here. Focus on clean code and test edge cases. ### Round 2 — DSA - Problems: rod-cutting dynamic programming variant and a tree problem. - Outcome: Received positive feedback. DP and tree fundamentals were handled well. - Takeaway: Practice variants of standard DP problems and common tree traversals/transformations. ### Round 3 — Low-Level Design (LLD) - Prompt: Design a password manager supporting create, edit, forgot-password flows; design token generation and password policy enforcement. - Approach used: Applied SOLID principles and patterns (Singleton, Strategy for policies, Observer for notifications). However, feedback suggested the design lacked clarity or end-to-end completeness. - Likely gaps: API contracts, data models, token lifecycle/expiry, encryption/storage details, failure modes, scaling considerations, and clear flow diagrams. - Takeaway: In LLD you must be explicit and cover the whole flow — request/response shapes, database schema, sample APIs, edge cases, and how components interact in failure scenarios. ### Round 4 — Manager Round - Focus: Deep resume walkthrough and scenario-based questions (distributed systems, tradeoffs, operational concerns). - Takeaway: Be ready to justify design decisions, discuss tradeoffs, and show ownership and impact from your prior work. --- ## Why the rejection (and what to improve) The candidate performed well on algorithmic rounds but the LLD round lacked the end-to-end clarity interviewers expect. For SDE-2, interviewers want to see: - Clear API design and contracts (request/response examples) - Concrete data model and schema decisions (tables/fields, indexes) - Security considerations (encryption at rest/in transit, token structure) - Token lifecycle: generation, storage, validation, expiry, revocation - Error handling and edge cases (concurrent edits, rate limits) - Component interactions and sequence flows (how requests move across services) - Reasoned tradeoffs and complexity estimates In short: DSA correctness helps you get to later rounds, but LLD communication and completeness often decide the outcome. --- ## Actionable prep checklist - DSA - Practice sliding window, DP variants, and tree problems. - Write correct, testable code; narrate complexity and edge cases. - LLD - Practice end-to-end designs for small services: auth, payments, notifications, password management. - Always draw a sequence diagram or step-by-step flow. - Define APIs (example request/response), DB schema, and important indexes. - Explain security: hashing, salting, encryption, token format (JWT vs opaque), refresh/revocation. - Discuss failure modes, scaling (caching, sharding), and monitoring/alerts. - Use SOLID and design patterns where they add clarity, but avoid overusing patterns for their own sake. - Manager/Behavioral - Prepare a concise resume walkthrough: technical decisions, tradeoffs, measurable outcomes. - Expect scenario questions on system reliability, scaling, and team processes. --- ## Example checklist for the Password Manager LLD 1. Scope: create/edit/forgot-password flows, token generation & validation, password policy enforcement. 2. APIs: POST /users, PUT /users/{id}/password, POST /auth/forgot, POST /auth/reset 3. Data model: Users table (id, email, password_hash, salt, reset_token, reset_expiry, created_at) 4. Security: bcrypt/argon2 for hashing, TLS in transit, encrypt sensitive fields at rest. 5. Token: use opaque reset tokens stored server-side (or signed JWT with short expiry + revocation list). 6. Flow: diagram the forgot -> send token -> validate token -> reset password -> invalidate token. 7. Edge cases: multiple reset requests, token reuse, expired tokens, brute-force protection, rate limiting. 8. Observability: logs (no plaintext secrets), metrics on reset attempts, alerts on spikes. --- ## Final takeaway Cracking DSA problems is essential to move forward, but for SDE-2 roles you must pair algorithmic strength with crisp, end-to-end low-level design communication. Practice small-service LLDs with concrete APIs, data models, token flows, and failure scenarios — and narrate them clearly during the interview. Good luck — focus on clarity and completeness for LLD, and the rest will fall into place. #SoftwareEngineering #InterviewPrep #SystemDesign