Top 20 Interview Questions for H1B Visa Holders at FAANG Companies

I've been through the FAANG interview process three times. Made it to the final round at Google twice, got an offer from Amazon, and bombed a Meta phone screen so badly I still think about it in the shower sometimes. I'm not saying this to brag — the point is I've sat on both sides of the table now, and I want to share what I wish someone had told me when I was prepping for these interviews on an H1B.

What nobody talks about openly: the interview process at these companies is hard for everyone, but it's harder in specific ways if you're an Indian professional on an H1B visa. Not because the questions are different — they're not. But because the stakes are different. If a US citizen bombs an interview at Google, they apply somewhere else next week. If you bomb it and you're on an H1B with a transfer pending, or your current company is going through layoffs, the consequences compound fast. That pressure changes how you prepare, how you perform, and what mistakes you're likely to make.

What follows are 20 questions that come up repeatedly across FAANG interviews, along with what's actually going on behind each question and where Indian candidates namely tend to struggle. I've grouped them loosely, but don't treat these as rigid categories — in a real interview, a behavioral question can pivot into a technical one and vice versa.

The "Tell Me About Yourself" Trap

1. "Walk me through your background."

This feels like a softball. It's not. What the interviewer wants is a 2-3 minute narrative that connects your experience to the role you're interviewing for. What Indian candidates often do instead is start from their engineering college and methodically walk through every job they've held, in chronological order, for 8-10 minutes.

The fix is simple: start with what you're doing now, explain why it's relevant to this role, and briefly mention 1-2 past experiences that build the case. "I'm currently a senior backend engineer at Walmart Labs, where I've been leading the redesign of our inventory management system to handle Black Friday scale — about 250K requests per second at peak. Before that, I spent three years at Infosys working on distributed systems for banking clients, which is where I really fell in love with solving reliability problems at scale. I'm excited about this role at Google because your Cloud Spanner team is tackling exactly the kind of distributed consistency challenges I've been working on."

That's it. Under two minutes. Specific. Forward-looking.

2. "Why do you want to work here?"

I've heard Indian candidates answer this with "Because Google is the best company in the world" or "I've always admired FAANG companies." These answers are generic enough to apply to literally any candidate at any company, which means they add zero signal. The interviewer is trying to assess whether you've done your homework and whether your motivations align with the team's mission.

Be specific. "I've been following the work your team published on the Pathways architecture, and the idea of building a single model that can generalize across tasks is something I've been thinking about since I read the paper in December. My experience building ML pipelines at my current company would translate directly, and I think I could contribute meaningfully to the serving infrastructure side." That's an answer that only makes sense for that specific role at that specific company. That's what they want.

3. "Why are you looking to leave your current role?"

This is where the H1B elephant enters the room. Maybe you're leaving because your current employer underpays you and you know it. Maybe your company is on a layoff spree and your visa transfer is a ticking clock. Maybe you're stuck doing maintenance work on a legacy system and you want to grow. All of these are valid, but "my H1B situation is complicated" is not a good answer, even if it's the truest one.

Focus on what you're moving toward, not what you're running from. "I've learned a lot in my current role, but I've hit a ceiling on the technical challenges available to me. I want to work on systems that operate at a scale I can't access at a mid-size company, and I'm precisely drawn to the kind of problems your team solves." The interviewer probably knows visa dynamics are a factor. You don't need to spell it out.

Technical Questions That Have a Behavioral Layer

4. "Describe a system you've designed from scratch. What tradeoffs did you make?"

Google and Meta love this question. They're not just testing your system design knowledge — they want to see how you think about tradeoffs. Indian engineers, in my experience, tend to present their designs as optimal solutions rather than as a series of choices with consequences. The American tech interview culture values the phrase "it depends" much more than Indian engineering culture, where there's often an expected "right answer."

Walk through your actual reasoning. "We chose Cassandra over PostgreSQL for this service because we needed high write throughput and could tolerate eventual consistency for this particular use case. The tradeoff was that our read queries became more complex, and we had to build a separate read model for the dashboard. If I were doing it again, I might consider DynamoDB instead, because managing Cassandra clusters turned out to be more operational overhead than we anticipated." That kind of honest, specific answer with a retrospective admission scores very well.

5. "How would you design [Twitter/Instagram/Uber's core feature]?"

The classic system design question. Everyone expects it, and yet most people prepare for it wrong. They memorize architectures. They draw the same boxes-and-arrows diagram they saw on a YouTube tutorial. The interviewer has seen that diagram a thousand times.

What differentiates you is asking good clarifying questions upfront (which Indian candidates often skip because they don't want to seem unprepared) and making your thought process visible. Start with requirements — "Are we optimizing for read-heavy or write-heavy? What's our expected QPS? Do we need real-time or near-real-time?" Then build incrementally. Start simple, identify bottlenecks, and evolve the design. The interviewer wants to see you think, not recite.

6. "Tell me about a time you disagreed with your tech lead or manager."

This trips up Indian candidates more than almost any other question, and I think the reason is cultural. In many Indian workplaces, disagreeing with your manager openly is unusual. The hierarchy is more rigid. So when this question comes up, a lot of candidates either say "I've never really disagreed" (which sounds dishonest) or they tell a story where the disagreement was so mild it barely counts.

Amazon asks some version of this in literally every loop. It maps to their "Have Backbone; Disagree and Commit" leadership principle. They want to hear that you pushed back when you believed you were right, did so respectfully, backed it with data, and then committed to the final decision regardless of whether it went your way. Think of a real example before the interview. Everyone has one. Maybe you argued against a technology choice. Maybe you pushed back on an unrealistic deadline. The specifics matter less than demonstrating that you can hold a professional disagreement.

7. "You've inherited a codebase with significant technical debt. How do you approach it?"

This is practically a trick question because the obvious answer — "I'd refactor everything" — is wrong. The right answer involves prioritization, business context, and pragmatism. How do you identify which debt is actually causing problems vs. which is just aesthetically ugly? How do you make the case to product managers that refactoring time is worth the investment? How do you do it incrementally without halting feature development?

If you've worked at a services company in India where the client dictated every sprint, talk about that honestly. "At my previous company, we had very little autonomy over the backlog, so I learned to fold refactoring into feature work — every PR that touched a messy module, I'd leave it slightly better than I found it. It's not glamorous, but over six months we reduced our bug rate in that module by about 40%."

Amazon's Leadership Principles Questions

If you're interviewing at Amazon, I cannot overstate how seriously they take the Leadership Principles. Every single interview question maps to one or more LPs. Your answers need to map back to them too.

8. "Tell me about a time you made a decision with incomplete data." (Bias for Action)

Amazon wants people who move fast even when they don't have perfect information. Indian engineering culture — particularly at larger companies — often emphasizes getting sign-off, getting all requirements documented, getting approval from three levels of management before proceeding. That's the opposite of what this question is probing for.

Your example should show: I had limited information, I assessed the risks, I made a call, I was willing to course-correct if I was wrong. "We were seeing intermittent failures in production during peak hours, and our monitoring wasn't granular enough to pinpoint the cause. Rather than spending a week building out better observability first, I hypothesized it was a connection pool exhaustion issue based on the pattern, pushed a config change to increase the pool size, and set up alerts to validate. The failures dropped 80% within an hour, confirming the hypothesis. We then built proper monitoring as a follow-up."

9. "Describe a time you simplified something complex." (Invent and Simplify)

Another Amazon favorite. They want to hear that you don't just add complexity — you actively fight it. "We had a deployment process that involved 14 manual steps across three different tools. I wrote a single CLI tool that automated the entire flow and reduced deployment from a 2-hour process to a 15-minute one. I also documented it so other teams could adopt it, and within a quarter, four teams were using it."

10. "Tell me about your biggest professional failure." (Earn Trust / Learn and Be Curious)

The failure question. Everyone dreads it. Indian candidates especially tend to either pick a failure that's secretly a success ("I worked too hard and burned out") or they minimize the failure so much that it doesn't sound like a failure at all.

Pick a real failure. Something that actually went wrong because of a decision you made. Then — and this is the part that matters — explain what you learned and what you changed. "I once pushed a database migration to production without testing it against a realistic dataset. It worked fine in staging with 10K rows, but in production with 50M rows, it locked the table for 20 minutes during peak traffic. We lost about $30K in failed transactions. After that, I built a pre-production environment with production-scale data and made it a mandatory step in our migration runbook. We never had that issue again."

Google's Style: Analytical and Open-Ended

Google interviews feel different from Amazon ones. Where Amazon is structured around LPs, Google tends to be more free-form. The interviewers have more latitude, and the questions often probe for intellectual curiosity and analytical thinking.

11. "How would you improve Google Search?" (or Maps, or Gmail, or any Google product)

This is a product sense question that sometimes shows up even in engineering interviews at Google. They want to see that you think about users, not just code. The mistake I see Indian engineers make is jumping straight into technical solutions without defining the problem. "I'd add machine learning to improve results" is not an answer. "I've noticed that when I search for recipes, the top results are all SEO-optimized blog posts with 2000 words of backstory before the actual recipe. I'd explore a feature that extracts and surfaces the recipe directly in the search results, similar to how featured snippets work but more structured. The technical challenge would be building a reliable recipe parser that works across different site formats..." — that's closer to what they want.

12. "Design an algorithm to [specific problem]. Now optimize it."

The classic coding question. Google still weighs these heavily. I won't go into specific algorithms here because that's a whole separate topic, but I want to address something specific to Indian candidates: the communication gap during coding interviews.

At top Indian engineering colleges and in competitive programming culture, the emphasis is on finding the optimal solution quickly. In an American tech interview, the emphasis is equally on communication. Think out loud. Explain your approach before you code. Talk through tradeoffs between a brute force approach and an optimized one. Ask clarifying questions about edge cases. Indian candidates who are genuinely brilliant algorithmically sometimes get mediocre scores because they code in silence for 30 minutes and then present a working solution without having said a word.

The interviewer can only evaluate what you show them. If all they see is someone typing silently, they can't give you credit for your thought process.

13. "What's something technical you've learned recently that excited you?"

Google loves intellectual curiosity. This question is your chance to geek out. Don't give a generic answer like "I've been learning about cloud computing." Be specific and passionate. "I've been diving into CRDTs — conflict-free replicated data types — after reading Martin Kleppmann's work on it. The idea that you can design data structures where concurrent edits always converge without coordination is beautiful, and I've been playing around with implementing a collaborative text editor using Yjs to understand the practical challenges." That's an answer that makes the interviewer want to talk to you more.

Meta's Emphasis on Impact

14. "What's the most impactful project you've worked on, and how do you measure that impact?"

Meta is obsessed with impact. Measurable, quantifiable impact. If you can't put a number on it, Meta's interviewers will push you until you can. This is where Indian candidates from services companies sometimes struggle — when your client owns the metrics and you're three layers removed from the business outcome, it's hard to claim specific impact numbers.

Do the work beforehand. Even if you don't have exact numbers, estimate. "The caching layer I implemented reduced our API response time from 800ms to 120ms. Based on internal studies showing that every 100ms of latency reduces conversion by 1%, I estimate this improvement contributed to roughly a 6-7% uplift in checkout completions, which for our transaction volume would mean approximately $2M in additional annual revenue." Is that estimate perfect? Probably not. But it shows you think in terms of business outcomes, not just technical outputs.

15. "How do you prioritize when you have more work than time?"

This sounds like a time management question, but at Meta it's really about prioritization frameworks. They want to hear that you can distinguish between urgent and important, that you can push back on low-value requests, and that you communicate proactively when things are going to slip. "I ask three questions: what's the customer impact, what's the deadline driven by, and what happens if this slips by a week. That usually makes the priority obvious. If it doesn't, I escalate to my manager with a recommendation rather than just presenting the problem."

The Visa-Adjacent Questions

16. "Are you authorized to work in the United States?"

This one's straightforward and legal. If you're on an H1B, the answer is yes — you are authorized to work in the US. You don't need to volunteer your specific visa type unless asked. If they ask follow-up questions about whether you'll need sponsorship in the future (for green card processing, for instance), be honest. Most FAANG companies sponsor green cards routinely and this isn't a red flag for them. Where it can get tricky is at smaller companies, but that's a different conversation.

17. "Where do you see yourself in five years?"

This question has a hidden dimension for H1B holders. The interviewer might be (sometimes unconsciously) wondering about your long-term commitment — will you stay in the US? Will you go back to India? Is this just a stepping stone? You don't need to address any of that directly. Answer it like anyone else would: talk about your career growth goals, the kinds of problems you want to solve, the scope of impact you want to have. "In five years, I want to be leading a platform team that other teams depend on, making the kind of architectural decisions that set the direction for the engineering org. I'm drawn to companies that promote from within and invest in growing their engineers, which is one reason I'm excited about this role."

The Culture Fit / Collaboration Questions

18. "Tell me about a time you had to work with a difficult teammate."

A universal question, but one where cultural context matters. In Indian work environments, "difficult teammate" conflicts are often resolved through the manager or through avoidance. American tech culture expects you to have addressed it directly. Your answer should show that you initiated a direct conversation, sought to understand the other person's perspective, and found a resolution — or at least a way to work productively together.

"I had a teammate who consistently pushed back on code reviews, not with technical feedback but with stylistic preferences that weren't in our coding standards. It was slowing us down and creating friction. I asked him to grab coffee, and in that conversation, I learned that he'd been a solo developer at his previous company and wasn't used to collaborative review. We agreed on three things: we'd follow the existing style guide, we'd save stylistic debates for our weekly team retro, and we'd keep PR comments focused on correctness and maintainability. Things improved noticeably after that."

19. "How do you handle receiving critical feedback?"

Be honest but show growth. "I'll admit my initial reaction to critical feedback is usually defensive — I think that's human nature. But I've trained myself to separate the immediate emotional response from the actual content of the feedback. I usually say 'thank you, let me think about that' in the moment, and then I actually go think about it. More often than not, the feedback is pointing at something real, even if the delivery wasn't ideal. I've gotten much better at this over the years, and I've had managers in particular tell me they appreciate that I take feedback seriously and act on it."

That answer works because it's honest about the imperfection. If you say "I love getting critical feedback!" nobody believes you.

20. "Do you have any questions for me?"

Always, always, always have questions. And not the generic ones you Googled. Not "What does a typical day look like?" which is fine but forgettable. Ask something that shows you've been paying attention during the interview. "You mentioned your team is migrating from a monolith to microservices — how far along are you in that process, and what's been the biggest surprise?" Or, "What does the on-call rotation look like for this team, and how has it changed in the last year?" Or even, "What's the one thing you wish you'd known before joining this team?"

For H1B candidates especially, one question I'd recommend: "Can you tell me about the team's approach to professional development? Are there opportunities for conference attendance or internal mobility?" This signals that you're thinking long-term and invested in growth, which can subtly address any unspoken concerns about commitment.

Patterns I've Noticed Across All FAANG Interviews

Indian candidates who do well at FAANG interviews share a few traits that have nothing to do with raw technical ability. They practice talking through problems out loud, which doesn't come naturally if you grew up in an education system that emphasized silent, individual work. They quantify their impact, even when it requires estimation. They're comfortable saying "I don't know, but here's how I'd figure it out." They ask clarifying questions rather than assuming the most complex interpretation of a problem.

The ones who struggle tend to have the opposite patterns: they code in silence, they describe responsibilities instead of achievements, they avoid admitting uncertainty, and they try to impress with complexity rather than clarity.

If I had to boil it down to one meta-strategy for Indian engineers interviewing at FAANG companies, it would be this: the interview is a conversation, not an exam. There is no answer sheet. The interviewer is your potential future colleague, and they're trying to imagine what it would be like to work with you. Would you be the kind of person who explains your thinking, asks for help when stuck, admits what you don't know, and makes the people around you better? Or would you be the person who silently grinds through problems alone and only speaks up when they have the perfect answer?

American tech culture overwhelmingly rewards the former. Indian education culture often trains us for the latter. Bridging that gap is the real preparation.

One last thing. Before your interview, find out who your interviewers are, if possible. Check their LinkedIn, their blog posts, their conference talks. Not to stalk them — to understand their technical interests. When you're in the interview and they ask an open-ended question, being able to reference something relevant to their area of expertise creates a connection that's genuine and memorable. I once mentioned a blog post my Google interviewer had written about distributed tracing, and the entire dynamic of the interview shifted from "evaluator and candidate" to "two engineers having a technical discussion." That's the energy you want. And sometimes, that's the difference between a "lean hire" and a "strong hire."