The advice we see everywhere online is to study coding interview problems, especially on LeetCode. This makes sense, especially since a majority of these large tech companies will need to evaluate your coding skills and can quickly assess you by asking about data structures and algorithms. This post isn’t about what coding problems to solve but is about the difference between solving the coding question and getting an offer.
My quick background
I’m a current software engineer at Microsoft who previously worked at Amazon and passed onsites at Google. I’ve done about 300 unique LeetCode problems with about 80% of them being medium difficulty. Yes, any current software engineer will think they know how to pass any onsite but here’s where my experience is different.
I’ve given interviews at Microsoft, and I interview at a lot of other companies for fun. Here’s what works.
The easiest improvement you can make on any interview
Communicate more. Involve the interviewer, treat them more like a coworker, not a proctor.
Before you code
Read the prompt out loud. If you can’t understand how the example input leads to the output, you don’t understand the problem. Ask the interviewer for clarification.
Give an example test case or possible edge case input and expected output. Then ask the interviewer if it’s correct. If it is, you won’t misinterpret the question.
Talk about the algorithm you’re going to use. Mention out loud what you’re thinking about and whether your approach will solve the question or not. Clarify if it’s a brute force method or any other reason why it’s optimal or not in terms of space and time complexity.
Directly ask your interviewer if they want you to code that solution or not. They’ll let you know if they’re happy with your approach or if they want you to give something more optimal where you will think out loud again.
Otherwise, they’ll be happy to see you start coding.
While you’re coding
Yes, half the interview assessment is if you can code a correct and optimal solution. LeetCode and FAANG interview culture mistaken believe that’s all it takes to land any offer. Here’s what they’re not telling you.
Code Out loud. Explain out loud what each line of code you’re writing is doing any what part of the algorithm you mentioned earlier is addressing. If your algorithm needed to use binary search, then as your coding that portion, refer back to the algorithm you previously outlined that you are now coding the binary search portion. Again, reference which part of your algorithm you outlined as you’re coding it.
Confirm the interviewer understands what you wrote. Slow down after you complete a portion of writing code and confirm with the interviewer if they understand what you wrote so far. If they don’t confirm or say anything, dry run your code with an example test case and talk about what the output should be up to the point you coded. If there’s a mistake, good job catching it early. If they don’t understand what you wrote at that point, you’ll make the mistake of writing overly complicated code the interviewer won’t approve of.
Talk about optimizations and bottlenecks as you go. There was already agreement on the algorithm you would already write so you don’t need to optimize on the spot. But mention as you’re coding if any portion is suboptimal, you recognize it, and you’ll come back to it afterwards. You don’t have to code the perfect solution on the first written iteration.
Point out what you’re going to code for later. There’s portions of code you don’t have to look at as you’re writing initially. I’ve been checked on null input in 25% of my interviews but I don’t always want to waste time on that if the interviewer is not interested. Put a comment mentioning //ToDo: Null Checks. You’ll come back to it if they care. If they don’t, you’ll be happy you saved time.
When you’ve completed your first iteration, ask the interviewer if they would prefer you to
- Dry run your code against the example inputs
- Optimize your code further
After your first written code iteration
You’re not done after you finished writing the algorithm you said you would. We don’t know if it actually works or not with the test cases we wrote. We don’t know what the interviewer wants you to do now. So ask instead of assuming what you should be doing. Because different interviewers care about different things.
Dry run your code against the example inputs. Go through your code and reference again what portion of code your coding is covering line by line. Yes, line by line. As you’re going through it, talk about what the state of the output should look like as you go along. If anything is unexpected, mention you’re going to fix it and work on it. The rest of the code is invalid if you’ve made a mistake and you don’t need to discuss further. Repeat until you’ve fixed all your bugs. Do this for each interviewer given example test case.
Optimize your code further. If there are bottlenecks in your code, point them out, explain why the bottleneck is there and what you’re going to do to optimize them. Talk out loud what you’re thinking and why certain approaches you’re thinking do or don’t work to optimize the algorithm. When you do come up with an improved solution, ask again if the interviewer is happy with that approach and if they want you to implement it or not.
At some tech companies you’ll be done here. At others, they’ll want a space and running time analysis.
The mistake everyone makes when asked about space and time complexity
They answer without showing their work. Never just assert to the interviewer your algorithm runs in O(logN).
As an example: You iterated through your input using binary search and it’s the only algorithm you used. Binary search goes through at most O(logN) elements as it processes elements in the input. What our algorithm does as it processes is a constant O(1) operation. Therefore, that’s why our running time is O(logN)
Do not answer space and time complexity, solve for it.
Solving for space and time complexity. You already went through your code line by line. This portion you can go through and see where your algorithm might be slow with talking out loud as much what the algorithm is doing. Look for data structure operations like add, remove as well as for-loops/while loops in your code that could be influencing space and time complexity and speak to that. Comment what those running times at those operations are. After reviewing the rest of your code, the bottleneck should be clear and you’ve effectively solved for the running time instead of just treating the question like an answer on a flash card.
If you enjoyed this experience consider being a member for more content like this!
Follow up on how I negotiate on offers here.
Please consider subscribing to be the first to hear about niche experiences like this.
And follow me on my quest to 30,000 followers on LinkedIn
Alex Nguyen | LinkedIn
Mobile \ Read more \ 27.09
iOS SwiftUI Lists Are Broken And Can’t Be Fixed Swift Combine: Understanding Publisher-Subscriber Pattern in 2 seconds How to Create...
Mobile \ Read more \ 26.09
iOS Compose UI for iOS Aspect Fit Layout Guide Replacing if let in Swift 5.7 Native iOS Game Development w/...
Dotlin – Kotlin to Dart compiler
Dotlin is a Kotlin to Dart compiler. The aim is to integrate Kotlin as a language into the Dart ecosystem,...
Koreography – A light weight Compose Animation library
A lightweight Compose Animation utility library to choreograph low-level Animation API through Kotlin DSL. It does the heavy lifting of dealing...
Mobile \ Read more \ 22.09
iOS Understanding Swift’s Opaque Types Implement Core Spotlight in a SwiftUI App MVVM + POP to deal with complex UI...
Dynamic Islands – A sample of Dynamic Island designs
A sample of Dynamic Island widgets that will help you make better things! Dynamic Islands This repo aims to provide...