All right.
Welcome back.
This will be a 32nd 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 at a whiteboard and 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 faced an app 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 a lot of 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 set outset, I don't know, break it down.
So at this point, if you if you like to write like totally perfect pseudocode 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.
If you're timed 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% of this.
Here is 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 whole.
You can confuse yourself.
It's happened to me many times in interviews.
If you just start, you think you know where to start and you'll figure out the rest as you go.
Often you pigeon 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 plan
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 a 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 like one and two for sure.
Do that out loud.
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, they're 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.
Okay, 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 of archetypes, blueprints for solutions that may come in handy.
I honestly think this stuff is much more useful in the real world because it applies to all sorts of
problems.
What we're going to learn next is a little more specific, but for the types of problems it helps with,
it really helps.
That's up next.