hey tech lethea and welcome back to
another episode today we are drinking
green tea with pomegranate and cranberry
it's sweet and tangy kind of like a
Asian fusion mixture for people who
can't truly appreciate real green tea
and need that American sweetness to it
sort of like orange chicken or sushi
with a Thousand Island dressing or any
type of Asian food with Thousand Island
dressing today I wanted to give you five
last-minute tips for your technical
coding interview and this is about what
you're going to be graded on and every
technical interviewer is going to be
watching you and evaluating you on five
basic things and I think that if you
were to nail these five things you're
gonna be golden now before we get
started today we actually have a new and
exciting sponsor algo expert dot IO
slash tech leader they actually make
coding interview videos that walk you
through entire sets of many coding
interview questions and they make a ton
of these videos you should check it out
alka expert io slash tech lead okay so
the first thing that you're evaluated on
is coding coding is the primary thing
you're gonna want to focus on if you're
an entry level engineer generally if you
do a bunch of white board coding
exercises yeah you go to Lee cocom and
do a bunch of those coding exercises I
have a few videos about those then that
should get you set up for the coding
portion and well make sure you're
writing real code and the code looks
good looks clean
nothing convoluted right the inputs
should be clear each method argument is
very clear and each return value is
clear it's not like you have a method
that accepts five different parameters
you know you break it down and there's
just sections for each one many people
come in and they call me write you the
code they can't really write actual code
they can't write a recursive function
they can't turn that for a cursive
function into an area function and you
won't remember that D and the
interviewers often won't like to take a
picture of the code that you write and
then reference that in their actual
feedback report for you you know I like
to do is bring a small marker pen right
in medium small font leave enough space
between lines of code such that I can
insert lines of code if I need to later
on and just make sure that everything
looks nice and neat that would get you a
good score in coding okay so number two
the second thing we want to make sure
that
good on our data structures and this is
being able to have mastery of things
like hash tables arrays linked lists
classes object-oriented programming cue
stacks using any of these types of data
structures or mentioning them would get
you points and it's important to also
know their run times you know the
time-space analysis and if you can just
mention these as you're going through
them in your analysis then that's going
to be really great for you and I will
make sure to try to find opportunities
to just show off that you know
object-oriented programming like even in
the initial function that you may be
creating you can put that inside the
class and that would just win you those
extra points and the interviewer just
feels a little bit more comfortable more
confident that you at least know some
structures the other benefit of using
opiates unless you create instance
variables which are essentially Global's
but even though interviewers were
generally frowned on you if you start
using Global's if you set that up using
object-oriented programming and make
them instance variables then you're
gonna start looking good actually it may
also help make your function of
signatures cleaner because you may be
able to find areas where you can remove
certain variables from the method
parameters and move them into the
instance variables instead overall
though the more data structures that you
can mention in your analysis the more
points you're going to be getting so one
common pitfall is you always want to be
thinking about new data structures that
you are creating new variables
especially heavy data structures like
arrays and you won't be thinking about
if you really need that and what the
cost of that are going to be and if you
create this is there a better way you
can be creating that like should it be a
hash map instead you have to train
yourself to really be careful any time
you start creating arrays matrices
factors anything that takes a lot of
space and just really take a look at
that and think about it and think about
if you really need that and if you can
justify that okay the third thing that
people are going to be looking for is
designed how are your design skills and
this is really something that comes more
into play for senior engineers and this
has less to do with the actual solution
of the problem but rather how you
him about reaching that solution and
which alternatives you considered and so
this portion about design I would say is
really about alternatives
how many alternatives did you think
about how many did you propose did you
look at their pros and cons you know
examples of this maybe if there's a
recursive algorithm why did you choose
to do it that way why not the iterative
solution if there's a choice of data
structures there's usually a trade-off
of time versus space time versus space
is always a trade-off in software
engineering
you can usually trade one for the other
and the design portion is about being
able to analyze that and explain you
know do you want a faster time or do you
want faster space which solutions which
data structures would leave you to one
or the other
generally you're going to one pick the
one with faster time there may
occasionally be more design oriented
interviews where there's less coding and
that's an aryl it could be about design
your entire system or architecture and
figuring out how many different pieces
of code may interact together and my
recommendation for this is to always
think about data flow how does data flow
within the program what are the objects
in your system how do they communicate
between one another you know if you have
like five objects how are they
communicating with each other if it's
just spaghetti communication and
everyone's communicating with each other
that's going to be a mess it's going to
be an even bigger mess once you have 50
objects or 500 objects if you sense the
design weren't a question coming your
way you may want to start busting out
those software design patterns I made
the video about that so you can check it
out if you like but you can start
mentioning patterns like Model View
controller or Singleton's observers
establishing a cleaner one-way data flow
having objects with certain rows I would
say that design also encompasses proper
understanding of big-oh time space
analysis and you absolutely have to know
this the funny thing is most people know
big-oh time space analysis you give them
enough time and they can slowly stump up
on the answer after one or two
failed attempts you know there's only so
many different ones just like constant
time linear time logarithmic exponent
show quadratics something like that and
you know you give people five guesses
and they'll figure one out it's really
about having mastery and fluidity so if
you know the answer and you know usually
I think the answer isn't that hard to
find like if it's an optimal algorithm
is probably gonna be linear time or
something like that if you know the
answer just mention it if you can do it
quickly and confidently they'll just get
you more points tip number four is about
communication you want to make sure that
you're communicating effectively I think
this comes into play in two areas the
first is when you're talking about
yourself your prior projects your
experience you wanna make sure you don't
lose the interviewer and just if you can
explain what you did and not lose the
interviewer and grasp their attention
while you're explaining it you want to
make sure that you're explaining clearly
and you're checking that interviewers
reactions you don't want to lose them if
you can do this effectively then that's
already going to get you big points here
the second portion maybe in explaining
the algorithm that you may have written
at the end you know I would think
carefully about if you want to be
talking while you're writing code you
want to explain some of it but if you're
writing and your friend to talk at the
same time at least for me I find that
it's difficult for me to speak fluidly
if I'm trying to write at the same time
what I like to do is explain why I'm
gonna do write the code write a few
things then talk about it and then go
back to writing but I wouldn't
necessarily do it all at the same time
and then the fifth thing that people
look for which I think a lot of
candidates forget or don't pay attention
to is speed and efficiency speed and
efficiency is really what separates the
top tier candidates from the mediocre
candidates because the fact is I think
many people will be able to ultimately
solve a problem solve a whiteboarding
problem even get the answer even be able
to analyze it but many people don't make
it very far you want to make sure that
if you know the answer just solve it
solve it quickly blow the interviewer
away and you may be surprised if I
and that the problem that they asked was
only the beginning of a problem and
there were two or three additional
advanced stages to the problem may be
several follow-ups maybe there was
another problem the interviewer wanted
to ask you just get as far as you can
along the problem and don't
underestimate that a problem is as
simple as it seems and that you can just
take all the time you want all too often
I will see candidates start working on
the edge case some useless function or
something like that and they'll just
spend tons of time trying to write the
code perfectly and you know they focus
almost too much on the coding portion
and they want to write every single
semicolon every single variable and they
have really long variable names and they
think it's going to make their code look
beautiful and yeah sure it does and
maybe they win a few extra points and
say the coding portion that I might be
looking at but if it takes them super
long and the speed is just not there
then that's going to losing points their
practice may involve coming up with
short hands abbreviations perhaps
creating helper functions that you can
film in later so you just want to make
sure that you're not losing time my last
and final tip if you're looking for more
interview practice is to check out our
sponsor algo expert they'll slash tech
lead they offer over 65 hand curated
technical interview videos with complete
solutions in many different languages
the videos cover time space complexity
analysis gives you a complete
walkthrough of the solution in five
different popular programming languages
Java Script Python C++ Java and go you
can try the problems on your own get
pins and then watch the entire video
solution I wish I had something like
this years ago when I had just started
so check them out I'll go expert the L
slash tech lis so they'll do for me if
you have any other interview tips make
sure to leave them in the comments below
if you liked the video give it a like
and subscribe and good luck on your
interview