Coding Techniques for Technical Interviews

I interview 2 Senior / Staff Engineers at Meta every week for E5 and above roles. If they asked me how to perform better in coding interviews, I would start with these 3 things. These are people with 8, 10, 15 years of experience. 1. Treat the interview like a joint problem-solving session When I ask an algo question, I want to hear your thought process from the first minute. Start wide, then narrow: - First: state the brute force   If I do this in the simplest way, I would:   a) scan all elements,   b) try all pairs or all paths,   c) this gives time O(N²) and space O(N²). - Second: show that you respect constraints   Now, if N is 10⁵, O(N²) will not work. So I will look for something closer to O(N log N) or O(N). - Third: propose concrete options   Option 1: sort and scan with two pointers, complexity X.   Option 2: use a HashMap and one pass, complexity Y. Then ask: Given these options, which path would you prefer I implement first This does a few important things: - It shows you understand trade-offs, not only syntax. - It gives me a chance to correct your direction early. -  It proves you are not guessing. If your first solution is not optimal and I ask for a better one, keep the same structure: offer two ways to improve, sketch pseudocode, confirm the choice, then code. 2. Enunciate while you code One of the hardest interviews to conduct is when the candidate goes silent and types for 20 minutes. As an interviewer, I am sitting there thinking: - Are they stuck - Are they copying a pattern from memory - Do they even know what this line is doing You can fix this just by speaking while you code. Example of what I want to hear: - I am creating this array to store prefix sums. - This loop walks the list once and builds the map from value to index. - This condition picks the earliest valid index for the answer. Now I do not have to reverse engineer your solution. I can follow your logic in real time. I know you understand your code. You also get an extra benefit: if you say something and your code does something else, you will catch that mismatch yourself. Strong communication here is not about fancy English. You can speak in simple language as long as the mental model is clear. 3. Dry run your code Too many candidates write the final line and look up, waiting for a verdict. A much better move is to verify your own work: - Take the example input from the problem. - Feed it through your code step by step. - Say out loud what each variable holds after each key step. For example: - After the first iteration, the stack contains these indices. - Here we update the answer from 3 to 5 because the condition is true. - At the end of the loop, we return 5, which matches the expected output. Two good things happen: - You often find your own typos, off by one error or edge cases. - You show that testing and verification are part of how you think, not an afterthought.

7 general tips that helped me get 300% better results at coding interviews and flipped my results from rejections to success (Salesforce, Atlassian, Deliveroo, Uber). If you have a Leetcode-style round coming up, pay attention. [1] Start with constraints before you touch the keyboard - Ask 4 to 6 sharp questions on input size, value range, edge cases, and “impossible” scenarios. - Use those answers to rule out dumb ideas in your head instead of jumping into half-baked solutions. - Say it out loud: “Given these constraints, O(n²) will / will not fly, so I am thinking of pattern X.” [2] Always show the brute-force path first, then walk to the better one - Sketch the simplest correct idea in plain language, even if you would never code it in production. - Use it to introduce your data structures, invariants, and what “valid answer” means. - Then upgrade: “This works in O(n²). To make it scale, I will turn this into a sliding window / hash map / BFS.” [3] Name the pattern early so the interviewer can follow your mental model - Say what you see: “This feels like a sliding window problem” or “This is BFS on a grid with extra state.” - Anchor the discussion on that pattern so the interviewer knows you are not guessing randomly. - Reuse that pattern vocabulary while you code: “left and right pointer”, “current window state”, “queue of positions”. [4] Dry-run your idea on the example like a human interpreter - Before coding, walk through the example exactly like in the video: move pointers, grow and shrink windows, run BFS layers. - Say where your current state is stored: “target map”, “current frequency”, “distance matrix”, “matches vs needed”. - Use the dry run to catch missing pieces early, like duplicate counts, disconnected components, or off-by-one mistakes. [5] Code in small, logical chunks, instead of one giant block - Set up core structures first: maps, counters, queues, and pointers, and say why each one exists. - Implement one clear loop or helper at a time, then mentally test it on part of the example before moving on. - Keep your names meaningful so you can talk through them: targetFreq, currentMatches, needs, distanceGrid. [6] Talk through trade-offs instead of just time complexity formulas - After you finish, do more than “O(n + m), O(1) space”. Say what actually makes it faster than the naive version. - Call out where it can break in real systems: duplicates, empty cases, disconnected components, large grids, long strings. - Mention alternatives briefly: “We could also do X, but it would recompute too much / use too much space.” – P.S: Say Hi on Twitter: https://lnkd.in/g9H82Q98 — P.P.S: Feel free to reach out to me if you're preparing for a switch, want to chat about interview preparation, or how to move to the next level in your career: https://lnkd.in/guttEuU7

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?

7-Step Framework to Answer 90% of Coding Problems (Based on My Experience at Walmart, Samsung, & Microsoft) 1. Clarify the Problem - Understand the input and output requirements. - Ask about edge cases and constraints (e.g., data size, negative values). - Confirm expected time and space complexity. 2. Break It Down - Identify the core problem type (e.g., sorting, searching, graph traversal). - Divide the problem into smaller, manageable subproblems. - Discuss a brute-force approach first, then optimize step by step. 3. Choose the Right Data Structure - Arrays or Lists for sequential data. - HashMaps for fast lookups. - Stacks/Queues for order-sensitive operations. - Trees/Graphs for hierarchical or connected data. 4. Plan the Algorithm - Write down the pseudocode or flow in plain language. - Choose between iterative or recursive solutions based on the problem. - Think about sorting, traversals (DFS/BFS), or divide-and-conquer strategies. 5. Write the Code - Start with a clean and simple implementation. - Focus on edge cases (e.g., empty arrays, single elements, negative numbers). - Add comments to explain your logic as you write. 6. Test and Debug - Use sample inputs to validate your solution. - Cover edge cases, stress-test with large inputs, and compare outputs. - Optimize if it doesn’t meet the constraints (e.g., reduce nested loops). 7. Optimize and Explain - Discuss improvements: - Can time complexity be reduced (e.g., O(n^2) → O(n log n))? - Can space usage be minimized (e.g., avoid extra arrays)? - Clearly explain your solution and why it works for all cases. Practice this framework consistently with a variety of problems. The more you apply it, the easier it becomes to adapt it for any interview challenge. Consistency + Structured Thinking = Success in Coding Interviews. 🚀 Note: This approach works well for most problems but may not be ideal for every type of problem, so feel free to adapt it according to the specific nuances of the interview question.

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

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

I failed many coding interviews, but finally, 🚀 I’ve cracked them at Meta, Amazon, Netflix, Snap Inc., and Intuit. Here are lessons I wish I knew earlier 👇 🔹 Understand the problem first Don’t jump into coding. Clarify requirements, constraints, and edge cases. Sometimes it’s okay to defer handling complex edge cases and call them out as follow-ups. 🔹 Think in trade-offs, not just solutions If multiple approaches exist, explain each and discuss pros & cons. Talk about data structures and why you’d pick one over another. Recursive vs iterative: recursion may look elegant but comes with stack depth & memory costs. 🔹 Code quality matters Readable, modular code beats a clever one-liner. Use meaningful variable names (not just i/j). Add error handling when appropriate. 🔹 Testing mindset Don’t stop at “happy path.” Think about edge cases and how unit tests would catch real-world issues. 🔹 Communicate constantly Explain your thought process, decisions, and trade-offs as you go. This shows how you solve problems in real-world scenarios. 🔹 Stay calm under pressure Interviewers are testing problem-solving under pressure, not just correctness. 👉 For Senior/Staff+ SWE roles, interviews measure engineering judgment + clarity of thought more than speed. What’s one tip you wish you knew earlier in coding interviews? #InterviewTips #SoftwareEngineering #MAANG #EngineeringExcellence

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?

I struggled with my first few front-end interviews. Despite knowing frameworks well, I froze when asked to code a simple accordion component. One rejection feedback changed everything: "Strong technical knowledge, but couldn't apply it under pressure." After changing my approach, my interview performance improved significantly. Here's what worked: 1. Practice Building, Not Just Answering Most engineers memorize theories about closures and DOM. Instead, I did timed 30-minute sessions building actual components. When asked to code a star rating component in an interview, I'd already built something similar under pressure. 2. Explain Your DOM Structure First Before coding, I explained my planned HTML structure: "I'll use a container with button elements for each star, with proper aria attributes and SVG icons." This shows your thought process, catches issues early, and demonstrates accessibility awareness. 3. Talk About Performance Without Being Asked While coding, I proactively mentioned performance considerations: "I'm using a ref instead of state here because it doesn't need a re-render." "I'll debounce this input to prevent excessive function calls." This signals senior-level thinking. 4. Build Your Interview Component Library I documented each component I practiced, creating a reference library with: 🎁 Common UI components 🎁 Different implementation approaches 🎁 Accessibility and edge case notes This became my quick study guide before interviews. 5. Handle Error States Without Being Asked Always address what happens when things fail: "Now let's handle API errors and loading states...". This shows production-ready thinking, which distinguishes senior engineers. Front-end interviews are less about trivia and more about demonstrating how you work. These strategies helped me show what I knew more effectively. What techniques have worked for you?🚀

I analyzed the top 50 coding interview questions, and they all boil down to these 18 patterns. People ask me how to crack technical interviews without spending years on LeetCode. My secret? I don't memorize solutions. People ask how I identify the right approach for a brand new problem instantly. My secret? I look for the underlying pattern, not the specific question. But the truth is... There is no secret. Just pure Pattern Recognition. To master DSA, you have to stop treating every problem as unique. You need to map them to these 18 fundamental branches. Here is the technical breakdown to get you started: 1. Optimization & Pointers - Two Pointers: Essential for sorted arrays and linked lists. Use this to detect cycles (Floyd's algorithm), remove elements, or find target pairs in O(N) time. - Sliding Window: The standard for subarray problems. Perfect for calculating running averages, finding the longest substring under constraints, or optimization within a linear data structure. - Intervals: When dealing with time ranges or overlaps, use Merge Intervals or Catalan logic. 2. Search & Traversal - Binary Search: Beyond finding numbers. Use on rotated sorted arrays or to find "first/last occurrence" boundaries in O(log N). - Tree Traversal: Master the recursion. Know when to use Level-order (BFS) vs. Pre/In/Post-order (DFS) for tasks like serialization or finding the Lowest Common Ancestor. - Graph Traversal: Solves island counting, cycle detection, and topological sorting. 3. Complex Structures & Logic - Heaps: The most efficient way to handle "Top K" elements, scheduling tasks, or finding medians in a data stream. - Tries: The go-to design pattern for autocomplete systems, spell checkers, and prefix searches. - Backtracking: For when you need all possibilities. Used in generating permutations, N-Queens, and Sudoku solvers. 4. The Heavy Hitters - Dynamic Programming (DP): For overlapping subproblems. Includes 1D/2D arrays, Longest Common Subsequence (LCS), and the Knapsack problem. - Graph Optimization (Union Find): Critical for network connectivity. Uses Disjoint Set Union and MST algorithms like Kruskal’s or Prim’s. Want to be a software engineer? Stop memorizing. Start recognizing. Remember, seeing the pattern is 90% of the solution. The code is just syntax. Which of these patterns do you find most difficult to implement? ♻️ Repost to help a connection ace their technical interview.