All right.
Welcome back.
This will be a 30 second video.
I just wanted to summarize the steps.
So to recap sort of the five step protocol here whether you're faced with a tough interview challenge
and you're you're at a white board there's a bunch of people watching you or you're trying to solve
something on your own for a novel.
I don't know challenge you.
You're trying to build trying to figure out how to sort search results whatever it is.
These are the steps that I like to go through.
Make sure you understand the problem and do this the way I taught it or talked about it was geared towards
interviews like I said especially things like understanding the problem.
So ask questions of your interviewer of course clarify the problem make sure you understand it.
But even if it's just you working on something.
Make sure you understand it to make sure that you really have thought out how your solution how your
application should operate how it should behave in every scenario and that goes hand-in-hand with exploring
concrete examples.
These two are really both about understanding the problem understanding the inputs understanding the
outputs understanding edge cases how do you handle errors what happens when a user enters something
invalid.
All these different things all have to do with just sort of understanding from the outset how everything
should work on the outset.
I don't know break it down.
So at this point if you if you like to write like totally perfect pseudo code line by line you can do
that or just break out a couple of steps to lay out a game plan for the code you need to implement.
This is really helpful especially in an interview a few times and you know that you're going to run
out of time.
It can be useful to write your game plan out so you can show them Hey this is where I was going even
though I only actually implemented 40 percent of this.
Here's the other steps that I was going to do.
So make sure you know where you're going before you just start typing code.
Often that's a bad way.
You can end up in a hole.
You can confuse yourself it's happened to me many times in interviews if you just start to think you
know where to start and you'll figure out the rest as you go.
Often you pigeonhole pigeonhole yourself into one approach and then I start to panic because it's not
working out and I take a step back and usually erase everything I've done and and start over and planned
it out.
So then solve.
And if you can't solve the problem right away solve a problem that you can.
Even if it's simpler if you simplify you remove some core difficulty core challenge try and solve something
where you can then reincorporate that core difficulty back in.
So we talked about in two videos ago if you're not sure how to test for something being alphanumeric
ignore that part and just write the problem write the solution ignoring the alphanumeric part so that
you could then plug it in later.
And then finally what I said was the most important for learning or improving as a developer.
Looking back on your code and sometimes refactoring it sometimes just looking back and analyzing it
and patting yourself on the back.
Most of the time there's room to refactor even if you're totally expert developer.
It can be very useful to look at other people's solutions or to scrutinize your own and figure out what
you could have done better.
All right.
So those are the steps I recommend if you're ever faced with a tough challenge especially if you're
an interview in an interview.
I would absolutely recommend always starting off with understanding the problem.
Exploring examples one in two for sure.
Do that outloud.
Make sure the interviewer hears you bring them into the process tell them what you're doing.
Breaking it down.
Write the steps down.
Talk out loud.
Solve it of course.
If you can and then look back on your code and refactor if you can.
All of these honestly are equally important.
In an interview setting as well as in real life but I think most of you care about interviews for the
most part.
So I'm gearing it towards that.
OK so that's the wishy washy part of problem solving sort of the approach the steps that you can take
mentally to prepare yourself.
Next we're going to talk about some patterns for code.
There are a couple of archetypes blueprints for solutions that may come in handy.
I honestly think this stuff is much more useful in the real world because this applies to all sorts
of problems.
Well we're going to learn next.
It's a little more specific but for the types of problems it helps with it really helps.
OK.
That's up next.