The coding interview formula that will get

you any FAANG/MAANG offer

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.

Photo by Firmbee.com on Unsplash

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

1. Dry run your code against the example inputs

2. 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.