Interview Math Lewis Lin Swwatchz

On the Interview Math Stuff for Software Engineering Roles

Most people preparing for SWE interviews don't actually know what they're signing up for when it comes to the quantitative side. The math portion isn't calculus or proofs. It's discrete math, probability, combinatorics, and basic statistics wrapped into algorithmic thinking. Lewis Lin covers this territory pretty thoroughly across his guides and his Interview Math Lewis Lin Swwatchz material, and the approach he takes is practical rather than academic. When I sat through technical screens and onsite loops at mid-size companies, the math questions came disguised as coding problems. You'd see something like: calculate the time complexity of a recursive solution, figure out the probability that two randomly selected elements from an array satisfy some condition, or determine the expected number of operations before a randomized algorithm terminates. The math is the scaffold. The coding is the building. Here's the thing nobody tells you upfront: you don't need to be good at math to do well on these questions. You need to be good at translating word problems into formal structures. A lot of candidates freeze because they read "expected value" and immediately panic about statistics. In practice, the interviewers want to see that you can set up the problem, identify the constraints, and walk through the logic out loud.

I remember one specific screen where the question asked me to find the expected number of flips to get two consecutive heads. Standard probability problem, right? The trap is that most candidates jump straight into solving it algebraically on the whiteboard without verifying their setup against small cases first. I spent four minutes deriving a formula that was actually wrong because I misread the boundary conditions. The fix was simple: I worked through the first three terms by hand, wrote out the state transitions, and only then set up the equation. Got it right in the remaining six minutes. That experience changed how I approach every subsequent problem.

Breaking Down the Core Topics

The territory breaks into roughly four buckets, and each one appears with different frequency depending on the company. This is the highest-yield topic by far. Every single technical interview will ask you to analyze the complexity of your solution, and several will give you a problem specifically designed to test whether you understand amortized analysis versus worst-case versus average-case. The common pitfall is confusing the two. Big O gives you worst-case. Theta gives you tight bound. Omega gives you best case. Interviewers will push you on these distinctions if you're sloppy. A useful trick that most people miss: when analyzing recursive solutions, draw the recursion tree. Visualize the work at each level, count the levels, multiply. It sounds elementary but candidates who try to apply the master theorem mechanically without understanding the tree structure regularly make arithmetic errors under pressure. I've seen people misapply the theorem because they didn't check whether the regularity condition held.

Probability and Expected Value

This shows up most often at companies like Google, Microsoft, and Uber. The questions range from straightforward coin-flip problems to more involved scenarios involving Markov chains or coupon collector variants. The key insight here is that expected value is linear, regardless of independence. E[X + Y] = E[X] + E[Y] always holds. This fact alone solves a significant portion of interview problems that look much harder than they actually are. Another counter-intuitive point: conditional probability questions in interviews are almost never about applying Bayes' theorem blindly. They're about setting up the sample space correctly and counting outcomes. I once encountered a problem asking for the probability that a randomly chosen path from the top-left to bottom-right of a grid avoids a specific cell. The naive approach is to count all paths and subtract those through the forbidden cell. The faster approach uses the reflection principle, but honestly, just writing out the combinatorics formula C(n+k, k) for each case and subtracting is cleaner under time pressure.

Combinatorics and Counting

Permutations, combinations, binomial coefficients, inclusion-exclusion. These appear less frequently than complexity analysis but show up in a concentrated way. The trick is recognizing which counting principle applies. If order matters and you're selecting without replacement, it's a permutation. If order doesn't matter, it's a combination. If you're overcounting and need to correct for it, inclusion-exclusion is your tool. I had a candidate once who could derive complex combinatorial formulas from memory but completely fell apart when asked to explain why the formula worked. That's the real test. Can you justify your answer, or can you only reproduce it? Interviewers can tell the difference within thirty seconds.

Basic Discrete Math and Number Theory

GCD, LCM, modular arithmetic, prime factorization, bit manipulation tricks. These show up most commonly in problems involving bitwise operations or cyclic patterns. The bitwise tricks are particularly high-value because they're fast to execute and demonstrate fluency with low-level representation. Knowing that x & (x-1) clears the lowest set bit, or that x ^ x = 0, or that n & (n-1) tests for powers of two — these are the kinds of facts that separate candidates who have memorized tricks from those who understand why the tricks work. The standard advice is to grind LeetCode problems and that's not wrong, but it's incomplete. The math-specific preparation requires a different approach. You need to study the underlying concepts separately from the coding problems, then practice integrating them. Start with resources like Lewis Lin's materials on Interview Math Lewis Lin Swwatchz to get a structured overview of what's actually tested. Then work through the probability and combinatorics chapters in a standard discrete math textbook. Rosen's "Discrete Mathematics and Its Applications" is the usual recommendation, though it's dense. For a more focused read, "Concrete Mathematics" by Graham, Knuth, and Patashnik is excellent but demanding.

Practice problems should come from three sources: LeetCode's tagged probability and math problems, the "Garrett's Advanced Mathematical Questions" collection that circulates in interview prep communities, and the classic problem sets from MIT's 6.042J course on discrete mathematics. The MIT problem sets are particularly useful because they're designed to build intuition, not just test computation. Here's a concrete schedule that worked for me when I was preparing: two weeks of concept study, one week of targeted problem practice, and three days of full mock interviews with timed conditions. The mock interviews are critical because the math questions feel very different under time pressure than they do when you're studying casually. I found that my accuracy dropped from about eighty percent to sixty percent once I added the timer constraint, so I deliberately practiced with a countdown clock from the start.

Common Mistakes and How to Avoid Them

The most frequent error is neglecting edge cases. A probability problem that asks for the expected number of trials until success assumes a non-zero probability of success on each trial. If the interviewer changes the parameters so that success is impossible under certain conditions, your entire formula breaks. Always check: does my solution handle n=0, n=1, and the case where the probability is zero or one? Another mistake is overcomplicating the answer. Interviewers often include a simpler approach alongside the elegant one, and the simpler approach is usually the one they want you to identify first. I've had situations where I spent eight minutes deriving a dynamic programming solution for a counting problem that could have been solved with a single combinatorial formula in thirty seconds. The interviewer's reaction was not encouraging. The worst mistake, in my opinion, is staying silent when you're stuck. If you hit a wall on a math problem, say so. "I'm not immediately seeing the clean approach here. Let me try working through small cases to get intuition." That buys you time and shows the interviewer you're thinking strategically about your problem-solving process. Most interviewers would rather see you recover from a mistake than watch you suffer silently for five minutes.

When the Math Approach Doesn't Work

There are scenarios where studying math extensively won't help much. If you're interviewing at companies that emphasize system design or coding proficiency over mathematical reasoning, the return on investment for deep math preparation drops significantly. The ratio of math questions to total interview time varies wildly: at some companies it's zero percent, at others it's thirty. Know your target before you invest heavily in this area. Additionally, if you have a genuine gap in your discrete math foundation, no amount of interview prep will close it in a few weeks. In that case, the practical workaround is to focus on pattern recognition — memorize the standard problem types and their solutions — rather than trying to build deep understanding from scratch. It's a second-best strategy but it's better than walking in unprepared. The tools and frameworks I've described here are based on actual interview experiences across multiple companies and roles. The math component is one part of a broader preparation process, and it deserves attention proportional to its weight in the interview. Don't ignore it, but don't obsess over it either. Find the right balance and practice under realistic conditions.