Interview questions & answers

Real questions by role and company — each with a framework for a strong answer. Then rehearse them out loud with AceCoach, our free AI interview coach.

By role

• Software Engineer interview questions
• Data Analyst interview questions
• Product Manager interview questions
• UI/UX Designer interview questions
• DevOps Engineer interview questions
• Digital Marketing Manager interview questions
• Data Scientist interview questions
• Machine Learning Engineer interview questions
• Frontend Developer interview questions
• Backend Developer interview questions
• Business Analyst interview questions
• Project Manager interview questions
• QA Engineer interview questions
• Financial Analyst interview questions
• Sales Representative interview questions
• HR Recruiter interview questions

By company

• Big Tech interview prep — Google · Amazon · Microsoft · Meta · Apple · Netflix
• IT services & consulting interview prep — TCS · Infosys · Accenture · Deloitte
• Startups & finance interview prep — Early-stage startups · JPMorgan Chase

Big Tech interviews follow a predictable structure once you understand what each round actually tests

A Big Tech coding interview — Google, Meta, Amazon, Microsoft — is designed around a single question: can this engineer solve novel algorithmic problems under time pressure? The structure is consistent: 45 minutes, one to two algorithmic problems, discussion of approach and tradeoffs. You are not being graded on whether you solve it perfectly; you are being graded on how you think. How do you approach an unfamiliar problem? Do you state your assumptions? Do you ask clarifying questions? Do you recognize when you are stuck and pivot? The interviewer is listening for thinking patterns, not just code. Most candidates fail because they jump into code without a plan. Most passes come from candidates who spend 10 minutes talking through the approach, write clean code, and talk through complexity tradeoffs. If you understand this — that the interview is assessing your thinking process, not your answer — you can prepare systematically. Study algorithm families (sorting, searching, dynamic programming, graphs) not individual LeetCode problems. Practice explaining your approach out loud before writing code. The preparation is formulaic because the interview structure is formulaic.

System design interviews at Big Tech test a different skill: can you decompose a large, ambiguous problem into components and make architectural tradeoffs? You are given something like 'design Instagram' or 'design a payment system', and you have 45 minutes to propose a reasonable architecture. The interviewer is not looking for one correct answer — there is no perfect Instagram design — but rather for evidence that you think about scalability, database choices, caching, and consistency guarantees. Again, the skill is decomposition and clear communication of tradeoffs, not memorization. Preparation is pattern-based: study common components (load balancing, caching, databases, messaging queues) and tradeoff frameworks (consistency vs availability, latency vs durability). Practice designing systems by explaining your choices and listening for interviewer feedback.

Big Tech behavioural interviews test how you work with others and how you handle ambiguity. You are asked to tell stories about past decisions, conflicts, or failures. The interviewer is listening for: do you take responsibility or blame others? Do you learn from mistakes? Can you navigate ambiguity without needing perfect information? The preparation here is different — you need three to five well-rehearsed stories that cover different dimensions: handling disagreement with teammates, recovering from a mistake, prioritizing under constraints, driving a project to completion. Write these stories down, practice them out loud until they feel natural (not scripted), and make sure they illustrate specific qualities the company values. Big Tech values engineers who are autonomous, detail-oriented, and willing to simplify complex problems.

IT services and consulting interviews test project management and communication, not innovation

Interviews at TCS, Infosys, Accenture, Deloitte follow a different playbook entirely. The coding interview, if included, is easier — LeetCode Easy to Medium difficulty, focus on code clarity and ability to explain your solution. The interviewer is checking that you can write maintainable code and communicate your thought process. Complexity optimizations matter less than demonstrating a structured approach. The system design or architecture round, if it exists, is not about designing Instagram; it is about designing a realistic component that might exist in an enterprise system — a data pipeline, a reporting system, a batch processor. The interviewer wants to know: can you understand requirements, decompose a concrete problem, and choose technologies that solve it pragmatically? This is very different from Big Tech system design, which tends toward unbounded scale. Services companies are hiring for different work — delivering client projects on time, to spec, with clear ownership — not for building the next consumer product.

Behavioural interviews in services hiring focus on project delivery, team coordination, and client management. Expect questions like: 'Tell me about a time you had to manage a difficult client expectation', 'How have you handled a missed deadline?', 'Describe a time you disagreed with your manager'. The interviewer is assessing your ability to work within hierarchy, communicate upward and downward, and deliver despite constraints. Stories that work here are different from Big Tech stories: emphasize how you kept the project on track, how you communicated changes to stakeholders, how you adapted when initial plans fell apart. Services companies value reliability and communication over innovation and speed. A story demonstrating 'I noticed the client's requirement was incomplete so I asked clarifying questions' works better than 'I shipped a feature faster than expected by cutting scope'.

Technical depth is still tested but in a narrower, more practical context. You might be asked about specific technologies (Java frameworks, SQL databases, REST APIs) used by the company or their clients. The interviewer is checking that you can pick up domain knowledge quickly and apply it to concrete problems. You will not be asked to design a message queue from first principles; you will be asked 'How would you use Kafka to solve this data pipeline problem?' or 'What is the tradeoff between MongoDB and PostgreSQL for this use case?' The preparation shifts from learning algorithm families to learning pragmatic technology choices and how they are deployed in enterprise systems. Read architecture blogs from banks and insurers (JP Morgan, Deloitte), understand common patterns in enterprise software, and be able to discuss tradeoffs in terms of operational reality — deployability, maintainability, cost of failure — not theoretical elegance.

Startup interviews are less standardised, which makes them more predictable if you know what to listen for

Startup interviews often skip formal rounds and instead probe whether you can think independently and adapt quickly. There is no standard structure — you might interview with a founder and a senior engineer in one session, get a coding problem that is specific to their codebase, or skip coding altogether and spend an hour pair-programming on a real problem. The unpredictability is the point: the interview is testing whether you stay calm when you do not know what is coming next. How you handle ambiguity and what you ask when you are uncertain matters more than how you solve a specific problem. Startups are building something new; they need engineers who can figure things out with incomplete information. Preparation for this is different: do not memorize problem solutions or prepare polished stories. Instead, be ready to ask intelligent questions, to state your assumptions, to say 'I do not know but here is how I would learn', and to be genuinely interested in what the company is trying to build. Interviewers at startups want to hear curiosity and problem-solving thinking, not rehearsed answers.

Coding in a startup interview often comes with a twist: the problem is either very open-ended or tied to the company's actual tech stack and problems. A startup might ask you to extend an existing feature or solve a problem using their specific codebase. This is harder to prepare for because it is not formulaic. Your preparation should focus on understanding their product, their technology choices, and the problems they are solving. Look at their GitHub if they are open source, read their engineering blog, understand their architecture. When you interview, you can show that you have done homework and ask informed questions about their technology choices. This signals genuine interest and lets you demonstrate problem-solving in a real context rather than a hypothetical one.

Startup behavioural interviews probe adaptability and autonomy more than anything else. Expect questions like: 'Tell me about a time you shipped something with incomplete information', 'How do you prioritize when everything feels urgent?', 'Describe a time you had to teach yourself something new quickly'. Startups are betting on people who can move fast and not get paralysed by uncertainty. Stories that work here are different from services or Big Tech: you want to illustrate how you learn, how you push forward despite incomplete information, and how you handle failure. A story about 'I shipped a feature on Friday that had a bug on Monday, I fixed it Tuesday' works better than a story about 'I spent two weeks perfecting a solution'. Startups value iteration and feedback loops over perfection. The hiring manager is asking: can this person ship something good enough, learn from real usage, and improve? Can they work without a detailed spec? That is what startup success looks like.

Frequently asked questions