Core CS Roadmap

Purpose: prepare for core CS questions that may arise in an Amazon SDE Intern interview, especially while discussing your projects.
Last updated: 26 October 2026

Amazon lists object-oriented design as a student SDE core competency. An example India SDE Intern posting calls out object-oriented design, algorithm design, data structures, problem solving, and complexity analysis; relational databases appear in its preferred qualifications. A 2027 India intern posting also mentions AI tools and design patterns in its qualifications or responsibilities. Candidate accounts describe OOP and database questions, and some describe AI discussions. These are reasons to review the concepts, not evidence of a guaranteed core CS or AI round.

Keep the DSA roadmap, Leadership Principle stories, and project explanations as the main preparation. Use 20–30 minutes on most study days for this page. Give extra time to the technologies actually listed on your resume.

Priority mapCopy Anchor Link

The priority is a study recommendation based on the role description and candidate reports. It is not an Amazon interview syllabus.

1. OOP and basic designCopy Anchor Link

Cover: class vs object; encapsulation, abstraction, inheritance, polymorphism; interfaces; composition vs inheritance; coupling and cohesion; when to split responsibilities between classes or modules. Know one concrete example of each from a project. For an intern interview, a clear small design is more useful than memorizing a large catalog of design patterns.

Check yourself:

• Explain encapsulation and abstraction using a class or module you wrote.
• Describe a case where composition is easier to change than inheritance.
• Sketch classes or modules for a small task manager or library system; identify responsibilities and one extension.
• Explain the time and space complexity of a data structure used inside that design.

Design patterns and SOLID, tied to your codeCopy Anchor Link

Know the purpose and trade-off of a pattern you actually used: for example, Strategy for interchangeable algorithms, Factory for object creation, Adapter for an external API, or Repository for separating data access from business logic. Repository is an application architecture pattern, not one of the original GoF patterns. Be able to name the relevant classes or modules and explain why a simpler function would or would not have been enough.

Review the five SOLID ideas with one small example each:

Practice: pick one project, draw its main components, identify one pattern or principle it genuinely uses, and explain a design choice you would revise. You do not need to claim all five principles are present in every project.

Optional full-time-style design drill: sketch a cart that can add or remove items and compute a final price with several eligible discounts. Clarify whether discounts stack, their order, and rounding before choosing classes; a small Cart, PricingService, and interchangeable discount policies are enough to discuss responsibilities and tests. Alternatively, design parking allocation by vehicle size while tracking available spaces. These are extra exercises for explaining design choices, not expected intern rounds.

2. Databases and SQLCopy Anchor Link

Cover: tables, primary and foreign keys, one-to-many relationships, normalization at a practical level, SELECT/WHERE/GROUP BY, INNER JOIN vs LEFT JOIN, indexes and their read/write trade-off, transactions and ACID, and the idea of isolation when two requests update the same data. If you used a database, know why you chose it and how your important queries work.

Check yourself:

• Draw two related tables from a project and explain their keys.
• Write a query that joins them and counts rows per user or category.
• Explain which query an index would help, and why every column should not be indexed.
• Describe a multi-step update that should be in a transaction and what rollback would protect.

3. Operating systemsCopy Anchor Link

Cover: process vs thread; context switching; stack vs heap; virtual memory and paging at a high level; concurrency vs parallelism; race conditions, locks, and deadlocks. Link these ideas to a bug you have seen or could reproduce. Kernel implementation details are optional unless the role or your resume calls for them.

Check yourself:

• Explain what memory and state two threads in one process share.
• Give a two-request example that could cause a race condition.
• Explain how a lock could fix that race and how careless locking could deadlock.
• Describe what happens when a program needs more memory than physical RAM, at a high level.

4. Networks and web fundamentalsCopy Anchor Link

Cover: DNS, IP address and port, TCP connection, TLS for HTTPS, request/response, HTTP methods and status codes, statelessness, timeouts and retries, and caching. If you built APIs, know the route, validation, authentication or authorization check, database operation, response, and error path for one important endpoint.

Check yourself:

• Trace a browser request to your API from URL to response.
• Explain the difference between a network timeout and an HTTP 500 response.
• Explain why retrying a request that creates an order may duplicate it, and one way to prevent that.
• Describe what data HTTPS protects in transit and what it does not fix in application code.

5. Your language, Node.js, and project codeCopy Anchor Link

For your interview language, review collection types, equality and mutation, recursion limits, error handling, and the syntax you need for live coding. Follow the interview invitation's permitted-language instructions. The Node.js repository in your OA makes a short Node refresh useful, but it does not tell us which language the interview will use.

If you have used JavaScript/Node.js, cover the event loop at a high level; promises and async/await; how errors propagate; module imports; blocking CPU work vs asynchronous I/O; and how to run a test and trace a failing request through a repository.

Check yourself:

• Explain why an async function returns a promise and how a rejected promise reaches a caller.
• Explain why a slow synchronous loop can delay other Node.js requests.
• Walk through one bug: symptom, reproduction, files inspected, root cause, fix, and test.
• Explain one project choice you would change after learning more.

6. AI engineering if you used itCopy Anchor Link

Recent intern interview accounts describe questions about trust in AI and how candidates used it; another account describes conceptual GenAI questions tied to projects. If your resume names an AI feature, prepare a deeper explanation. If you only used an assistant for coding or debugging, explain that workflow and how you checked its suggestions.

For an LLM-backed product feature, cover:

• Use case and data flow: why a model was needed; what input, retrieval context, tools, and output it sees. For RAG, know how documents are retrieved, permission checked, and refreshed.
• Correctness: unsupported or fabricated claims, malformed JSON, and variable answers. Validate schemas and business rules in code, test representative cases, and define a fallback or human review for consequential failures.
• Operations: measure success on a small evaluation set, track errors and p95/p99 latency, limit token cost, and decide when to retry or fall back.
• Security and privacy: prevent sensitive data from reaching an unauthorized provider or user, and treat retrieved text and tool results as untrusted. OWASP documents prompt injection and recommends validation and least-privilege access; it also covers sensitive information disclosure.

Check yourself:

• Give one truthful AI use case from your own work and say what failed or could fail.
• Explain how you detect a wrong or malformed response before it reaches a user or downstream API.
• State one latency or cost trade-off and the measurement you would use.
• Explain why a prompt alone cannot enforce data access permissions.

If your resume calls for itCopy Anchor Link

Review Linux commands, cloud or deployment, queues and caching, and basic distributed-system trade-offs if they appear in your projects or job description. One recent candidate account describes a project deep dive of this sort. Do not substitute a senior system-design course for being able to explain your own code.

Ten short sessions, plus optional deep divesCopy Anchor Link

This can run alongside the six-week DSA plan. Each session is roughly 20–30 minutes. After the first two sessions, try five minutes of questions aloud without notes; use the answers to choose what to revisit. Repeat weak sessions rather than rushing through them.

Ready enough for the next topic: you can explain its main idea with an example from your own work and identify what you still do not know. Keep doing DSA mocks and behavioral practice while you fill those gaps; no need to finish this entire page first.

References for weak spotsCopy Anchor Link

• Amazon Student SDE roles and India SDE Intern posting — role competencies and qualifications.
• PostgreSQL tutorial and index introduction — SQL, keys, transactions, and index trade-offs.
• Operating Systems: Three Easy Pieces — processes, memory, and concurrency; select only the chapters you need.
• MDN: How the web works and HTTP overview — request flow and HTTP.
• Node.js event loop guide and Don't block the event loop — Node runtime behavior.
• Amazon 2027 India SDE Intern posting — AI tools and design patterns in an example role description.
• Amazon software development interview topics — broader SDE topic list; review concepts you can apply rather than memorizing terms.
• OWASP LLM prompt injection and sensitive information disclosure — security issues for LLM applications.