What to Expect in a CS Interview

In the last 15 years, I’ve interviewed at Google, Microsoft, Paytm, Amazon, and dozens of startups.  And no matter the company, the interview pattern rarely changes.  Here’s what to expect in 99% of product-based company interviews:   1. Data Structures & Algorithms (DSA)   Time: 45-60 minutes  What happens:   - Solve 1-2 DSA problems within the time limit.   - Write optimal, bug-free code that actually runs.   - Explain time & space complexity for every approach.   - Be prepared to handle edge cases, one miss can cost you.  DSA is usually the first filter. If you fail here, you don’t move forward.   2. System Design / High-Level Design (HLD)  Time: 60-90 minutes  What happens:   - You get an open-ended system design problem.   - Explain the architecture, database modeling, and API contracts.   - Think about scalability, performance, and fault tolerance.   - No coding, just whiteboarding & deep technical discussions.  There’s no single correct answer, what matters is how you think and justify your design.   3. Low-Level Design (LLD)  Time: 60-90 minutes  What happens:   - You get a generic feature to design - (like a parking lot system, ATM, or rate limiter).   - Define classes, attributes, and interactions.   - Follow SOLID principles and avoid redundant data.   - Sometimes, you’ll need to write actual code based on the discussion.  Good design choices can make or break your interview.   4. Machine Coding Round (MC)  Time: 90-180 minutes  What happens:   - Build a working solution for a given problem, this isn’t about theory anymore.   - Write executable, maintainable code for at least one core functionality.   - Follow best practices, clean code, SOLID, design patterns, error handling.   - Your code should be flexible enough for modifications (they might ask you to extend functionality).  5. Managerial Discussion   Time: 45-60 minutes  What happens:   - Deep dive into your past projects, expect follow-up questions.   - How did you solve challenges? What was your impact?   - Situational questions (answered best with the STAR method).   - You’re evaluated on ownership, leadership, and decision-making.  This round is not just about tech, it’s about how you work and think.   6. Cultural Fit Round   Time: 30-45 minutes  What happens:   - How well do you align with the company’s values & culture?   - Expect behavioral questions (e.g., “Tell me about a time you handled conflict”).   - Be honest, don’t make up stories to fit the values.  You can clear every technical round and still get rejected here.     Also, Some companies include:   - Concurrency discussions (how to handle multi-threading & parallelism).   - Pair programming (coding in real-time with an interviewer).   - Take-home assignments (especially in startups).  But for most product-based companies, these six rounds are the standard.  

I was chatting with a backend interviewer ... ... and I picked his brain about what he expects from candidates. Here are 8 items he is always looking at: 1. Programming Language Proficiency He expects candidates to know their primary backend language inside and out: Python, Java, C#, it doesn't matter. The more senior the role, the more he dives into advanced topics like memory management, concurrency, and language-specific features. 2. Database Knowledge He always checks if candidates are comfortable with SQL databases. Be ready to chat about query optimization, schema design, and concepts like indexing and transactions. 3. APIs & Web Services He loves asking about API design. Candidates should know how to build RESTful APIs, why other options exist (GraphQL), and how to handle authentication (think OAuth). Expect questions on rate limiting, API versioning, and even webhooks. 4. System Design Even for junior roles, he tests candidates on system architecture. You'll need to explain how to design systems for scalability, fault tolerance, and high availability. He's big on event-driven architecture. 5. Security Security is a non-negotiable. He'll ask about SQL injection, XSS, CSRF, and how you secure APIs. If you don't mention data encryption, input validation, or authentication best practices, that's a red flag for him. 6. Testing & Debugging He expects candidates to know how to write unit tests at a minimum. 7. Data Structures & Algorithms You don't need to be a LeetCode wizard, but understanding Big-O complexity and knowing when to use hash maps, trees, or queues will help you stand out. 8. DevOps & Deployment Basics He doesn't expect you to be a DevOps expert, but he'll definitely ask about CI/CD pipelines, Docker, and deploying apps on cloud platforms like AWS, Azure, or GCP. The best way to learn these topics is to build actual products. Try to bring your ideas to life, eventually, you'll hit most of these.

I sat down for 2 hours and recalled every coding interview I’ve given in the last 8 years of my career at Google, Meta, Microsoft, Amazon, Hotstar, Dunzo and many other companies... Here are the topics that I was asked about (in order of fundamentals): 1// Category 0 – Absolutely Fundamentals These topics are non-negotiable. If you skip these, you’re setting yourself up for a tough time in every interview, no matter the company. - Dynamic Arrays - String Manipulation - Two Pointers - Grids & Matrices - Binary Search - Sets & Maps - Stacks & Queues - Recursion - Sorting - Linked Lists - Trees - Graphs Master these inside out before touching anything else. 2// Category 1 – Fundamentals+ Once you’re solid on the basics, double down here. These topics show up a lot in interviews, and depth here will help you stand out: - Heaps - Sliding Windows - Backtracking - Prefix Sums - Dynamic Programming - Greedy Algorithms - Topological Sort This is where you move from “can solve problems” to “can solve tough problems quickly.” 3// Category 2 – Going Above and Beyond If you want to really separate yourself, go above and beyond, tackle these topics.  - Monotonic Stacks & Queues - Union-Find - Data Structure Design - Set & Map Implementations - Tries - Graphs (Advanced) - Dynamic Programming (Advanced) - Bit Manipulation - Math Don’t chase 100 topics at once. Start from the core, then build up. When you master the right order, you’ll never feel lost in an interview again.

Hard Truth: Data Structures - The Unavoidable Interview Reality Here's a pattern I've noticed recently that every software professional needs to hear: Even if you haven't used a binary tree in years, you WILL face data structure questions in your next interview. Here's why this matters: The Interview Reality Check: 1. FAANG-level companies:    - Will absolutely grill you on data structures    - Expect implementation from scratch    - Want optimal solutions 2. Startups:    - May seem more relaxed    - Still include DS questions in their process    - Use them to evaluate problem-solving 3. Even Frontend Roles:    - React state management? That's a tree    - Event handling? Welcome to queues    - Browser history? That's a stack What I've Observed: - Brilliant developers failing interviews because they're rusty on basics - Senior engineers stumbling on LinkedList questions - Tech leads getting rejected for missing optimal solutions The Smart Approach: 1. Keep a "DS Emergency Kit":    - Arrays & String manipulation    - Hash Tables implementations    - Tree traversals    - Graph basics    - Stack & Queue operations 2. Monthly Refresh Routine:    - Solve one problem per structure    - Review time complexities    - Practice explaining your approach Common Mistakes: - Thinking "I don't use this at work, so I won't study it" - Starting interview prep too late - Focusing only on coding, ignoring theory Quick Tips: 1. LeetCode Medium is your friend 2. Always write clean code in interviews 3. Think aloud during problem-solving 4. Review basic implementations monthly Core Data Structures You MUST Know: 1. Arrays    - What: Continuous memory blocks    - Why: Foundation of most data operations    - Real use: Instagram's photo feed, Spotify's playlist management 2. Linked Lists    - What: Connected nodes with next/prev references    - Why: Dynamic memory allocation    - Real use: Undo/Redo functionality in text editors 3. Hash Tables    - What: Key-value pair storage    - Why: Lightning-fast O(1) lookups    - Real use: Database indexing, caching systems 4. Stacks (LIFO)    - What: Last-In-First-Out structure    - Why: Track execution context    - Real use: Browser history, Function call management 5. Queues (FIFO)    - What: First-In-First-Out structure    - Why: Order preservation    - Real use: Print spoolers, Message queues in distributed systems 6. Trees    - What: Hierarchical data structure    - Why: Organized data relationships    - Real use: File systems, DOM in web browsers 7. Graphs    - What: Nodes connected by edges    - Why: Complex relationship mapping    - Real use: Social networks, Google Maps, Netflix recommendations 1. Practice implementing from scratch 2. Study time complexity for each operation 3. Learn when to use which structure Action Items: 1. Pick one structure weekly 2. Implement it in your preferred language 3. Solve 2-3 related problems 4. Document real-world applications

I've interviewed over 100 candidates at Google and another 50 at my previous company, BlueStacks. Over the years, I've seen a lot of common patterns of mistakes that candidates make. Here are the top ones: --Before the interview-- ❌ Not researching the interviewer or the company. You should always take the time to learn about the interviewer (Stalking them on LinkedIn?) and the company before your interview. This will help you understand the type of questions they might ask and the kind of solutions they're looking for. ❌ Not knowing the level you're interviewing for or the type of interview. This will help you prepare for the right kind of questions(e.g., design round, coding round, etc.). ❌ Overpreparing on the behavioral aspect for an early career position. For early career tech interviews, the focus is typically on coding and problem-solving skills. Leadership and behavioral questions become more important for more senior positions. --During the interview-- ❌ Not knowing the format of the interview. Clarify expectations with the interviewer or recruiter to ensure your time is optimized, preventing unexpected shifts. ❌ Jumping right into the code without asking clarifying questions. This is the biggest red flag from the interviewer's side. Take your time and spend some time understanding the problem ❌ Not explaining your thought process. Interviews are not about the end result but how you get there so think out LOUD. ❌ Not dry-running your code. The last thing you want is for the interviewer to find a bug in the code. ❌ Not mentioning the space-time complexity of your code. This shows the interviewer that you understand the performance implications of your code. ❌ Not proposing alternatives or improvements to your code or the problem itself. This shows the interviewer that you're able to think critically about your code and that you're always looking for ways to improve (Growth mindset). --On the code side-- ❌ Writing bad code and not using language features. For a 20 mins solution, it doesn't make sense to implement the Stack class yourself. ❌ Not using proper abstractions (the extra mile). Great programmers always encapsulate the logic behind interfaces and APIs. ❌ Not calling out potential design patterns, algorithms, and coding techniques. This shows the interviewer that you are SKILLED IN YOUR ART FORM, in other words, you have a deep understanding of computer science. If it's just the code that matters, why you should even talk about alternatives, call out patterns and time complexities, and think out loud? Answer: Programming can be thought of as an art form: Mastering algorithms, time complexity, and abstractions is akin to an artist's mastery of brushwork and color theory, which elevates your work from mere functionality (or drawing) to a well-written program (or craftsmanship), reflecting your dedication to coding's artistry. #programming #softwareengineering #codinginterviews #interviewersperspective #coding

What's it REALLY like interviewing as a freshie at Motive? Since announcing the fresh grad program, my inbox has been flooded with questions about the interview process. Funny enough, just a year ago I was in your shoes. Let me break down the ENTIRE process: This is a long post, so sit tight. First thing, everyone gets a CodeSignal assessment. No CGPA filter. 70 minutes for 4 questions. Q1 & Q2: Leetcode easy Q3: Implementation heavy with edge cases Q4: Between medium and hard (needs optimal solution) My suggestion? Tackle them: Q1 -> Q2 -> Q4 -> Q3 Patterns my friends and I noticed last year: Sliding window, Two pointer, Hashmap, Stack, Tries Aim for at least 500+/600 to be safe. Then the real fun begins… Every. Single. Interview. Matters. None are a formality. They're assessing both your technical AND communication skills. Technically - they don't expect k8s knowledge or latest Nextjs quirks. They want SOLID FUNDAMENTALS. Frontend? Know JavaScript and core web concepts. ML? Know the MATHS behind everything. Communication-wise, they're watching how effectively you talk about past experiences. - Each project or internship you mention? - Those impressive metrics on your resume? Be ready to break down what u did & how you achieved those numbers. They will dig deep, and so KNOW YOUR SHIT. The interview flow: (The exact sequence might vary) 1. HR Screening Standard HR questions about your resume, experiences, FYP. They'll ask about your interests to set your interview track. 2. Two Engineering Manager Rounds These are conversational interviews that mix: - Non-leetcode technical domain knowledge - Resume deep dive (be ready to explain EVERYTHING) - Behavioral questions That "most challenging technical problem" I asked about in referral emails? This is where it shines. To better prepare for the behavioral part: https://lnkd.in/dwEaq-Sf 3. Two Leetcode Coding Rounds Classic leetcode-style problems to solve live. Think out loud. They care about your thought process just as much as the solution. 4. Domain Specific Interview This is where theory meets practice. You'll solve a problem that mimics actual work at Motive. This interview varies significantly between FE, BE, and AI tracks since each functional area has its own unique challenges. If you've worked in your domain, this should feel natural. And remember… Be in BEAST confidence mode throughout. They're also gauging how coachable you are throughout. Your ability to take feedback matters BIG TIME. Is this a lot of interviews? Yes. But the culture, work-life balance, environment, and package at the end? Worth. Every. Minute. Good luck, future colleagues.

After giving & conducting 100+ coding interviews over the past 12+ years at startups and MAANG+ companies, I’ve realized one thing: —Interviews aren’t about who writes the most code. —they’re about who thinks in the most structured way. Here are 30 key insights I’ve learned from sitting on both sides of the table - as an interviewee striving to prove my skills and as an interviewer evaluating candidates:   - Communicate trade-offs clearly - Test your code with multiple cases - Start with a brute force, then improve - Clarify edge cases & constraints early - Know when to trade-off time vs. space - Explain time & space complexity upfront - Know when to use BFS vs. DFS in graphs - Optimize only after correctness is ensured - Don’t overcomplicate: simple solutions win - Think out loud & show your thought process - Handle errors & unexpected inputs gracefully - Use stack for problems with nested structures - Understand system design even at junior levels - Recognize patterns (many problems are variations) - Cache results for repeated calculations (Memoization) - Understand when to use heaps & priority queues - Confidence matters(believe in your approach) - Master sliding window for subarray questions - Use binary search for optimization problems - Use modular functions for better readability - Know when recursion vs. iteration is better - Use meaningful variable & function names - Write clean, readable, and modular code - Divide & conquer for large problem sets - Refactor before finalizing your solution Understand the problem before coding - Use two pointers for array problems - Use hash maps for quick lookups - Know how to debug efficiently At the end of the day, coding interviews aren’t about memorization, they’re about structured thinking.  Which lesson do you wish you knew earlier?

In the last 10 years, I've applied to almost all the MAANG+ companies for Cloud & DevOps positions:  - Applied Twice at Google - Applied to Microsoft (Cleared 3 rounds) - Applied to Amazon Twice - Applied to Meta (for Production Engineer_ - Had a chance to sit in for the SRE interview at Apple Each time, I went through the hiring processes, I learned a lot from my experiences regarding industry standards & my skills. Here are my learnings from all the interviews (insights that are rarely talked about)  1. Confidence Opens Doors - Walk in with confidence, but back it up with examples from your work.   – Show them how you’ve done similar things before or learned fast on the job.  - Give specific examples of how you created solutions, the more detail you give, the more genuine you seem  2. Talk Out Loud: They Care About Your Thinking Process   - Coding rounds are less about the final answer and more about how you think.   - Always explain why you chose this algorithm, data structure, or approach.  - Example: If I ask you to sort a linked list and array, explain how you’d handle each input without hardcoding.   3. Problem-Solving >>> Memorization   - You won’t be asked standard questions all the time. –They want to see if you can break down problems into smaller steps.   – Focus on understanding the problem statement first.   - Example: At Google, questions often started vague, like “Optimize Spark performance.” You had to ask questions to clarify the scope before jumping in.   4. Business Impact > Fancy Code  - Interviewers love candidates who think about real-world impact, how their work improves systems, reduces costs, or handles failures.  - Don’t just explain your code. Say, “This approach scales better because…” or “This method reduces downtime during outages.”   5. Expect Tricky Questions & Learn to Adapt   - You’ll get questions that test your ability to learn on the go.   - They don’t expect you to know everything but want to see if you can stay calm, ask the right questions, and figure things out.  - Example: Amazon asked about migrating hot and cold storage. Even without prior experience, the key was breaking the problem into steps and proposing ideas.   6. Failures Are Normal, Show How You Recover  - Big Tech doesn’t expect perfect systems, they expect fail-safes.   - Prepare examples where something failed, and you recovered quickly.  - Example: They asked about a time when servers went down during peak hours. My answer focus was on how recovery systems reduced downtime instead of avoiding failures completely.   7. Simplify Your Approach. Don’t Overcomplicate   - Many candidates try to impress with complex answers and overengineered solutions. Don’t.   - Focus on clarity and efficiency. Explain why you’re choosing one approach over another.  - Example: For a database optimization question, start with indexing strategies before diving into custom caching layers.  Continued in the comments ↓

Our interviews are designed to evaluate your strong computer science fundamentals and your ability to learn. We focus on two key areas: • Behavioral (Communication and alignment with Microsoft Core Values) • Technical (Problem-Solving Methods, Coding, and System Design) TECHNICAL Problem Solving • Ask Clarifying Questions: Ask clarifying questions upfront to fully grasp the problem before diving into code or design. This avoids wasting time on incorrect assumptions. Interviewers want to see how you break down the information and how you are powering through the problems • Talk about your approach: Show your structured approach to problem-solving rather than trying to guess what the interviewer wants. • Time Management: This is important given the short 45–60-minute interview round. Ensure that there is a strong transition from your problem-solving methods into implementation. Coding Guidelines • Code Cleanliness: Write clean, concise, and bug-free code without using pseudocode. • Language Proficiency: Use your strongest programming language effectively. • Data Structures: Understand common data structures (arrays, strings, queues, linked lists, trees, hash maps, graphs) and their applications. • Algorithms: Review algorithms like recursion and sorting, focus on efficiency (big O notation). Discuss their tradeoffs. • Testing: Test your solutions thoroughly, considering edge and corner cases and potential issues. Make sure you have a test driven solution • Optimization: Provide the most optimal solution first; if not possible, suggest improvements. Do not overcomplicate your solution. System Design Guidelines • Ask clarifying questions, state the functional and non-functional requirements • Understand software design fundamentals such as scalability, distributed systems, SOA, and n-tier architecture. • Familiarize yourself with software system design diagrams and scalability concepts (caching, load balancing, non-relational databases, microservices, and sharding). • Review object-oriented design and Service-Oriented Architecture (SOA) principles.