Whether you're preparing for your first SDE-1 role or targeting a Senior Engineer position at a FAANG, these are the questions that actually come up. Each question includes the interviewer's real intent, a structured answer framework, a spoken-ready sample answer, and the red flags that get candidates rejected.
Salary expectations, career gaps, why you're leaving, strengths & weaknesses — the questions that trip up even strong coders.
Conflict resolution, leadership, failure stories, and teamwork — structured using the STAR method with Amazon LP mapping.
Data structures, algorithms, problem-solving approach, and code quality — what senior interviewers really evaluate beyond the correct answer.
Scalability, database choices, caching, load balancing — the architectural thinking that separates mid-level from senior engineers.
This is NOT a biography request. The interviewer wants to understand three things in 60 seconds: what you do now, one concrete proof that you're good at it, and why this specific role excites you. They're also calibrating your communication clarity for the rest of the interview.
Sure, I'd be happy to give you the quick version.
I'm currently a Software Engineer at Razorpay, where I work on the payments infrastructure team. My day-to-day is building and maintaining the APIs that process about 2 million transactions a day — so reliability and latency are basically my entire world.
The project I'm most proud of from this past year is redesigning our retry and idempotency layer. We were seeing about 0.3% of payments fail silently during bank timeouts. I proposed and built a state-machine-based retry system with exponential backoff, and it brought that failure rate down to under 0.02%. That translated to roughly ₹4 crore in recovered revenue per month.
The reason I'm excited about this role is that your team is building the payment orchestration platform from the ground up. That intersection of distributed systems and direct business impact is exactly where I do my strongest work, and I'd love to contribute to that from day one.
They want to see if you can explain complex technical work clearly, whether you understand the business impact of what you built, and how deeply you contributed vs. just being on the team. This is where senior candidates separate themselves — ownership and depth matter more than the project size.
The project I'm most proud of was redesigning the notification delivery pipeline at my current company. We're a B2B SaaS with about 2,000 enterprise customers, and our notification system — emails, in-app alerts, webhooks — was a single monolithic worker processing everything sequentially.
The problem was that during peak hours, a single customer sending a bulk campaign would block notifications for everyone else. We were getting 15-20 escalations a month about delayed alerts.
I proposed and led the migration to an event-driven architecture using Kafka with per-customer partitioning. The key design decision was implementing priority queues with fair scheduling — so time-sensitive webhooks (like payment confirmations) would never wait behind bulk marketing emails, even from the same customer.
I owned the architecture doc, wrote the core consumer service in Go, and built a shadow-traffic testing framework to validate it before the cutover. The migration took 6 weeks with zero downtime.
The result: p99 notification latency dropped from 45 seconds to under 2 seconds, customer escalations went to near-zero, and we handled a 4x traffic spike during our product launch without any intervention.
This is a character test disguised as a career question. They're checking for: professionalism (do you badmouth employers?), self-awareness (do you know what you actually want?), and flight risk (will you leave US in 6 months too?). The right answer pulls TOWARD the new role, never pushes AWAY from the old one.
Honestly, I've had a great run at my current company. I joined as a junior engineer and I've grown into a solid mid-level developer here — the team is strong and I've shipped meaningful work.
But over the last year, I've realized that I'm mostly optimizing existing systems rather than designing new ones. The architecture decisions are made at the principal level and then handed down, which made sense when I was learning, but I've reached a point where I want to be in the room making those decisions.
What attracted me to this role specifically is that your engineering team operates with a high degree of autonomy — I noticed from your engineering blog that individual engineers own service architecture end-to-end. That's the kind of environment where I can have the most impact and continue growing.
At Amazon, this maps to the Leadership Principle "Have Backbone; Disagree and Commit." They want to see that you can push back respectfully with data, that you don't just roll over to avoid conflict, AND that once a decision is made you commit fully — even if it wasn't your preference. The best answers show the disagreement was about the WORK, not about egos.
Last quarter, my team lead proposed migrating our entire authentication system from JWT tokens to session-based auth. His reasoning was that JWTs were causing issues with token revocation when we needed to force-logout compromised accounts.
I disagreed with the full migration approach. I ran a quick analysis and found that only 3% of our auth flows actually needed immediate revocation — primarily admin and billing operations. A full migration would have taken 6 weeks and introduced risk across all our services.
Instead, I proposed a hybrid approach: keep JWTs for standard user sessions (which covered 97% of traffic), but add a short-lived session layer specifically for sensitive operations with a Redis-backed revocation list. I put together a one-page doc comparing the two approaches — engineering hours, risk surface, and rollback complexity — and presented it in our next architecture review.
My lead agreed to try the hybrid approach first. We shipped it in 2 weeks instead of 6, the revocation issue was fully resolved, and we didn't touch the majority of our auth infrastructure. He actually referenced it later as a good example of "disagree with data, not opinions."
The URL shortener is a classic "entry-level system design" question because it seems simple but reveals your thinking about scale, storage, hashing, read vs. write ratios, caching, and analytics. Interviewers use it to calibrate your architectural maturity before asking harder design questions. A senior candidate is expected to proactively discuss tradeoffs, not wait to be asked.
Before I jump into the design, let me clarify a few things. I'll assume we need to handle about 100 million new URLs per month, the read-to-write ratio is roughly 100:1, URLs should be as short as possible, and we need basic click analytics.
High-level architecture: At the top, we have a load balancer distributing traffic to two service types — a Write Service for creating short URLs and a Read Service for redirecting. Both backed by a shared database and a caching layer.
URL generation: I'd use a distributed ID generator (like Twitter's Snowflake) to produce unique 64-bit IDs, then Base62-encode them to get a 7-character short code. This avoids collision entirely and gives us ~3.5 trillion unique URLs before we run out.
Storage: A relational database like PostgreSQL for the mapping table — short_code (primary key), original_url, created_at, expiry, user_id. With 100M URLs/month, that's about 1 TB/year which is very manageable with partitioning.
Caching: Since reads dominate, I'd put a Redis cache in front of the database. The top 20% of URLs likely account for 80% of redirects. Cache hit ratio should be above 90%, bringing p99 redirect latency under 10ms.
Analytics: Every redirect fires an async event to Kafka, consumed by an analytics service that aggregates click counts, geographic data, and referrer info. This keeps the redirect path fast and decoupled from analytics processing.
At scale: If we need to go beyond a single database, I'd shard by the first two characters of the short code. And for the read service, we can scale horizontally since it's stateless with the cache handling most traffic.
Explore all 45+ questions organized by interview round:
You can memorize every answer on this page. But when the interviewer asks an unexpected follow-up, interrupts mid-sentence, or throws a curveball you didn't prepare for — that's when most candidates freeze.
ClapAssist runs silently during your Zoom, Meet, or Teams call. It hears the exact question and shows you what to say in under a second — completely invisible on screen share.