(bright musical tones) - 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. All right and the final step, and this is the most important, all right this can be one of those ones that really should differentiate you from the rest of the pack, right? You've repeated the question,
you've given your examples, you've described your approach,
you've written the code, you've tested at least on the whiteboard, written out your variables,
the last thing is the O and this is what I call the
optimization and runtime. Optimization, right? This is oftentimes the thing
that especially beginners are a little confused about
but this is really the idea how will this perform for large datasets? Or how does this algorithm
that you've created perform under different kinds of datasets, different sizes of data? So this is where we hear
a lot about the big O, this is big O of N, big O of
N squared, big O of M times N and maybe you went with
a brute force approach and maybe you went with
the Christopher approach so this is more ya know getting
into approximating big O is a little bit more detailed
than I want to get to in this talk but you really wanna, as you know more about big O just specify here's what I'm thinking
about optimization and here's what I think, I think this loop and this inner loop is
gonna give me an N squared. It just shows the maturity
that you're willing to, or you're able to think at a level of if I put this code into
production what's gonna happen to, what's gonna happen to our code base? So you know why did we
think the REACTO framework or why did I come up with
this REACTO framework right? And I think the first thing,
the most important thing is to not start writing right
when you get the code right? Because here's my picture
of it is that your brain is working on multiple levels and as soon as you start writing you start committing yourself into paths that could be incorrect right? But the more you really buy yourself time, the more time your brain gets to load in all the stuff you've practiced
on, you've trained on so give your brain some
time to think, right? Give your subconscious brain some time to load stuff into memory
before you start writing because writing, once you start writing I feel like you start
committing down pathways. Two, you really wanna
start the conversation because once the conversation is flowing between you and the
interviewer it's a lot easier to continue the conversation
once you're coding right? Because then you can say things like well I'm a little bit stuck here but if I think back to the
approach I described earlier I think it would look something like I need to somehow find a base case or I need to figure out my recursive step. So the conversation continues
to flow once it's started. So some additional advice is
one, just stay calm, right? You're not supposed to
know the answer immediately because these problems are
meant to take some time to take some thought and
to work through, right? So focus on breaking down the problem and I think these problems
are a little bit unfair because for example one
of my favorite examples is find me a cycle in a link list, right? So you have a link list,
see if there's a loop in it. And the algorithm is named after somebody because I think they wrote
about it in their PhD or they wrote about it in some
kind of thesis paper right? So if you don't know the answer or if you don't know that trick it's unlikely that in a
situation where you're nervous you're gonna come up with
it on the spot, right? So it is a little bit of a test not that you're some
genius and can figure out all of computer science
in a 30-minute interview but that you've been exposed
to this information right? 'Cause even after being exposed you still have to kind of
recall it, implement it, execute it, and so the
reality is don't stress out that you have to figure out these things. If you don't know the answer
sometimes that's okay, right? You can still get a job,
you can still get to a job even if you don't get the answer
and make it a conversation. Ask questions when you get stuck. I think the, this is just
a human nature thing. It's very awkward to be
in a room with somebody and no one's talking. If you ever want to do a social experiment just go on the street, someone asks you something
and just look at them and as you're looking at them you're gonna see them
continually get uncomfortable. They start shifting around, they're gonna start looking
different directions because silence is very awkward
and so this is not for you because oftentimes you're the one, you're lost in thought right? But your interviewer is
sitting there like whoa, I don't wanna work with this person because every time they're
stuck they're just sitting there making me very uncomfortable, right? Whether or not this is fair or not your job is to also make
the interviewer comfortable and just keep talking,
keep trying to verbalize what's going on in your mind, right? Even if what's in your
mind you feel a little bit is totally off the mark, right? You have to kind of let
that conversation flow and learn to read the
interviewer a little bit and how they're responding
to your thoughts. And final thing just to repeat, don't start writing right away, right? It's a reflex, you want to you know maybe
you wanna buy yourself time or I don't know why people
start writing right away but the number one thing to remember is don't let your hands touch the marker. Repeat, give examples,
describe your approach before you even touch the marker. And really this is something that our students at
Fullstack practice a lot and the ones who practice
a lot get good at it. They come back and tell me
that it works like clockwork. You're in an interview, you're
thinking to yourself REACTO, REACTO, REACTO, REACTO, react oh, right? I hope this helps and as always ya know the most important thing
is to practice too. So there's a lot of interview, there's a lot of practice
interview platforms, get together with a friend, and really just go through
the REACTO framework. Practice it and just as a
caveat don't go in there and say oh hey interviewer,
I'm using the REACTO framework. I'm gonna repeat the question. Make it natural. No one wants to feel like
they're part of a script, right? So make it feel natural but this is what you should
be thinking inside your head is the things that I'm gonna go through. So one last time, repeat the
question, list your examples, describe your approach,
code, test your examples, and then talk about optimization. All right I hope that helps. (bright musical tones)
