The Amazon coding assessment is one of the most talked-about hurdles in tech hiring — and for good reason. It's typically the first real filter between your application and an Amazon recruiter call, so how you perform here can make or break your shot at a software engineering role. If you've gotten the invite, you're not behind; you just need to know what to expect and how to prepare smart.
Amazon uses an online assessment platform (usually HackerRank) that delivers two coding challenges plus sometimes a work style survey. The whole thing takes about 90 minutes. That's tight. Knowing exactly what types of problems show up — and how Amazon thinks about them — is the starting point for any serious preparation.
Amazon's online assessment typically includes:
The coding problems are the part that trips people up. They're not beginner-level LeetCode easy — but they're not typically hard either. Most fall squarely in the medium difficulty range, which means you need solid fundamentals and decent problem-solving speed. You don't need to memorize exotic algorithms, but you do need to execute quickly under pressure.
Certain patterns appear repeatedly in Amazon's assessment pool. If you've done any study of technical interviews, these will look familiar:
Arrays and strings: Probably the most common category. Expect manipulation problems — subarray sums, two-pointer techniques, sliding window approaches. Sorting problems also show up frequently.
Hash maps and hash sets: Amazon loves problems that have an O(n²) brute force solution and an O(n) hash-based solution. If you're not reaching for a map immediately when you see a frequency-counting or lookup problem, practice that reflex.
Trees and binary search trees: Traversals (inorder, preorder, postorder), path problems, lowest common ancestor, and BST property validation. You need to be comfortable with recursive tree solutions and know when iteration is cleaner.
Graphs and BFS/DFS: Graph traversal problems — connected components, shortest paths in unweighted graphs, cycle detection. Amazon doesn't usually go heavy on Dijkstra's or complex graph theory, but basic BFS/DFS is fair game.
Dynamic programming (basic): Classic DP patterns like coin change, climbing stairs, and knapsack variants appear occasionally. You probably won't see anything that requires novel DP state design, but the standard patterns should be in your toolkit.
Linked lists: Reversal, cycle detection (Floyd's algorithm), merge sorted lists, find the kth node from the end. These show up less often than arrays but still make appearances.
90 minutes for two problems sounds generous until you're staring at a problem you've never seen and the clock is running. Here's how to use the time effectively:
Spend the first 5 minutes reading both problems before writing any code. Knowing what you're dealing with upfront lets you sequence your work — if one problem looks easier, knock it out first to bank a complete solution.
Once you start coding, don't aim for perfection immediately. Get a working solution first, even if it's not the most efficient approach. A brute-force solution that passes all test cases beats an elegant O(n log n) solution that has a bug. Amazon's automated scoring rewards correctness over sophistication.
After your first solution works, optimize if time permits. Look for the inefficiency in your approach — is there a data structure that makes the lookup faster? Can you eliminate a nested loop with a hash map?
If you hit a wall on a problem, move on. Coming back with fresh eyes often unlocks the approach. Spending 45 minutes on a single problem and leaving the second untouched is one of the more common assessment regrets.
Your solutions run against a set of test cases, and Amazon scores based on how many pass. This means a few things practically:
Edge cases matter a lot. Empty arrays, null inputs, single-element inputs, very large values — these are specifically designed to catch solutions that work on happy-path examples but miss boundary conditions. Before submitting, mentally run through what happens when the input is empty, when all values are equal, or when the answer is at the start or end of the array.
Efficiency matters but doesn't trump correctness. An O(n²) solution that passes all test cases is better than an O(n log n) solution that fails edge cases. Don't sacrifice correctness for elegance when time is short.
Amazon's test cases often include hidden cases beyond what's shown in the problem. The visible examples are the easy ones. Plan for the hard ones.
Many Amazon online assessments include a work style or behavioral survey alongside the coding problems. This isn't a throwaway section — Amazon takes its Leadership Principles seriously, and the behavioral data informs hiring decisions.
The survey typically presents scenarios and asks you to rate which response you'd most or least likely take. It's essentially a Likert-scale situational judgment test. You can't game it perfectly, but you can align your responses with principles Amazon values: customer obsession, bias for action, ownership, and earning trust.
Don't overthink each question. Respond as you genuinely would act in a work context, leaning toward the behaviors Amazon describes in its Leadership Principles. If you haven't read those 16 principles before your assessment, spend 20 minutes doing so — it gives you a useful frame.
Amazon's assessment platform supports most major languages: Python, Java, C++, JavaScript, Go, Ruby, and others. Pick the language you know best — this isn't the time to try something new. Speed matters, and you'll be fastest in the language where you don't have to think about syntax.
Python is popular for assessments because the standard library is rich and the syntax is concise. Java and C++ work well if you know them. The language choice itself doesn't factor into Amazon's scoring — what matters is that your solution is correct.
One practical note: HackerRank sometimes has issues with I/O if you're not using their built-in input methods correctly. Before diving into the logic of your solution, confirm that your input parsing works on the sample cases. This is a common source of mysterious failures that have nothing to do with your algorithm.
Smart preparation beats grinding 200 LeetCode problems randomly. Here's what actually moves the needle:
Start with patterns, not random problems. Learn the common patterns — sliding window, two pointers, fast/slow pointers, BFS/DFS templates, hash map frequency counting — and practice applying them to variations. One pattern mastered deeply is worth ten problems solved superficially.
Practice under time constraints. The ability to code accurately under a 45-minute clock is a skill you need to develop, not just assume you have. Set a timer when practicing. If you're regularly going over, your pace needs work.
Do Amazon-tagged problems on LeetCode. While the exact problems aren't public, the LeetCode Amazon tag gives you a strong approximation of the difficulty and style you'll encounter. Focus on medium-difficulty problems there.
Use Amazon assessment test questions and answers resources to familiarize yourself with the format, and review Amazon online assessment prep guides to understand how the platform works before test day.
Review your weak spots explicitly. Most people have predictable gaps — DP feels like magic, or tree recursion makes their brain fog. Attack those specific areas with targeted practice rather than reviewing things you already know.
Don't skip the behavioral portion. Read all 16 Amazon Leadership Principles and think of concrete examples from your experience that illustrate each one. The coding assessment is the online filter, but the interviews that follow are heavily behavioral. Setting up good thought patterns now pays off later.
If you pass, you'll typically hear from a recruiter within a week or two to set up a phone screen. If you don't hear back, you might not have passed, or the role may have closed — neither reflects a permanent judgment about your skills.
If you're rejected, you're usually eligible to apply again after six months. That window is enough time to meaningfully improve. A lot of engineers who end up at Amazon didn't make it through on the first try — the process is competitive, not designed to be easy.
The coding assessment is also just the beginning. If you pass, you'll face a phone screen and then an on-site (often virtual) loop of interviews that includes both technical and behavioral rounds. The preparation you do for the coding assessment — especially the pattern recognition and problem-solving speed — carries directly into those conversations.
Treat the assessment seriously, prepare systematically, and don't get rattled by difficulty. The problems are meant to be challenging, not impossible — and the difference between candidates who pass and those who don't usually comes down to preparation quality, not raw intelligence.