Interview experience
American Express Interview Questions and Answers (2026)
Overview
Section titled “Overview”American Express’s fresher hiring is a straightforward 3-4 stage loop anchored by a Codility-based online assessment, with technical rounds leaning on OOP and low-level design more than pure algorithmic depth.
American Express interview process at a glance
Section titled “American Express interview process at a glance”| Round | Duration | What they test |
|---|---|---|
| Online Assessment | ~90 min | 3 coding questions (medium-hard) on Codility |
| Technical Interview 1 | 45-60 min | DSA, OOP concepts, low-level design |
| Technical Interview 2 / Manager Round | 45-60 min | Deeper technical + behavioral mix |
| HR Round | 20-30 min | Motivation, team fit, logistics |
Online Assessment
Section titled “Online Assessment”A roughly 90-minute Codility test with 3 coding questions at medium-to-hard difficulty. Codility’s grading weighs code quality and edge-case handling alongside raw correctness, unlike a simple pass/fail judge.
Common questions
- Array and string manipulation problems
- Basic data-structure implementation (stacks, queues) under time pressure
- Edge-case-heavy variants where partial test cases matter for your score
Technical Interview 1
Section titled “Technical Interview 1”Mixes core DSA with OOP fundamentals and a lightweight low-level-design prompt - expect to both write code and reason about class/schema structure in the same round.
Common questions
- Implement or reason about a linked-list or queue-based data structure
- Core OOP concepts - inheritance, polymorphism, interfaces vs abstract classes
- Design a small system or database schema (e.g. a simple rewards or transaction-logging system)
Technical Interview 2 / Manager Round
Section titled “Technical Interview 2 / Manager Round”A deeper technical round that often blends into a hiring-manager conversation - some candidates report this stage merging with HR, reducing the total to 3 rounds instead of 4.
Common questions
- Follow-up depth on your Technical Interview 1 answers
- Project walkthrough - architecture decisions and trade-offs
- Behavioural questions mixed with technical ones (team fit, ownership)
Round-by-round narratives are on the American Express interview experience page.
HR Round
Section titled “HR Round”A closing 20-30 minute conversation on motivation, team preference, and logistics.
Common questions
- Tell me about yourself, and why American Express?
- Which team or role would you prefer, and why?
- Describe a time you had to be extremely careful about accuracy under pressure
- Strengths and weaknesses
Sample answer frameworks for each of these are on the American Express HR interview questions page.
Common technical interview questions and answers
Section titled “Common technical interview questions and answers”Q: How do you implement a queue using two stacks?
Keep an input stack and an output stack. Enqueue always pushes onto the input stack, which is O(1). Dequeue checks the output stack: if it is empty, pop every element from the input stack and push it onto the output stack, which reverses the order so the oldest element ends up on top, then pop from the output stack. If the output stack is not empty, just pop it. Each element is moved at most twice across its lifetime, once in and once across, so dequeue is amortised O(1) even though a single dequeue can cost O(n). The mistake to avoid is transferring back and forth on every operation, which makes it O(n) per call. Total space is O(n), and peek follows the same lazy-transfer rule as dequeue.
Q: How do you design a stack that returns its minimum in O(1)?
Keep a second stack of minima alongside the main stack. On push, push the value onto the main stack and push the smaller of the new value and the current top of the min stack onto the min stack, so the min stack’s top is always the minimum of everything currently in the structure. On pop, pop both stacks together. getMin then just reads the top of the min stack. All operations are O(1) time and the structure uses O(n) extra space. If the interviewer pushes for O(1) extra space, the trick is to store an encoded value when a new minimum arrives, pushing 2 * newValue - oldMin, and to decode the previous minimum on pop; that works but risks overflow, which is worth calling out before you write it.
Q: How do you merge two sorted linked lists?
Create a dummy head node and a tail pointer starting at it, then walk both lists together: compare the two current nodes, splice the smaller one onto the tail, advance that list, and advance the tail. When one list runs out, attach the remainder of the other in a single step rather than continuing node by node. Return dummy.next. It is O(m + n) time and O(1) extra space, because you are relinking existing nodes rather than allocating new ones. The dummy node is what removes the awkward special case for choosing the first head. If instead you are merging k sorted lists, push the head of each onto a min-heap and repeatedly pop the smallest and push its successor, which is O(N log k) time for N total nodes.
Q: What is the difference between an interface and an abstract class?
An abstract class can hold state through instance fields, constructors, and any mix of concrete and abstract methods, and a class can extend exactly one of them. An interface historically declared only method signatures and public static final constants; since Java 8 it can also carry default and static method bodies, and since Java 9 private helpers, but it still cannot hold instance state, and a class can implement many interfaces. The design rule is that an abstract class expresses an is-a relationship with shared implementation, such as an abstract Transaction base carrying an amount, timestamp, and a shared audit method, whereas an interface expresses a capability that unrelated types can offer, such as Refundable or Auditable. Prefer interfaces when you want to keep the type hierarchy flexible, since single inheritance of classes is a hard constraint, and reach for an abstract class only when subclasses genuinely need to share fields or constructor logic.
Q: How would you design a database schema for a card transactions and rewards system?
Start with the core entities: customers, cards, merchants, transactions, and reward ledger entries. A cards table holds a card ID, its customer ID as a foreign key, a product or tier code, status, and a token rather than the actual card number, since raw card numbers should never sit in an application database. Transactions hold a transaction ID, card ID, merchant ID, an amount stored as a decimal type rather than a float, a currency code, a timestamp, a status such as authorised, settled, or reversed, and an idempotency key so a retried request cannot post twice. Rewards belong in an append-only ledger of point entries, each referencing the transaction that earned or redeemed them, so the balance is a sum rather than a mutable column that can drift; a running balance can be a periodically materialised snapshot for speed. Index on card ID plus timestamp for statement queries, and partition transactions by month, since that is the table which grows without bound. Rates and category multipliers belong in their own effective-dated table so a promotion changing tomorrow does not rewrite the meaning of yesterday’s transactions.
Q: How do you check whether a string of brackets is balanced?
Walk the string with a stack. On an opening bracket push it; on a closing bracket, if the stack is empty the string is unbalanced, otherwise pop and check that the popped opener matches the closer’s type using a small map from closer to opener. After the loop the string is balanced only if the stack is empty, which catches unclosed openers like a trailing open parenthesis. That is O(n) time and O(n) space in the worst case of all openers. Two edge cases interviewers deliberately test are an empty string, which should return true, and a string beginning with a closer, which must fail without underflowing the stack. If the input mixes brackets with other characters, decide explicitly whether they are ignored or invalid rather than assuming.
Q: How would you model a rewards engine so new offer types can be added without rewriting it?
Put each earning rule behind a common interface, for example a RewardRule with a method that takes a transaction and returns points earned, plus a predicate saying whether the rule applies. Concrete implementations then cover a flat rate per rupee, a category multiplier for dining or travel, a merchant-specific bonus, and a capped promotional offer, and adding a new offer means adding a class rather than editing a growing conditional. A RewardEngine holds an ordered list of applicable rules loaded from configuration and composes their results, which is the Strategy pattern combined with a Chain of Responsibility if some rules should stop evaluation. Keep rules effective-dated and stateless so they can be unit tested in isolation and so replaying an old transaction reproduces the original points exactly. The design principles to name are Open-Closed, since the engine is open to new rules and closed to modification, and dependency inversion, since the engine depends on the interface rather than on any concrete offer.
Q: How do you keep a transaction ledger accurate when requests can be retried or arrive out of order?
Make writes idempotent by requiring the client to send an idempotency key with every state-changing request and storing it under a unique constraint alongside the resulting outcome; a retry with the same key returns the stored result instead of posting a second entry. Make the ledger append-only and double-entry, so a correction is a compensating reversal entry rather than an update or delete, which keeps a complete audit trail and lets you rebuild any balance by replaying entries. Handle out-of-order arrival by keying on the event’s own business timestamp and sequence number rather than the arrival time, and by making the apply step commutative where possible so ordering does not change the final balance. Use a database transaction with an atomic conditional update, or a SELECT ... FOR UPDATE row lock, whenever a balance is both read and written, so two concurrent postings cannot both see the same starting balance. Finally, run a periodic reconciliation job that recomputes balances from the ledger and alerts on any drift, because in a payments system detecting an inconsistency late is the expensive failure.
Frequently asked questions about American Express interviews
Section titled “Frequently asked questions about American Express interviews”What is the American Express interview process for freshers?
American Express campus hiring typically runs an online coding assessment (around 90 minutes, 3 questions of medium-to-hard difficulty on Codility), followed by one or two technical interviews (45-60 minutes each, DSA plus OOP and low-level design), and a final HR round. Total timeline is usually 2-3 weeks from test to offer.
What questions are asked in American Express interviews?
American Express technical rounds cover DSA problems (stacks, queues, linked lists), OOP concepts, and low-level design questions such as designing a small system or a database schema. The HR round asks why American Express, strengths and weaknesses, and which team or role you’d prefer.
How many rounds are there in the American Express interview?
Most American Express campus drives use 3-4 rounds: Online Assessment, one or two Technical Interviews, and an HR round. The later technical round is sometimes combined with the hiring manager discussion, so some candidates report only 3 stages.
What is the American Express online assessment like?
The OA runs about 90 minutes on Codility, with 3 coding questions at medium-to-hard difficulty - typically covering arrays, strings, and basic data-structure manipulation rather than heavy algorithmic puzzles. Codility auto-grades on both correctness and code quality/performance, so partial-credit test cases matter.
How should I prepare for American Express interviews?
Practice timed coding on Codility-style platforms specifically, since its scoring and test-case format differs slightly from LeetCode/HackerRank. Revise OOP and low-level design basics - Amex interviewers like asking you to design a small system or a simple schema. Prepare a clear story for why you want to join a payments and financial-services company, since that’s asked directly in HR.
Does American Express ask payments/fintech-domain questions for freshers?
Less than a pure fintech startup, but it comes up - interviewers occasionally frame low-level-design prompts around a card-transaction or rewards-style system, and the HR round explicitly checks your interest in payments/financial services. The core technical bar, though, is standard DSA/OOP/LLD rather than deep domain knowledge.