Loading...
A practical coaching guide for Amazon SDE I university hire candidates — covering OA, phone screen, onsite loops, Leadership Principles, and exactly what interviewers look for at each stage.
If you're applying for Amazon's Software Development Engineer I (SDE I) role through the University Talent Acquisition pipeline, you're entering one of the most structured — and most learnable — interview processes in the industry. I've coached dozens of new grad candidates through this exact process, and here's the truth: Amazon's interview is very predictable once you understand the framework. Let's break it all down.
Here's the order you should expect:
For university hires specifically, the loop is usually virtual (not in-person), and the system design component is scoped way down compared to SDE II or senior levels. Don't underestimate the LP rounds though — they are weighted just as heavily as coding for this role.
The OA is typically hosted on HackerRank or a similar platform. You'll get 2 coding problems and around 70–90 minutes to solve them. For university hires, expect:
Some OAs also include a work simulation or work style survey — answer these authentically, they're screening for cultural fit signals early.
At this stage, Amazon's automated system is checking: Can you write correct, working code? Do you pass edge cases? Do you handle performance reasonably?
A strong submission completes both problems fully, handles edge cases (empty input, single element, large inputs), and passes most or all test cases.
A weak submission only handles the happy path or times out on large inputs due to a brute-force approach.
Spend 2–3 weeks on LeetCode focusing on the Amazon tagged problems. Aim for fluency in:
Here's the type of problem you might see — a classic sliding window:
# Longest substring without repeating characters
# Amazon OA-style medium problem
def length_of_longest_substring(s: str) -> int:
char_index = {}
left = 0
max_len = 0
for right, char in enumerate(s):
# If we've seen this char and it's inside our current window
if char in char_index and char_index[char] >= left:
left = char_index[char] + 1
char_index[char] = right
max_len = max(max_len, right - left + 1)
return max_len
# Edge cases to always check:
Practice saying your thought process out loud even on OA prep — it builds the muscle for the real interviews.
One Amazon engineer, one coding problem, 45–60 minutes. The format is usually a shared coding environment (like CodePair or CoderPad). At the SDE I level, expect a medium LeetCode-style problem, often with a follow-up twist.
Here's what most candidates miss: the phone screen isn't just about getting the right answer. The interviewer is checking if you can think out loud, communicate trade-offs, and handle feedback. They want to see your process, not just your solution.
Strong signal: You clarify the problem before coding, state your approach and complexity, write clean code, then test it yourself.
Weak signal: You dive straight into coding silently, produce working code, but can't explain why you made certain choices.
Here's a script you can adapt:
"Before I start coding, let me make sure I understand the problem correctly. So we have [restate the problem in your own words]. A few clarifying questions — can the input be empty? Can values be negative? Is there a memory constraint I should be aware of?"
"My initial approach would be a brute force O(n²) solution — I'd do [brief explanation]. But I think we can do better. If I use a hashmap to track [X], I can bring this down to O(n) time and O(n) space. Does that trade-off sound reasonable to you?"
"Let me code that up and then I'll walk through a couple of test cases to verify."
This kind of structured narration makes interviewers confident in you, even if you hit a bug.
Prepare for these by always asking yourself these questions before the interviewer does.
This is the main event. Each interview is 45–60 minutes and every single one will include both a coding/technical component AND Leadership Principles (LP) questions. Yes, both. In the same round. Budget your time accordingly.
Expect medium to medium-hard problems. Topics to be solid on:
| Topic | Likely Problem Type |
|---|---|
| Arrays / Strings | Two pointers, sliding window, prefix sums |
| Trees | BFS, DFS, LCA, path problems |
| Graphs | Connected components, shortest path (Dijkstra, BFS) |
| Dynamic Programming | 1D/2D DP, knapsack variants |
| Design-light | Design a simple class (e.g., LRU Cache) |
Here's a classic tree problem that shows up in Amazon loops:
# Find the lowest common ancestor of two nodes in a BST
# Demonstrates tree traversal + BST property knowledge
class TreeNode:
def __init__(self, val=0, left=None, right=None):
self.val = val
self.left = left
self.right = right
def lowest_common_ancestor(root: TreeNode, p: TreeNode, q: TreeNode) -> TreeNode:
# In a BST, if both p and q are less than root, go left
# If both are greater, go right
# Otherwise, root is the LCA
if p.val < root.val and q.val
After writing this, a good interviewer will ask: "What if this wasn't a BST?" Have the general binary tree solution ready (post-order DFS). Knowing the follow-up before they ask it is a strong signal.
At the SDE I / new grad level, Amazon doesn't expect you to design distributed systems at scale. What they do expect:
You might get something like: "Design a URL shortener" or "Design a simple notification system." Focus on requirements clarification first, then data model, then API, then scale considerations at the end.
Red flag: Jumping straight to microservices and Kubernetes for a simple problem. Show you can think proportionally.
This is where Amazon is genuinely different from other companies. Amazon's 14 Leadership Principles (LPs) aren't just wall art — they are the actual hiring rubric. Every behavioral answer you give is scored against specific LPs.
The LPs most commonly probed for SDE I university hires:
Use the STAR format (Situation, Task, Action, Result) but dial up the Action part — Amazon wants to see your specific contribution, not what "we" did as a team.
"Sure, let me tell you about a time I demonstrated [LP]. The situation was [1-2 sentences of context — keep it tight]. My specific task was [what you were responsible for]. Here's what I did: [detailed breakdown of your actions — this is the meat, spend 60-70% of your time here]. The result was [quantified outcome if possible — numbers are gold]."
Prepare 8–10 strong STAR stories from your internships, projects, coursework, or extracurriculars. Each story should be adaptable to multiple LPs. Map each story to 2–3 LPs before your interview.
In every Amazon loop, one interviewer is designated the Bar Raiser — an experienced Amazonian from a different team, specially trained to assess whether you raise the overall bar for Amazon hires. They have veto power in the debrief.
Don't try to "win" against the Bar Raiser. Just be consistent, authentic, and specific. The Bar Raiser is looking for candidates who demonstrate genuine growth potential, intellectual honesty, and ownership. Candidates who try to oversell themselves get spotted immediately.
A common trap: When they push back on your answer, candidates either cave completely ("yeah, you're right, I should have done X") or get defensive. The right move is to acknowledge the nuance while standing by your reasoning: "That's a fair point — in hindsight, I might have communicated earlier. That said, given the constraints at the time, I still think the approach was reasonable because..."
| Week | Focus Area |
|---|---|
| 1–2 | LeetCode Easy/Medium grind — core data structures |
| 3–4 | Medium/Hard problems + Amazon-tagged LeetCode list |
| 5 | LP story bank — write 8–10 STAR stories, map to LPs |
| 6 | Mock interviews (coding + behavioral) — use Pramp or a partner |
| 7 | System design basics (for SDE I scope) + OA practice |
| 8 | Full mock loops, review weak spots, rest before interviews |
Practice resources:
Here's what to remember when you walk into (or log into) your Amazon SDE I loop:
Amazon's process is tough, but it's also one of the most predictable in the industry once you learn the framework. Put in the structured prep time, practice your LP stories until they feel natural (not rehearsed), and keep your coding fundamentals sharp. You've got this.