Whiteboard Coding Interviews: 6 Steps to Solve Any Problem (1)
So one thing I wanna talk about today is how to ace that technical interview.
And this is really one of the hazing processes of getting a job in tech is to you gotta get into a room with another developer, someone you've just met, they're gonna introduce you, introduce themselves to you and they're gonna give you a problem and you're gonna have to solve it on a whiteboard which is totally unnatural, I get it.
Usually you don't code on a whiteboard.
Usually you're working with people you know.
So it's a pretty intimidating process for entry-level developers, actually to be honest it's intimidating for everyone.
It's one of those things where even to this day when I'm interviewing for technical jobs I still get nervous about it, even though I've done hundreds of them, I've been on both sides of the table and I've also,
I've practiced a lot of coding problems throughout my lifetime, it still makes me nervous.
So that's very natural.
I wouldn't be upset that you're nervous about it,
it's just something to practice for.
So at Fullstack we've invented a method that we like to call the REACTO approach to solving interview questions.
So it's R-E-A-C-T-O, nothing to do with the REACT framework
it's just something that as I was coming up with an acronym
I wrote 'em out kind of the exact steps
and REACTO was the acronym that came out.
So what does REACTO stand for?
Repeat, give examples, describe your approach, implement the code, test the code, and then talk about optimization.
All right so let's start with R, repeat the question.
You wouldn't believe how many times I'm in the interview room with a candidate...
and I'm excited for the candidate...
and we're having a good chat...
...and then we get to the programming question...
and I say implement this thing...
and the first thing they do is they take the cap off the pen and they start writing on the whiteboard before they even really understood the question
And I can tell because the first step they say is something
and I just know they're gonna go down the wrong path.
Now one secret is that when you're interviewing with somebody - people like to use the questions they're comfortable with
So very likely they've done this question 100 times
And this is the first time they're seeing it.
So they already know all the paths that you can go down that are gonna be incorrect.
So you're going down the wrong path immediately and that immediately puts the whole interview onto a tough foot.
So the first thing you should do is really just repeat the question and that will oftentimes help A, help you understand it better and B, really make sure that the things that you don't understand you can work out with the interviewer as you're going through the repeating of the question.
The second thing is to start writing out various examples.
So before you even write out any code, write out hey here are the parameters that I'm gonna pass into my function and what did I expect to get out, right?
So just create a little table, a two-column table and say given these parameters what output do you expect, right?
This is another way to really understand what exactly the question is asking, because you oftentimes will get a lot of understanding by just understanding input, output, input, output, right?
You're trying to, one way to think about this is that this problem is a black box.
How can you start understanding what's inside the black box before you know giving something into the black box, what comes out on the other side?
So list out examples.
This is another great way to keep the conversation flowing and make sure that you understand what the question is asking.
Now the third step A, describe your approaches right?
So start talking about the approaches you're gonna take.
Are you gonna look for a recursive solution, an iterative solution, a heuristic solution?
So give the interviewer some insight into your logic and thought process and really help them understand kind of the track that you're going down so that you know you also get a little bit of read on if you're on the right path
but how they respond to your questions.
So if you say you know what?
I'm gonna take a recursive approach
and they look at you like excuse me?
Then you know that you're probably on the wrong path right?
So if you say well I'm gonna take a recursive approach,
I'm like okay, that makes sense,
then you're playing the interviewer a little bit
as well as playing the question.
So take some time to talk about your approach.
Again, oftentimes people give advice keep talking,
keep talking at your interviews
and what they really mean is this kinda stuff, right?
Keep talking about your thinking
not what's going on in the code
and you realize there's three things that you've done.
You've probably spent about five minutes
and you haven't taken the marker out of the case
and started writing on the board.
All right, so after you've talked about your approaches
and you've confirmed an approach,
you say this is what I'm gonna take,
usually the interviewer will give you some sense that you're on the right path.
Then you start writing on the code, going down the path of writing code.
So C in REACTO is for code and you know there's so many things I can say about code,
we can dive into those further if you have questions
leave a comment below.
I'd love to talk about
how do you actually code these different problems?
You have all kinds of different thoughts and ways
to break down a problem.
But one thing that I really like and I heard this tip
from the author of Cracking the Coding Interview,
Gayle McDowell herself,
and she calls this breath first coding.
So I'll give you a link to the talk she gave at Fullstack
on breath first coding.
And you'll hear it's a little bit of a hack right?
Because you know in programming we can,
we like to decompose our work into functions right?
And so exactly the same thing here,
decompose your approach down into the high-level functions
instead of into the really what I say
more like the imperative things that you're doing.
So for example, instead of writing out a for loop
to iterate over some part of an array
or to iterate over some data structure
just write iterate data structure parentheses
the data structure comma whatever, right?
And then the idea here
is that you're breaking down from a high level your approach
into smaller steps right?
So we call this idea breath first coding
and I'll tell you a little bit
why I think this is really an amazing hack
is that really a lot of times,
you can get really caught up on something that's trivial
but is kinda quite complex in the minutia right?
And so those can be things like a regx right?
You can really spend a lot of time debugging a regx.
A lot of times when I'm working on a regular expression
I'll spend a lot of time before I get it right
and you can really get caught up on that stuff.
You can really get caught up on loop boundaries.
You can really get caught up on
the different naming of variables and these are things
that it's just not worth spending the time on
when you're still thinking about the problem
from a high level down to a low level.
And oftentimes if your approach is right
your core algorithm is right and the fact that you wrote out
hey this step is check the regx of this string,
the interviewer won't even ask you to go implement it
because they kind of assume that as long as they understood
that this is what they need to do at this point
I'm okay with that.
The underlying details aren't that important.
All right so after you've done the coding
some additional tips, right?
So leave yourself room between each line for edits right?
Writing on a whiteboard
is not coding in VS Code or coding in Sublime Text,
it's really hard to edit, right?
You can't really move stuff around
so write out big and with a lot of space in between each one
because most likely you're gonna go back and erase,
you're gonna insert some lines
and once you start writing like insert here arrow
and a small little thing, small code everywhere
it gets hard for you to understand
and hard for the interviewer to understand.
It really just starts becoming a mess, a jumble to work on.
The second thing I really like
is star things that you're not sure about right?
So as you're going through
there will be some things where you're very confident
and some things where it's tickling the back of your mind
that you know what I should go back and check this.
I'm gonna just say it here and you know leave a star
and say you know what, I'm pretty sure
this is how this function works
or I'm pretty sure these are the parameters of array reduce
or I'm pretty sure, whatever you're pretty sure about
leave a star there, you can go back.
This shows that your confidence level
matches to the interviewer's understanding
of your confidence level in what you're saying
because oftentimes if you're semi sure about something
and you don't convey that you're only semi sure about it,
it might come off as okay
this person doesn't know what they're talking about.
So always try to signal to the interviewer
your confidence level in what you're saying.
And really a lot of times it's okay to use pseudo code
in the interview.
Most good companies or most good interviewers
are not there to see that you know your JavaScript syntax.
They're not there to see that you've memorized
most of the developer network.
They wanna see how you think.
They wanna see how you break down a problem
and so it's okay to use pseudo code.
And so for example if there's something
that you're just a section of code
or maybe you've broken down the code
into these three major things and this one thing,
this one function
you can't really figure out the syntax for it,
feel free to just pseudo code it out.
Just write it out in English
and you'll get back to them about it.
All right so the 5th step is to test, right?
So after you've written your code, you're feeling relieved.
You're like okay I got something on the board.
Now it's very important to show your diligence
and go back and say well let's take some of those examples
I wrote down earlier and run them through my code right?
So choose a set of parameters and just run through.
And one thing I like to do is get another colored marker
and just kinda mark your variables
as you're going through the process, right?
So you're saying okay A here is one,
this loop I is zero as I'm going through the initial one
and then I'm going through the initial loop,
here's the different steps that I'm thinking it's taking
and then here's what it's changing,
et cetera, et cetera, right?
So go through and test your code.
Run the examples and see if they actually work.
This is a really important step
because if you take this step then most likely
unless your algorithm is perfect right off the bat
most likely the interviewer is seeing some problems
that they wanna see if you can also see those problems.
