Tips to Navigate the Developer Interview Process

I’m a Senior Software Engineer Working at Meta in London with 8 years of experience. I’ve also worked at Microsoft, Amazon, and Google…. Here are the best tips I can give for coding interviews that helped me generate results in my own journey. I hope they do the same for you: 1. repeat the question out loud You don’t get points for jumping in. Saying the problem in your own words slows things down, helps you process, and uncovers anything you might have missed. It’s your first defense against stupid mistakes. 2. clarify every assumption Never assume anything is “obvious.” Ask if input can be negative, if it can be empty, if duplicates matter. Most candidates trip on what wasn’t said, not what was. 3. confirm language and libraries Ask if you can use built-ins or language features. Don’t waste 10 minutes reinventing a data structure if you don’t have to. Saves your energy for the real problem. 4. check input size and constraints “How big can N be?” “Does it fit in memory?” You need this to pick the right approach. Real-world code fails not on logic, but on scale. 5. build your own test cases Don’t just use their sample. Make up weird edge cases, empty arrays, all-duplicates, single values. That’s where bugs hide. 6. talk through your example, step by step Show your logic out loud: “At i = 2, value is 5, so I…” This is how you catch logic errors before you write a single line. 7. don’t code until you and the interviewer agree on the plan Rushing to code is a rookie mistake. Make sure both of you are on board with your approach, even if it means repeating yourself. 8. say your brute-force idea out loud, then immediately ask if you can do better No shame in starting basic. The magic is in saying, “but that’s slow, can we optimize?” Shows depth and hunger. 9. compare two or three approaches Spell out the pros and cons. “This is O(n^2), but easy. This is O(n log n), but needs sorting.” The interviewer is judging your thinking, not just your code. 10. define what ‘optimal’ means for this problem Time? Space? Simplicity? Don’t guess, always ask. Sometimes the “optimal” answer is the one that’s easiest to maintain, not fastest. 11. state your plan clearly before you code Even if it’s obvious, walk through your steps. Structure is everything. If you’re clear before you code, your code will be cleaner. 12. write real code, not pseudocode In the interview, pseudocode won’t cut it. Practice until you can write clean, correct syntax under pressure. 13. narrate your code as you write Talk through what you’re doing: “Here I’m initializing the map…” Keeps you engaged and helps the interviewer follow your thinking. 14. use variable names that actually mean something Don’t be lazy, name your stuff so it’s readable. You’re not showing off; you’re showing you care about maintainability.

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?

The resume was strong. The coding round went fine. Then the interviewer asked why, and everything slowed down. Because interviews aren’t just about what you built… They’re about whether you can explain, reason, decide, and think like an engineer when the pressure hits. Here’s how to prepare the right way - not just for answers, but for understanding: 1. Know the Role Clearly Understand responsibilities, required skills, and success metrics. 2. Study the Job Description Deeply Decode the real expectations behind every requirement. 3. Strengthen Core Technical Fundamentals Revisit core concepts that drive engineering decisions. 4. Choose One Primary Tech Stack Become strong in one stack before branching out. 5. Improve Structured Problem-Solving Work through problems step-by-step with clear reasoning. 6. Practice Coding Consistently Build speed, confidence, and familiarity with patterns. 7. Focus on Conceptual Understanding Know how things work, and why. 8. Build Practical Projects Show applied skills and independent thinking. 9. Explain Your Projects Confidently Discuss architecture, trade-offs, and what you’d improve. 10. Learn System Design Fundamentals Understand scalability, bottlenecks, and reliability basics. 11. Prepare Common Interview Questions Reduce cognitive load by practicing structured answers. 12. Do Mock Interviews Regularly Train under pressure before the real thing. 13. Communicate Your Thoughts Clearly Good communication shows clear thinking. 14. Prepare Behavioral Stories Use real experiences to demonstrate ownership and growth. 15. Learn From Every Rejection Refine your approach after each attempt. [Explore more in the post] The candidates who stand out aren’t the ones who memorize answers, they’re the ones who understand their choices. If you can explain why you solved something a certain way, the interview becomes a conversation, not a test.

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 ↓

📍One mistake I made in my early interviews was failing to present my projects clearly. I knew the work inside out, but I couldn’t explain it in a structured way — and that cost me opportunities. Over time, I realized that interviewers aren’t just looking for what you built, but how you communicate your impact. Here’s a framework that can help you explain any project with clarity: 🔹 Context / Background Start with a quick snapshot of the project. What was the situation? Why was the project important? Keep it concise, something you can explain in under a minute. 🔹 Problem You Tackled Highlight the exact challenge. What issue did you or your team face? Why was it worth solving? This sets the stage for your contribution. 🔹 Your Contribution Be specific about your role. Did you design, code, test, lead, or optimize? Talk about key tasks you handled, roadblocks you hit, and how you overcame them. 🔹 Solution Approach Walk through how you solved the problem. Break it down into steps so the interviewer can follow your thought process — from the initial idea to the final execution. 🔹 Tools & Tech Mention the technologies, frameworks, or methods you used. This shows your technical decision-making ability and how you apply the right tools for the job. 🔹 Results & Outcomes Quantify the impact if possible. Did you improve performance by 30%? Save the team hours of work each week? Secure positive client feedback? Numbers and concrete results make your contribution stand out. 🔹 Collaboration & Learning Close by talking about teamwork and personal growth. How did you coordinate with others? What new skills did you pick up? What would you approach differently if given another chance? ✅ Remember: An interview isn’t just about what you built — it’s about showing your ability to identify problems, craft solutions, and communicate them clearly. #InterviewTips #CareerAdvice #ProjectShowcase #SoftwareEngineering #InterviewPreparation #CommunicationSkills #TechCareers #ProblemSolving

After taking 75 Software Engineer interviews at Google in < 7 months, I’ve seen a range of mistakes all of us make in coding interviews. Here’s a compiled list to help you (and me) avoid these pitfalls in our future interviews! 1️⃣ Not Clarifying Requirements > Many candidates jump straight into coding. Often without fully understanding the problem. This can waste time and lead to errors. Tip: Always ask clarifying questions. To ensure you get the requirements. Confirm edge cases and input constraints early on. 2️⃣ Overcomplicating Solutions > In the heat of the moment, it is easy to overthink a problem. And this complicates the solution, both for you and your interviewer. Tip: Start with a brute-force approach (just explain it), then iterate towards optimization (code it up). Easy-to-understand solutions get bonus points. 3️⃣ Under-Communication > Interviews are not just about coding. They’re also about conveying your thought process. Silence takes away the only help you have during the interview—your interviewer. Tip: Think out loud! Explain your reasoning and approach as you code. This helps the interviewers understand you and even guide you if needed. 4️⃣ Ignoring Edge Cases > Many candidates create a working solution. But fail to consider edge cases. This can lead to catastrophic failures. Tip: After arriving at a solution, always discuss potential edge cases. Explain how your code handles them. This shows your thoroughness. 5️⃣ Neglecting to Optimize > Even if your solution works, failing to consider optimization can cost you points. Tip: After solving the problem, re-read your solution and discuss ways to improve time and space complexity. No micro-optimizations. Interviewers appreciate candidates who think about efficiency in big-oh notation. 6️⃣ Skipping Dry Runs > 80%+ candidates skip the dry run of their code, leading to overlooked mistakes. Tip: Walk through your code with sample inputs. This helps catch errors early and makes you look proactive. 7️⃣ Getting Flustered > Interviews are stressful. And it is easy to panic if you hit a roadblock. Tip: If you’re stuck, ask for a minute or 2 to gather your thoughts. Ask for hints if necessary—interviewers appreciate candidates who are willing to seek help. Those were my 2 cents on how to tackle coding interviews. But believe it or not, the best way to realize your interview mistakes would be to start taking interviews (even mock ones). After conducting so many interviews at Google, I realized how I often fell into the same traps as everyone. Like going completely silent or forgetting to do a dry run for the interviewer. Taking interviews altered my perspective, and now I advise everyone preparing for interviews to take a couple of them first. Total game changer! #codingInterviews #jobPrep #softwareEngineering #Google #interviewTips

After guiding over 10 engineers through recent interviews at NVIDIA, I realized something surprising.   Many of us trip up on the exact same things. I know I certainly did earlier in my journey.   While every loop is unique, the fundamentals of a strong engineering discussion remain consistent.   If you are prepping for a ASIC RTL role, here is the playbook I wish I had earlier in my journey:   1. The Resume Deep Dive : The biggest mistake? Not knowing your own data. Don’t just list what you did; know the specific numbers and the why behind them. -Why did you choose that architecture? -What were the specific trade-offs? Top-tier teams drills down to find the curiosity behind the implementation.   2. Visuals always Wins : When asked an open-ended architectural question, stop talking and start drawing. -Whether it’s MS Paint or a whiteboard, sketch your thought process -Draw the waveforms (even for simple logic). It shows you can communicate complex ideas clearly and verifies your thinking.   3. Embrace the Vague : Some questions are intentionally vague. They aren't looking for a quick answer; they are looking for you to fill the gaps. -Ask clarifying questions. -State your assumptions out loud.   4. The Trade-off Mindset : There is rarely a "perfect" solution. It’s always a balance of PPA (Power, Performance, Area). For Seniors: Go beyond the block level. Discuss scaling, verification challenges, software impact, and complexity.   5. The "Curveball" : Be ready for questions intentionally designed to throw you off. -Often, candidates let one tough moment derail the entire interview. Recognizing you are stuck and resetting is a skill in itself.   Don’t just answer the question, show how you engineer the solution.   #NVIDIA #RTLDesign #HardwareEngineering #InterviewTips 

In the last eight years, I have interviewed 500+ Software Engineers for various roles. Here are the most actionable tips I can give you on how to do better during your behavioral round. 1/ Set the Stage Clearly - Describe the Situation or Task that needed solving. Focus on the challenge. - Example: "The API response times were too slow, affecting user experience, and I was tasked with optimizing it within a sprint." - Keep it short. If the interviewer wants more details, they’ll ask. 2/ Focus on Key Actions - Highlight 3 core actions you took to solve the problem. - Example: "I profiled the API calls, implemented caching for frequent queries, and reduced payload size by 30%." - Stick to impactful actions. Each action should take under 2 minutes to explain. 3/ Use “I” to Show Ownership - Make it clear what you did to demonstrate leadership and initiative. - Example: "I spearheaded the migration from monolithic architecture to microservices, improving scalability by 40%." - Avoid saying "we" too much. The interviewer needs to know if you led the effort or just contributed. 4/ Stick to Facts, Avoid Emotions - Keep your answers factual, even when discussing challenges. - Example: Instead of "I was frustrated with a teammate’s slow progress," say, "I scheduled a pair programming session to help them meet the deadline." 5/ Understand the Purpose of the Question - Think about what the interviewer is trying to assess—teamwork, problem-solving, leadership, or technical expertise. - Example: If asked about handling conflict, they want to see how you navigate disagreements productively. Frame your response accordingly. 6/ Use Data to Back Your Results - Quantify your impact wherever possible. - Example: "After optimizing the query logic, I reduced database read times by 40%, cutting down page load times by 2 seconds." - Data shows real impact and demonstrates the value you bring. 7/ Keep It Interactive - Make your responses concise to encourage follow-up questions from the interviewer. - Example: "I automated the deployment pipeline, cutting release times from 2 hours to 15 minutes. If you'd like, I can explain the challenges I faced setting up the CI/CD tools." 8/ Maintain good eye contact -Eye contact showcases confidence -In the era of online interviewing, it’s even more critical to showcase your focus via eye contact. And one thing you should never do in the behavioral interview is makeup details. It’s visible how shallow a story is if someone grills you on the details. I hope these tips will help you achieve great results. – P.S: Follow me for more insights on Software engineering.

I'm often asked what to do if one can't solve a coding problem after pondering it for 15-20 minutes. People often hit a wall while preparing for coding interviews. I did too. Here are my suggestions: 👉𝐏𝐫𝐚𝐜𝐭𝐢𝐜𝐞 𝐀𝐜𝐭𝐢𝐯𝐞𝐥𝐲: Instead of passively reading the explanation after 15-20 minutes, try to struggle with the problem a bit longer. This is where the learning really happens. If you can't solve it, try to identify which part of the problem you find challenging. Is it the initial approach? Is it a tricky corner case? Once you've identified your weak point, you can then focus on solutions to that specific issue. 👉𝐔𝐧𝐝𝐞𝐫𝐬𝐭𝐚𝐧𝐝 𝐭𝐡𝐞 𝐂𝐨𝐧𝐜𝐞𝐩𝐭𝐬, 𝐍𝐨𝐭 𝐉𝐮𝐬𝐭 𝐭𝐡𝐞 𝐒𝐨𝐥𝐮𝐭𝐢𝐨𝐧𝐬: While it's tempting to memorize solutions, the interviewers are more interested in how you think and approach a problem. So, focus on the underlying techniques, patterns, and algorithms. Once you deeply understand a concept, you'll be able to apply it to a variety of questions. 👉𝐒𝐩𝐚𝐜𝐞𝐝 𝐑𝐞𝐩𝐞𝐭𝐢𝐭𝐢𝐨𝐧: Instead of reviewing all questions every day, use the spaced repetition technique. For example: 1. Review a question you've solved today. 2. Review it again in two days. 3. If you solve it successfully, review it again in a week. 4. If you still solve it successfully, review it again in two weeks. This technique will help you remember the approach over the long term. 👉𝐃𝐢𝐬𝐜𝐮𝐬𝐬 𝐰𝐢𝐭𝐡 𝐏𝐞𝐞𝐫𝐬: Talking through your solution, or even your confusion, with someone else can be very beneficial. This could be in online forums, study groups, or with friends preparing for similar interviews. Explaining your thought process to someone else can help solidify your understanding. 👉𝐂𝐚𝐭𝐞𝐠𝐨𝐫𝐢𝐳𝐞 𝐏𝐫𝐨𝐛𝐥𝐞𝐦𝐬: Many problems can be grouped together into certain categories like sliding window. Once you've solved a few problems in a category, try to summarize the general approach that apply to that category. This way, when faced with a new problem, you can try to fit it into a known category and apply the corresponding techniques. 👉𝐌𝐨𝐜𝐤 𝐈𝐧𝐭𝐞𝐫𝐯𝐢𝐞𝐰𝐬: Consider mock interviews with friends or using platforms that offer this service (check https://lnkd.in/gwrarnyD). This not only helps with problem-solving but also gets you comfortable with explaining your thought process. 👉𝐕𝐚𝐫𝐢𝐚𝐭𝐢𝐨𝐧 𝐢𝐬 𝐊𝐞𝐲: Instead of solving similar problems repeatedly in a short span, try a mix. For instance, after two-pointer problems, move on to recursion, then sliding window, and then come back to two-pointers. This cyclic variation helps cement your learning better. 👉𝐔𝐧𝐝𝐞𝐫𝐬𝐭𝐚𝐧𝐝 𝐌𝐢𝐬𝐭𝐚𝐤𝐞𝐬: Whenever you can't solve a problem, instead of just reading the solution, ask yourself why you couldn't solve it. Is there a pattern or concept you're consistently missing? By recognizing your weak spots, you can focus on improving in those areas. #codinginterview #datastructures

How to Do Well in a Coding Interview I have been interviewing a lot of engineers lately. The strongest candidates make the same moves, and none of them involve writing perfect production-ready code. They show that they can actually code, think clearly, and work through problems without getting lost in the weeds. A few things that consistently stand out: 🔹 Communicate as you go Talk through your reasoning. Let the interviewer see your thought process instead of silently typing and hoping it passes. 🔹 Explain your decisions Why you picked a certain data structure or approach matters. The interviewer is assessing your ability to make decisions, not just follow a pattern. 🔹 Do not get stuck on tiny details Nobody cares if you forget a semicolon or the exact method name on a library. Stay focused on solving the problem, not chasing minor syntax issues. 🔹 Keep it simple and avoid premature production quality In interviews, hardcoding values is fine. You can say, “In production I would use environment variables here” and keep moving. That shows awareness without sinking time into setup. 🔹 Have your setup ready Test your IDE or coding environment before the call. A clean start helps you build momentum quickly. Also, make sure your computer is charged! 🔹 Ask clarifying questions Good engineers remove ambiguity. Make sure you understand the problem before writing code. 🔹 Start with the simplest version Get a working baseline, then talk about how you would handle edge cases, performance issues, or scaling. This proves you can walk and then run. 🔹 Stay calm when you get stuck Everyone hits friction. What matters is how you recover. Say what you tried, explain why it did not work, and pivot. Coding interviews are not about perfection. They are about problem solving, communication, and your ability to move forward with clarity under pressure. Nail those and you show what really matters: you can deliver. Anything else you’d add?