0:13

Welcome back to another web dev podcast episode

0:15

where we help aspiring developers get jobs and junior

0:17

developers grow . In this episode , we are

0:19

going to be tackling the very tough subject of

0:21

how the heck

0:24

do we learn data structures and algorithms

0:26

. There are a lot of very strong

0:28

opinions on Reddit from different developers

0:30

And I decided

0:32

to bring on Matt , who

0:35

actually has quite

0:37

extensive experience training

0:40

software engineers and aspiring

0:42

software engineers into even

0:44

positions that big tech

0:46

positions , where it's

0:48

maybe a little bit more elite code heavy , but

0:51

he's trained a lot of people and he'll talk more about

0:53

that . But yeah , i just brought someone on

0:56

to clarify how people

0:58

can navigate this messy world of data structures

1:00

and algorithms , how we can get started And

1:04

, yeah , let's just dive into things . Matt

1:07

, i appreciate you coming on , but yeah , do a little intro for yourself

1:09

. Who are you ?

1:10

Yeah , thanks , my name is Matt . I

1:12

go by Coach Matt And

1:15

I have . There's

1:17

been a . There's been a motif of like mentoring

1:19

, teaching throughout my entire life and that's manifested

1:22

in my work as well

1:24

. So I've been

1:26

. I've been working for 10 years . The first

1:28

month of my professional work

1:30

experience , i was interviewing people . I

1:32

really enjoyed it , for whatever reason . I've

1:35

been doing a lot of real interviews

1:37

since then And mock

1:40

interviews . I worked with a

1:42

bootcamp where I was working

1:44

on all their content their tech related

1:46

content And in

1:48

terms of the interview process , i've really seen

1:50

it from every angle . So

1:52

I've applied as an individual contributor

1:55

. I've applied as a manager . I

1:57

have hired people as a hiring manager

2:00

. I've interviewed people as

2:02

an individual contributor . I

2:05

have hired people

2:07

and I've been fired myself one time

2:09

. So , yeah

2:11

, you know a lot of experiences around

2:14

that And I think that really helps me in

2:17

my , my mentorship , my

2:19

coaching .

2:21

Love it . I appreciate the transparency . Not a lot

2:23

of people are willing to say that

2:25

I've definitely been fired before as well

2:27

, and I'm sure other people have . So actually

2:29

, yeah , i dig that

2:31

. So let's actually just dive into

2:33

it , because I'm very confident with what you know

2:35

. I've talked to you before . But

2:37

the big question really is , like

2:40

, as a new developer like you know my audience

2:42

full of new developers , junior

2:44

developers it's very

2:46

difficult to like really solidify

2:49

how

2:52

to get started , when to

2:54

implement data structures and algorithms and

2:57

how to navigate through that and how to measure

2:59

your progress , and then like , if you do

3:01

get stuck , you do hit a plateau . Where

3:04

the hell do I go from here ? Right , so

3:06

we're going to dive into all that , but , yeah , let's just

3:08

get started . If you had to give advice for

3:10

, like how to get started with it , what

3:13

would you usually recommend people ?

3:17

Yeah , great question How do

3:19

you , how do you get started with getting started ? pretty much

3:21

Right

3:24

. Well , the number one mistake that I see people

3:26

well , a really common mistake that I see people

3:29

making is that they're trying stuff that's

3:31

too challenging . So I like

3:33

to think of it as levels of

3:35

understanding . So imagine

3:37

, when you're speaking a language you know , first

3:40

you learn where

3:42

well , that's a little bit backwards because you learn

3:44

words and then you learn to spell . But imagine , you

3:46

learn to spell and then you learn words and then you learn

3:48

to make sentences and then write paragraphs

3:51

and maybe stories , if you go

3:53

that far , right , so

3:55

I think this translates quite translates

3:57

quite well to programming . So first

4:00

you would learn syntax and then I

4:02

would say native data structures and

4:04

how to work with those , and

4:06

then you learn concepts . A

4:09

concept could be recursion

4:11

or depth

4:14

, first traversal on a binary tree

4:17

, or dynamic

4:20

programming . Dynamic

4:22

programming is essentially recursion

4:25

with memoization , and memoization

4:29

is caching without cache invalidation

4:31

. So like there's this

4:33

really graph of concepts and how

4:37

they relate to each other , and that's what I see as the

4:39

fundamental language behind algorithms . And

4:44

you , when you introduce the idea of this chat

4:46

to me , you use this DSA acronym , which is something that

4:49

I've seen a few times I had forgotten about because

4:52

I use it so infrequently . It's the great

4:54

, it's

4:57

, it's the right one to use , but

4:59

I , for me , find it a little bit awkward

5:01

because I see data structures in

5:04

algorithms as nearly synonymous

5:06

with programming , right ? So

5:08

data structures is really anything beyond

5:11

a primitive , so some structure

5:13

of data and an algorithm

5:15

is essentially any function . So you write

5:18

functions that work with data . that

5:20

is programming . So , yeah , i really

5:23

like how you broke that down . That's

5:26

that's . That's actually . That's how I like to teach . I

5:28

like to identify , you

5:31

know , the fundamentals and

5:34

build up from there , especially identifying you know where the

5:37

missing gaps are in the person's knowledge

5:39

. Because everyone , right this , this day and age , people are teaching themselves

5:42

. Everyone has , like , a different background

5:44

, different experiences , different

5:47

aptitudes , so people get caught up on different things . People you

5:49

know , maybe even don't

5:51

hear about certain concepts . So , yeah , okay

5:55

, so what the way ?

5:56

you're describing

6:00

it , the way you've simplified

6:03

essentially what it is . It's

6:06

much less intimidating to just see it as data and a function

6:09

that does

6:11

something with that data . It's much less

6:13

intimidating . But in junior developers' minds they

6:17

hear you must learn data structures and algorithms

6:19

And there's a reputation for how in

6:22

depth this can be . And it

6:24

starts to go into a little bit more

6:26

obscure elite code problem area

6:29

where you you

6:31

might never use these types of , or you

6:33

might never need to know these types of solutions or

6:36

be able to solve certain types of

6:38

problems or have to memorize a certain

6:40

algorithm or search algorithm or search algorithm

6:42

, right . So people

6:44

in their mind they just to kind of create

6:47

this like boogie man and

6:49

this monster that is so intimidating . They're

6:51

never going to be able to defeat

6:53

that monster , like I know I'm being really silly

6:55

with this , but I'm telling you like a lot of junior

6:57

developers like have this vision . So

7:00

I guess

7:02

help me understand . Or

7:05

, for those that are kind of like creating

7:08

that vision , what's

7:11

a more realistic

7:14

end goal with

7:17

learning data structures and algorithms

7:19

that's

7:21

reachable ? Do they have to go deep

7:24

into this ? well , of tons of elite code

7:26

problems to stand out among

7:28

employers who a lot of employers test for

7:30

this . Or what do employers like when

7:32

they hear that employers are going to test you with coding

7:34

challenges and do you say problems

7:36

like how deep do they

7:39

go and what are they really looking for ? Let's start

7:41

with that .

7:42

Yeah , that's a great question . So what are they looking

7:44

for ? I'll start with that , especially

7:47

for people that are starting out in the industry . They want

7:49

to know that you can solve

7:51

problems , ideally difficult

7:53

problems , and the

7:56

industry has settled on and I largely

7:59

agree with this the

8:01

coding algorithm

8:04

interview format . So

8:07

that's really

8:10

what we've arrived on . And , as in

8:12

terms of feeling overwhelmed

8:15

by the breadth that's , you know , breadth

8:17

for search

8:19

, that's another concept , the breadth

8:21

of algorithms out there

8:23

, i think , i think elite code is at

8:26

fault here in

8:28

terms of presenting

8:30

this , you know , multi

8:32

thousand , i believe , list

8:34

of questions which is really hard to navigate

8:36

. It's incredibly intimidating , and the

8:38

metadata that you have around , that is primarily

8:41

like difficulty And that's even low resolution

8:43

. It's like easy , medium , hard . It's

8:46

really hard to figure out . What

8:49

do I work on and when ? How

8:51

much of this do I need to know ? right , there's

8:53

like the blind 75 . And

8:55

there's another one that's really popular too , that are just

8:57

, you know , consolidated lists of

8:59

lead code , which , which

9:01

helps . But I

9:04

like to think about it the other way

9:06

again . So , going back to the

9:08

levels of complexity that we were talking about , syntax

9:11

, and then working with native data structures

9:13

, and then concepts and then algorithms

9:15

. The concepts and algorithms can

9:18

really be kind

9:20

of like a chicken and egg thing

9:22

, so you

9:24

can work on an algorithm , but first

9:27

be aware of the concepts that

9:29

are required to solve that algorithm

9:32

And then , to exercise that a little

9:34

bit more , you can find more algorithms that

9:36

exercise those same concepts

9:39

. So I think that's the way to go And

9:41

you really want to focus on learning

9:43

these concepts , which

9:45

will allow you to , instead

9:48

of say , if you're given

9:50

the really

9:52

common algorithm of counting the number

9:55

of islands in a matrix

9:57

So you have a two dimensional matrix

9:59

where one represents land and zero

10:02

represents water you

10:04

want to find the number of , you know

10:06

, contiguous blobs in that , in that matrix

10:08

. So if you're not aware of

10:10

the concepts or familiar

10:13

enough with the concepts at play here , you

10:16

might say , well , i need to

10:18

create a , create an array and , you know , loop

10:20

through the matrix And then , whenever

10:22

I find one , i need to look

10:24

at all the neighbors , but then make sure I don't revisit

10:26

. Yeah , there's

10:29

, there's a lot , of , a lot of complexity there , but you

10:31

can really boil that down into like

10:33

it's a depth first

10:35

, search over the matrix space . Each

10:38

time you find a new piece of land . You

10:41

do the depth first search , mark all that is visited And

10:44

that's that's the algorithm . So

10:47

if you are familiar with these concepts

10:50

and you focus

10:52

on the concepts primarily , then the algorithms

10:54

become compositions of

10:56

those concepts And

10:59

I mean that's , that's . That's essentially like how we , how

11:01

we write , that's capturing how

11:03

we write code in the real

11:06

world to write . We have these

11:09

separation of concerns , these

11:11

abstractions that we rely upon . You can't be

11:13

, you can't , you

11:17

can't keep every line of code within a

11:19

project on the top it with in your head at one

11:21

time . It's

11:23

just , it's just too much . So you need , you need these abstractions , you need these

11:25

higher levels of

11:27

abstraction , you need a this higher

11:29

language to break down these problems and go about

11:33

them , go about solving them .

11:37

It makes sense . Yeah

11:41

, i feel like , i

11:43

feel like . Yeah

11:46

, the question still remains . You mentioned

11:49

, like the algorithm , the solution was a depth

11:51

first search , right

11:54

? And even the idea like it

11:57

, like when you said it it felt

11:59

very obvious . But

12:02

even the idea of like , if someone

12:04

else here , is it like depth first search

12:06

? OK , i've never heard of that before . When

12:08

am I supposed to learn it Right ? Is

12:10

there a way where

12:13

I guess this is my question Is there a way

12:15

where , when people are working on their personal projects

12:17

and they are starting to reinforce

12:20

skills or doing more challenges , is

12:23

there a ? How do

12:25

people figure out this like natural transition

12:28

to apply

12:31

these concepts in a very practical

12:33

way ? Do they just look up challenges on

12:35

the Internet ? Should they use chat

12:37

to help generate challenges ? Should

12:39

they integrate , like you

12:42

know , build a feature or something that's

12:44

going to have to utilize data

12:46

in a certain way with their personal project

12:48

to apply a

12:51

more complex algorithm or utilize

12:53

a more complex data

12:56

structure ? Because I still feel like there's that

12:58

bridge that

13:00

I think people still struggle with And

13:03

, yeah , i was hoping you can clarify that .

13:06

Yeah , so how does this translate to writing , working

13:08

on real projects ? Yeah , yeah

13:12

. So I want to put

13:14

a pin in chat GPT . Yeah

13:16

, chat GPT

13:19

is really interesting . It's a fantastic tool to

13:21

prototype with . I

13:24

was , i did a session with with someone

13:26

who's really high up in

13:29

Amazon and switching to

13:31

a more technical role and she doesn't have the technical background

13:33

, and I suggested using chat

13:35

. You can be

13:37

in a place where you're you're so confused

13:40

by what's at play Like you have difficulty

13:42

formulating proper questions , right

13:44

, i think . I think chat GPT is a

13:46

great tool to ask it . Like you know

13:49

, air quotes silly questions and

13:51

then have it help . You have a dialogue with

13:53

that . You know chat GPT

13:55

is always there . It's on demand . A

13:58

dialogue there to explore

14:01

and get a better understanding of what's going

14:03

on there . You know a better solution would be

14:05

to , you know , work with a mentor or , you

14:07

know , peer or

14:09

someone . Yeah , so

14:13

how does how does this ? how does this translate

14:15

to , to practical

14:18

projects ? So well

14:20

, first of all , i think I think it's it's really difficult

14:22

to derive these . You

14:25

know difficult and you're impossible to derive these

14:27

concepts If you're not aware of them in the first place

14:29

. So you have to learn whatever concepts

14:31

are going to be necessary for the project Um

14:34

. Really , there aren't a

14:36

massive amount of these concepts

14:38

that are used

14:40

Um . So

14:43

I think what

14:45

do you want to do is really just

14:47

build up a routine of working

14:49

on algorithms

14:52

every day . They don't even need

14:54

to be very difficult algorithms . Actually

14:56

, i even break down algorithms along

14:58

two axes , where

15:00

one is the difficulty

15:02

and the other one is the , the

15:04

, the complexity , and by that I

15:07

mean like , how much , how

15:09

difficult the code is to understand . Um

15:12

like correlate

15:14

, correlates basically with how much code there is . You

15:16

can imagine a solution that has a lot of code , but it's still

15:19

, you know , pretty straightforward Um . So

15:21

those don't necessarily there's aren't the same thing

15:23

Exactly , um . So

15:26

I think it's very beneficial

15:29

to work on these simple

15:31

but potentially , you know , easier , moderate

15:34

difficulty algorithms , um

15:36

, every day . Uh

15:38

, on my website I actually have questions

15:41

mapped along those axes as

15:43

well , as each of those algorithms

15:46

maps to the

15:48

concepts at play , and then those concepts

15:50

have pages that explain what they are

15:53

and map to other

15:55

algorithms that leverage that

15:57

concept . So the whole self

15:59

teaching process that I was saying of pick

16:01

a concept , learn the concept , practice

16:04

it with an algo , find more algos , right

16:06

, that's all very natural on on on this platform

16:08

, uh . But you

16:10

know , once you have that familiarity , then those are

16:12

, those are tools , those are , those are larger

16:15

things that you can reason about when you're , when you're working

16:17

on uh , on a project . So

16:19

I think , i think that's you know

16:21

, you have to . you just have to learn this stuff and then

16:23

bring it in to your , your practical coding

16:25

Okay , and really go backwards

16:27

.

16:28

Yeah , that makes sense . So get exposure initially

16:31

, um to

16:33

uh , some of the data structures and algorithms

16:35

. I and

16:37

you mentioned this idea of . Like you find

16:40

that many people will just dive too

16:42

deep too quickly . Yes , yes , how

16:45

do you know if you're diving too deep

16:47

too quickly And how do you know if it's like the appropriate

16:49

challenge ?

16:51

Yeah , that's , that's a really , that's a really awesome question

16:53

. Um , if you feel

16:55

like you're beating your head against the wall , so

16:58

this is , this is something where , um , ideally

17:00

similar or more experienced peers um

17:04

that you know can help

17:06

you out . Um

17:09

, i , this , this happened . I , i

17:12

saw this happen . Yeah

17:15

, i , i've seen this happen so many times , say

17:18

with web . Uh

17:20

, front-end engineers that are

17:22

working , working in React . So there's a

17:24

lot of moving pieces there . Say

17:27

, if you're trying to write something in React

17:29

, you have , you have potentially

17:31

inline CSS , css , you

17:33

have HTML and JSX , which isn't quite

17:35

HTML , but it mostly is , and

17:38

you , of course , have JavaScript . Right , there's a lot of

17:40

moving pieces there and , you

17:42

know , some people even really get tripped up with

17:44

all the syntax at play there . So

17:46

, for people

17:48

at that level , i think a good litmus

17:51

test is to see if you can

17:53

write a React

17:55

function that renders

17:58

a two-dimensional grid

18:00

of cells . So

18:02

a lot of moving pieces there . Um

18:05

, if you do know everything you need to know to

18:07

do that , it might feel a little

18:09

awkward and admittedly it is And

18:12

if you have no idea what to do , then

18:14

you need to take a step back and familiarize

18:17

yourself with whatever , whatever

18:19

syntax or moving pieces are fuzzy

18:21

. Um , did

18:24

I mess anything with your question ?

18:26

Yeah , no , i think that's helpful . Um , in

18:28

for people that aren't really familiar

18:30

or used to diving into a

18:32

little bit more complex coding challenges . You provided

18:35

the example of like yes , people dive

18:37

too deeply into reacts too

18:39

quickly very , very often . Like

18:42

that's a very common problem , um

18:44

, and so I think that's

18:46

the difficulty . It's like it's knowing when

18:49

to dive into the next advanced

18:51

concept . You mentioned the idea

18:53

of like if you're beating your head on the wall , is

18:56

there like let's

18:58

actually break this down a little bit more ? Um

19:01

, is there a time limit

19:03

you would give someone where

19:05

they haven't made any forward momentum

19:08

with a problem , where you would suggest

19:11

that maybe they need to take a step

19:13

back ? do you have any like timelines like that

19:15

?

19:18

Uh , i'm not sure if I would come

19:21

up with an explicit time

19:23

. Um , i

19:25

think it's more of a feeling , um , like when you're

19:27

, when you're coding and you recognize

19:30

this is a difficult , difficult problem , maybe you're working

19:32

on a really difficult problem and your

19:35

thinking of a new approach , perhaps refactoring

19:37

something , or thinking of a new

19:40

approach , and you're making like some kind of incremental progress

19:42

. When , when you're just

19:44

staring at the screen , you

19:47

don't know what to write , you don't

19:49

really know what to search , you don't know what concepts

19:51

are at play , you don't know

19:53

why you're getting a certain error , um

19:55

, that is to me like beating

19:58

your head against the wall Like this . This

20:00

feels like some futile exercise For

20:03

another three hours and

20:05

be exactly where I am right now . Does

20:08

that ? Is

20:11

that ? yeah ?

20:12

Yeah , no , no , what you're saying makes sense to

20:14

me . Um , i think a lot of people are

20:16

, especially newer developers , are going to imposter

20:18

syndrome , and I just remember , like thinking

20:20

back to even when I was in a coding bootcamp , i

20:22

literally could have like the anxiety

20:25

of solving a problem on the spot Um

20:27

cloud my

20:30

perception of if I am making

20:32

progress , like even where I might make

20:34

a little incremental progress . It

20:37

just felt like , am

20:39

I really making progress Or should I

20:41

just like am I tackling too hard of

20:43

a challenge ? So , um , i

20:46

do agree with you . You kind of have

20:48

to feel it out And I would almost argue

20:50

like you're going to get a better sense of that as

20:53

you code more , as you program more and

20:55

challenge yourself , you're going to realize how

20:57

you identify roadblocks

20:59

and how you're you identified that they

21:01

actually are roadblocks and not just

21:03

something that you , you know have to overcome and , uh

21:06

, or if you have to move back into simpler concepts

21:08

. So , no , i I like what you said , i think

21:10

that makes sense And I would just kind of encourage

21:13

people to like give it time

21:15

. The more you code , the more you're going to be able to assess

21:17

that , i think , properly . Um

21:19

, yeah , so .

21:23

Can I ? can I add a few more ? Oh , yeah , yeah , go for

21:25

it . So , um , yeah

21:28

, i think I can actually

21:30

add a upper time limit when we're when we're

21:32

talking about algorithms . So practice

21:34

algorithms will usually have an associated timeframe

21:37

for that , so I would respect that

21:39

. Maybe you know , if you feel

21:41

like this is all really new to you , you could you

21:43

know 2x that , but if

21:46

you're spending more time than that , then you're going

21:48

to get diminishing returns in terms of , like , the

21:50

value of you trying to work on that

21:52

problem . If you're having difficulty then

21:54

I would identify what those concepts

21:56

are at play in that algorithm

21:58

. Uh , find easier algorithms

22:01

that stress those concepts or read

22:04

up on those concepts , you know , do something

22:06

else and then maybe come back to it

22:08

.

22:09

How do you identify those concepts ?

22:11

Yeah , So

22:13

that's , that's , that's the tricky thing . Um

22:15

, so my , my , once again . my site has

22:18

that mapped out . Um , it's

22:20

like you , you , you can't really

22:22

derive a concept

22:24

that you're not . it's incredibly

22:27

hard to derive some concept that you're not familiar with . So

22:31

you can recognize the concepts if , if

22:33

you are familiar with them , But

22:37

in terms of that derivation

22:40

, that's , i think , when you

22:42

need to work with a peer

22:44

or look up additional resources

22:46

.

22:46

Okay , Yeah

22:49

, that makes sense . How

22:53

do you Do

22:55

you think there's Okay

22:57

? I guess I'm going to ask two questions One

23:00

and I know like I think it's kind of challenging

23:02

your paradigm and I think the way I'm asking

23:05

it probably isn't the way that

23:07

you necessarily should think about it . So feel

23:09

free to challenge the way

23:11

I'm asking these questions . But

23:14

I think a lot of people are . They want to

23:16

get a solidified version of exactly

23:19

what they need to know where they're

23:21

going to be fairly competitive in the interviews

23:23

, they're going to be able to tackle the challenges that employers

23:26

give them . Would you say there's

23:28

like a fundamental list of like data

23:30

structures and algorithms where people should be

23:32

familiar with , where a lot of

23:34

You can kind of expect that a

23:36

lot of companies are going to touch on one of these .

23:41

I would . Yeah , so

23:43

there are lists out there , i

23:45

have my own and I

23:47

think , just for completeness , perhaps

23:49

I could just run through it . It's , i

23:52

think , a little over 20 concepts right now , so

23:55

for the ones that I think warrant additional

23:58

explanation , i will

24:00

do that . So , values versus references

24:02

this is something that trips people up a

24:04

lot in

24:07

JavaScript , so you can look

24:09

that up . Truthiness this one's

24:11

quite simple but

24:13

shows up a lot . So

24:16

the number one is a truthy

24:19

value and

24:21

the empty string is a falsi

24:23

value . So in

24:26

JavaScript , say , if you have an if statement , anything

24:28

inside of that parentheses , it just cares

24:30

about the truthiness of that . It doesn't care if it's

24:32

literally the value true or literally

24:35

the value false . So

24:37

like if parentheses zero , that

24:40

if statement is not going to execute . So

24:43

understanding that is

24:45

really important . Fortunately , it's

24:47

also really simple . Actually

24:51

, i think a lot of these concepts on their own are

24:53

simple and really just the complexity arises when

24:55

you put them together and put it into practice

24:57

. So

25:00

a closure that's

25:02

essentially the extra

25:05

variables that you have in the current scope and the parent scope

25:07

. So if those are confusing that's

25:09

confusing terminology then look

25:11

it up in your own time . Data

25:15

structures So array

25:17

, hash , table , link , list , tree

25:19

, triay , which is actually pronounced tree

25:21

, but I deliberately pronounce triay to

25:23

disambiguate the two raft

25:27

sorting

25:31

, queue

25:34

, stack , heap , maybe

25:36

, recursion

25:40

, breadth-first search , depth-first

25:42

search , combinations

25:45

and permutations These two are

25:47

quite similar . A combination is

25:51

essentially a subset of

25:53

a collection of elements . So if

25:55

I have an array of

25:57

the values one , two , three an

26:01

array of just one is a

26:03

combination of that , and

26:07

actually combinations includes the original array

26:09

. So order does not matter . But

26:11

in permutations a permutation

26:14

is just in a rearrangement of those values

26:16

. So there's a lot of programming

26:19

problems that are that

26:22

focus on anagrams . So

26:25

anagrams are you take a word and you rearrange

26:27

the letters and then you get another word . That's

26:29

a permutation problem . There's a lot of permutation

26:32

problems and there's a lot of combination problems . So

26:34

if you recognize those two , then

26:36

right , you can of course reuse the

26:38

knowledge you already have around . All those things

26:40

, yeah , runtime

26:42

, complexity , caching , backtracking

26:46

, which isn't as scary as it sounds functional

26:50

programming and greediness

26:53

, a greedy algorithm versus

26:56

a more exhaustive search . So

26:59

there's

27:01

another really

27:03

popular dynamic programming problem

27:06

depending on the input

27:08

data which

27:11

is given an

27:14

amount , say

27:17

a dollar amount , what

27:20

is the optimal breakdown

27:23

of coins to

27:25

match that amount ? So

27:28

fortunately , with the

27:30

USD

27:32

, our currency

27:35

system , that is an algorithm

27:37

that can be solved greedily , so

27:39

you can just start

27:41

with the biggest value that is smaller

27:43

than what you have left and subtract as

27:46

many of those as you can and then go

27:48

down to the next biggest coin

27:50

and so on and so forth until you have no

27:52

money left . That's a greedy

27:54

algorithm . So this is really just going

27:57

down one path , and an exhaustive search would

27:59

be if there's some coin

28:01

denomination that's a little more awkward where

28:03

maybe you have some coin that's worth seven

28:06

and another coin that's worth six . So

28:10

let's say you have 12

28:13

, okay

28:16

, seven , six and one are the coins . So let's say

28:18

you have 12

28:20

as the amount

28:22

that you want to break down . If you do a greedy

28:24

, you take away seven and then you have five

28:27

left and you need five ones . So

28:30

that's not optimal . You

28:32

could instead do two six coins

28:35

, if that makes sense . So

28:37

greedy versus non-greedy that's

28:40

a really important one to recognize if the

28:42

algorithm that you're working on can be

28:44

solved greedily or not . So

28:48

yeah , i think that is a very

28:50

good starting

28:53

point . Starting point

28:55

That's like 80% of it really

28:57

, i would say .

28:59

Okay , 80% , Would

29:02

you say . I appreciate you breaking that down

29:04

. I mean , some of this was just a refresher for

29:06

me and I didn't know about the greedy

29:08

algorithm concept . Even So , I

29:10

appreciate you explaining that . Do

29:14

you like diving into

29:16

caching or learning

29:19

to navigate through

29:21

a graph ? Do you feel

29:23

like ? I guess I feel like

29:25

that's too complicated for an entry level

29:27

developer ? Do you feel

29:30

like companies are testing

29:32

for entry level positions with this complex

29:35

of data structures ?

29:37

Well , it

29:40

depends , they are absolutely . Caching

29:43

doesn't come up quite as much , but

29:46

it is useful . There's

29:49

a really popular saying that the two hardest things

29:51

in computer science are caching and naming

29:53

things . Caching

29:55

gets particularly difficult when you're dealing

29:58

with distributed systems and race conditions and

30:00

things like that . And you're usually

30:02

not worrying about distributed

30:05

systems and race conditions if

30:07

you're doing an algorithm interview . It's just

30:09

all one machine . There's no internet connection

30:11

, There's no asynchronous behavior . So

30:13

caching in that sense I think , is

30:15

greatly simplified for

30:17

the algorithm interview scope

30:20

, usually certainly for entry

30:22

level . And

30:24

then you're talking about traversal . Is that

30:26

complicated ? Maybe ? I

30:29

generally think no . If

30:31

you have a data structure like a tree

30:34

and a binary

30:38

tree or a link list or a graph

30:40

, they're really

30:42

not that useful if you can't traverse

30:44

them . So if we you know

30:46

Nick's traversing graphs

30:49

also just let's have

30:51

some nomenclature here a link list

30:53

and a tree are types of

30:55

graphs with additional restrictions

30:58

imposed , so they're all

31:00

graphs . If

31:03

you just

31:06

Nick's traversing graphs , then you

31:08

can't really use graphs . So

31:11

these graphs , these

31:13

different types of graphs , show up on a lot of algorithms

31:15

and traversing them Just

31:18

to correct .

31:19

I didn't mean to put the focus on the traversing

31:21

part , I just said graphs .

31:24

Oh , graphs . Okay , Well , traversing

31:26

is the most of the work that you do with the

31:28

graphs And it's

31:30

just whatever you do with the data that

31:34

you have at the node that you're looking at . So

31:37

, yeah , i think

31:39

, as I said before once or twice in

31:41

this chat , so far the

31:45

concepts on their own are

31:48

usually quite simple . It's just the complexity

31:50

gets introduced once you compose them

31:52

together .

31:59

Yeah , Okay , but

32:02

with your coaching

32:05

sessions , what types of developer

32:08

jobs are people typically aiming

32:10

for to get that kind of help from you ?

32:16

So the way I'm presenting myself online , i'm

32:18

focusing on entry level . I

32:21

do have some other end on clients

32:23

that are five

32:26

, 10 years experience , like level

32:28

six , level seven at Fane

32:30

companies . What

32:34

types of jobs are they looking for

32:36

? That's a great point

32:38

. So what types of jobs are they looking

32:40

for ? What types of jobs should they be looking

32:42

for ? Two

32:45

different things . So I've actually seen

32:47

this quite a lot with the candidates

32:50

, my

32:52

clients , my

32:55

mentees , whatever you want to call them , the

32:58

people that I work with . They

33:02

can have a tendency right . So there's

33:05

this notion that job

33:07

descriptions are wish lists And

33:10

that's true to a degree . But someone

33:13

that has zero work experience probably

33:15

should not be applying for a job that

33:17

requires four years of experience . And

33:21

a lot of companies , especially

33:23

the smaller ones that don't have

33:25

their interview process ironed out as much

33:27

as the bigger companies , will

33:30

be more likely to pass

33:33

someone with

33:35

no professional work experience in the early

33:37

stages of the interview . So for

33:40

people that have no professional

33:42

work experience and are applying for roles

33:44

that are too difficult , what that often

33:46

looks like for them is that they

33:50

have a call . They do well

33:52

in the culture fit . When they get into

33:54

tech algorithm interviews , maybe

33:56

they do do well on a

33:58

few of those And at the end

34:00

they always get the same response oh , we want

34:02

with someone else . And companies you

34:04

know , for liability or whatever reasons , they don't really like

34:06

to be transparent with you . At

34:10

some point someone likely realize oh well

34:12

, these other people have way more experience , so

34:14

we're going to go with them . So

34:17

what kind of jobs should

34:19

they apply for ? I'd

34:21

say zero to two years of experience , and

34:27

that's that

34:30

. So any of the interview process . I have a lot of opinions about

34:32

this . The interview process . Of

34:35

course they are interviewing you , but you are interviewing

34:37

them . It might

34:39

be a little difficult to be more selective

34:41

about the companies that you go work for

34:44

, but ideally

34:49

the company that you're interviewing , that is

34:51

interviewing you , is one that you

34:53

somewhat

34:56

enjoy the interview process with . They

34:58

ask the

35:01

engineers that interview you are people

35:03

that you enjoy talking

35:05

to . You can have an interesting conversation with them

35:07

. There's

35:10

different styles of interviews , so maybe they

35:12

do let you flounder a little bit in the interview , but

35:16

you get this kind of gut . chuck this

35:18

gut impression of like , do I actually like this company ? And

35:20

I think that's something you should respect

35:22

while you're interviewing . So

35:25

, yeah , there's a

35:27

lot of extra context , but I would say zero

35:29

to two years , and

35:36

then a company that feels good in whatever way that means to you .

35:40

Yeah , no , that makes a lot of sense

35:42

. Do

35:46

you feel like ? So , thinking about , like the

35:48

I'm going to dive deeper into this Thinking

35:50

about the different company sizes

35:52

and different types

35:56

of tech teams , or if it's like a tech

35:58

focus company versus a

36:00

company that isn't so tech focused but it has a tech

36:03

team , like it's not building a product

36:05

but it does have internal tooling and a website

36:07

for its

36:10

own internal stuff . So

36:12

do you notice

36:14

certain types of companies

36:17

that will maybe

36:19

like prioritize

36:21

heavy project work

36:24

, run through your implementation

36:26

right , because

36:28

sometimes you get take home projects , sometimes you get on

36:30

the spot coding challenges . Sometimes those challenges

36:32

will creep into kind of like leak code territory

36:35

And like sometimes they just really truly

36:37

want to understand . Like do you understand the quirks

36:39

of JavaScript ? and

36:42

like try to dig into . Like how much

36:44

should you Like what foundational

36:46

knowledge do you truly have of this language or

36:48

programming ? Do you

36:50

find that there

36:52

are commonalities with certain types

36:54

of companies And , if you do , what

36:57

types of companies usually challenge you

36:59

? in what types of ways ?

37:01

Yeah , great question . So I think this is a simpler question

37:04

for people that are getting into the industry . when you're more

37:06

senior than a lot of you know , more

37:09

things are assumed . So

37:11

if you're newer to the industry , i'd

37:14

say this has actually changed in the last five

37:17

or so years

37:20

. my answer to this Let's

37:23

for simplicity , let's focus

37:25

on people that are going into front

37:28

end and you can translate to whatever your stack

37:30

is for the listener . Yeah

37:35

, so obviously

37:38

algorithms , i think , are always fair game . Other

37:42

interview formats there can be right

37:44

, there can be some project where maybe

37:46

they have you fix a bug or add a feature

37:48

, or maybe they go into one of your projects that

37:50

you've worked on previously and ask you to add a feature

37:52

. Take-homes are always

37:54

likely , but I think there's some ethical implications

37:57

that go into that in terms of how much time

37:59

you should spend , how much time

38:01

the interviewer

38:04

should expect you to spend on

38:06

that , and I think also

38:09

those take-home challenges should only

38:11

be given after you have actually spoken

38:13

with someone at the company . So

38:23

I lost . my train of thought Was

38:25

the original question again .

38:27

So yeah , you were diving into . Sometimes people

38:29

or companies would give take-home

38:31

questions and

38:34

you kind of talked about the ethical concerns of

38:36

it . The original question , the

38:38

original question essentially , was what

38:41

types of companies are going to offer what types of

38:43

problems ? I think you just started with front-end

38:46

positions is kind of where .

38:49

Thank you , yeah , right , so , okay , great

38:51

, now I'm back up to speed , so I

38:53

remember that question I forget easily . A

38:57

lot to say Yeah , so right

39:00

. So once again , a little simplified for people

39:02

that are starting in the industry , specifically front-end

39:04

engineers algorithms

39:08

, those concepts all

39:10

fair game . And

39:14

then there's ubiquitous

39:16

technologies . Now There

39:19

are technologies that are really expected

39:21

of you to know in pretty

39:24

much all roles , so I would say

39:26

React is one of those . You

39:29

know NPM , git , of

39:34

course , html CSS . You

39:37

have to use those , unless

39:40

you're using React Native , which

39:42

diverges from that for good

39:45

reasons , i imagine . Yeah

39:50

, so that you

39:52

know . I think that's

39:55

my answer . Okay .

39:57

Yeah , so for front end , I

39:59

mean , i agree , html , css , javascript React

40:02

. I think you are . Here's my

40:04

. Actually let me get your opinion with this because

40:06

and

40:08

maybe you can kind of you can just correct

40:10

me So I've always had just

40:13

hearing from what a lot of people say , like

40:15

if you dive into aiming for a front

40:17

end role , typically , yeah , html , css , javascript

40:20

, react , and

40:22

you're typically going

40:24

to get tested more on , like walking

40:26

through implementation , maybe a take home project

40:29

And I love what you said like you

40:31

need to , you almost need to fight for your time

40:33

. And how do you do that as a new developer

40:35

when you don't know how much time you should invest into it ? I

40:37

don't think you should be investing five hours into a personal

40:39

project take home if they're not going to be paying right

40:42

. But I feel like

40:44

they're mainly testing for

40:46

like good fundamental knowledge of whatever the

40:48

stack they're going to be hiring you for . They

40:51

just want to see you build something like how

40:53

quickly can you get up , hit the

40:55

ground running and how solid

40:57

? and they I think a lot of them usually assess

41:00

that through your foundational knowledge with JavaScript

41:02

in general . And

41:04

so they're like I've heard of

41:06

tons of tests and I've been through . You

41:09

know one or two myself where they'll

41:11

like test the quirks of JavaScript

41:13

, like how well do you truly know JavaScript

41:16

? And that's where I see what's front end

41:18

. But with back end positions it feels

41:20

or full stack or back end positions , it feels more

41:23

there's more of a focus on

41:25

data structures and algorithms . It gets a little bit

41:27

more complicated with the types of coding challenges

41:30

that you're going to be given And

41:32

I think that's where , like the huge controversy of like

41:34

some of the challenges that are given

41:36

, you know it's not very clear

41:39

how that's going to apply to like practical

41:41

skills on the job , but it

41:43

just feels like back end , more

41:45

back end focused positions are more focused

41:48

on data structures and algorithms , where front end is

41:50

more foundational and practical .

41:52

Yeah , that I

41:55

wrote a few words so I don't forget what I'm talking about

41:57

. Great , great

41:59

point Thank you

42:01

for , because this is also touching on stuff that I wanted to say

42:03

previously . I want to amend or

42:05

add something to that list of ubiquitous technologies

42:07

TypeScript . I think that's

42:10

a fantastic tool , in my opinion , essential

42:13

for any non-trivial project . If

42:16

your code is difficult to

42:18

type with TypeScript , it's difficult to

42:20

reason about , and if it's difficult to reason about , it's

42:22

bad code . So

42:24

TypeScript doesn't mean

42:26

that you're going to write good code , but if

42:29

you could , yeah , that's

42:34

my hot take . In

42:37

terms of what to expect of the interview format

42:40

. There is convergence to

42:43

a degree across the companies , and

42:47

so you were talking about these different companies

42:49

that are , say , just getting into tech

42:51

. Yeah

42:56

, so it's always fair game to

42:58

ask what the interview format is going

43:00

to be like , and almost

43:03

always actually always in

43:05

my experience they will tell you oh

43:07

, this is going to be an algorithms

43:10

interview or system design or whatever

43:12

. So

43:14

that can help you Certainly

43:17

ask for more context if you feel like you

43:19

would need that . That is

43:21

fair game . Please , please do that

43:23

. That is super important . And

43:27

then you were also talking about the quirks of

43:29

JavaScript specifically , which I would say

43:31

for historical reasons , there are more

43:34

of those . So

43:38

there's this influential

43:42

author , douglas

43:45

Crockford I don't know if you've heard

43:48

the name before . He wrote this book

43:50

called I think

43:52

it was like the good and bad parts of JavaScript , which really

43:55

outlined , was quite

43:57

prescriptive in terms of use

43:59

these things in JavaScript and don't use these

44:02

things . I think a lot

44:04

of the stuff in that book actually

44:06

has become somewhat

44:08

obsolete because of the convergence around

44:11

tooling that we're using , like

44:13

linting , eslint , like

44:15

Webpack , the way that we bundle

44:17

files together , functional

44:21

programming , like this keyword

44:24

, if

44:28

this keyword , the word this

44:30

in JavaScript has a lot of weird behavior

44:32

, but with the patterns

44:34

that we use , those weird behaviors show up a

44:36

lot less often . So

44:41

I think the peculiarities are shrinking

44:44

in a way , but there are some

44:46

that are quite common . So

44:48

I don't know if you ran into this , don , but if you

44:50

have an array

44:52

of numbers between one and 10 , and you

44:55

just do the one , two , three , four , five , six

44:57

, seven , eight , nine , 10 array dot sort , it

44:59

will actually give you one , 10

45:01

, two , three , four , five , six , seven

45:03

, eight , nine , and that's

45:06

because it converts

45:09

each number to

45:11

a string before it compares which

45:13

order they should be in . So let's

45:15

go into a few concepts here . So

45:18

the sort function in JavaScript

45:21

can take an optional comparator

45:24

, a function that will take

45:26

two arguments let's call them A and

45:28

B that you

45:30

can use to determine the relative order

45:33

of those two arguments . So if you want A

45:35

to be before B , you return a negative value

45:37

in that callback . If

45:40

they should be in the same place , you return

45:42

zero . Otherwise you return one

45:44

, really just

45:46

a negative number or zero or a positive

45:48

number , so you

45:51

can customize your sorting logic

45:53

. So the way to get the expected

45:55

behavior for sorting numbers in JavaScript would be

45:57

to pass a comparator

46:00

that takes arguments A and B and

46:02

returns A minus B . So

46:06

that would do the sorting . Yeah

46:10

, i could get into that a little bit

46:13

. There's some really interesting

46:15

additional concepts in terms of higher

46:17

order functions and stable sorting

46:20

, but interest of time , we'll

46:22

maybe see that later .

46:25

Yeah , no , i mean , i

46:27

would probably find you to be very helpful

46:29

If you ran me through some of these problems . I

46:32

think the way that you describe them

46:34

I think you're very great at simplifying

46:37

it in a way where

46:39

you're just used to breaking it down

46:41

into different concepts , and

46:44

I think that's what's going to be helpful to remember

46:46

is like because I'm telling you so many

46:48

people that I talked to they're just so overwhelmed with

46:50

data structures and algorithms and they have this end goal

46:53

in mind that's very unreachable

46:57

, abstract , like they can't even solidify it , they

46:59

don't know when the finish line is right . And

47:02

I think what you're trying to teach is like , as

47:04

you're learning fundamental concepts , as

47:06

you're going through coding challenges , eventually they're

47:08

going to kind of blend together and these coding

47:11

challenges will give you that

47:13

exposure to how these fundamental concepts

47:15

can be used in a more complex

47:17

manner as building blocks in more practical

47:20

types of problems , right

47:22

. So I love the idea , the advice that

47:24

you've given , just kind of like , get some exposure

47:26

to these concepts and work on it every day And

47:28

then , as you learn programming in

47:30

general , like it kind of just seems like you're blending

47:32

them together And with

47:34

that exposure I think it's

47:37

going to be easier to start solidifying , kind

47:40

of just like a little bit more of a linear path

47:42

into data structures , more complex

47:44

data structures .

47:48

So I wouldn't necessarily say it's a linear path . I would say

47:50

it's more of a tree or

47:52

just a graph

47:54

. Traverse the graph and learn what you need

47:56

to learn on demand . Yeah

47:59

.

47:59

No , that's fair . I think that's a good correction , thank you . But

48:02

, like it also kind of what we were solidifying

48:05

with it sounds like like

48:08

there's a huge emphasis on

48:10

quirks , especially in the JavaScript

48:12

world . There's a huge emphasis on quirks , if you truly want

48:15

to understand the language , and I would almost

48:17

argue it's like some of these abstractions and the

48:19

way we bundle things . I

48:21

would argue companies are still trying

48:23

to test , if you kind of understand what's happening

48:25

under the hood . I think a lot of teams understand

48:28

how these bundles create these abstractions

48:30

and I think it kind of causes developers to be lazy

48:32

. I feel like there are developers that do

48:35

understand that that I've worked with and

48:37

I find that just

48:40

like , even with my second interview

48:42

at a company , they were really fascinated with me understanding

48:45

like weird set timeout , quirks and

48:47

stuff like that . They wanted me to understand the

48:49

language thoroughly And

48:52

I still did a React challenge . But

48:54

the conversations that I

48:56

had at that company were like I

48:58

remember being introduced to you don't know JS

49:00

, which kind of started to upgrade me a little

49:03

bit with my JavaScript skills And then I just

49:05

expanded from there . But anyways

49:07

, what I'm trying to say is I think

49:09

your emphasis on like it seems like you kind

49:11

of keep digging into like some of the quirks

49:13

of JavaScript and trying to break that

49:15

down into like what concepts you

49:17

truly need to understand . I think it's going to eventually

49:20

develop a good foundation to

49:22

be able to tackle some of the challenges that

49:25

you're going to be facing in the interviews . That

49:27

is a long-winded response , but do you feel like

49:29

what I said was fairly accurate ?

49:32

Yeah , let me add a little bit more color

49:34

. Okay , yeah , i

49:39

have seen that there is less

49:41

emphasis on the quirks with the newer hires

49:44

, but of course there are quirks that do show up quite

49:46

a lot . I wouldn't really call

49:49

set time behavior weird set timeout

49:51

behavior quirks . I think that's actually

49:54

quite instrumental to the language

49:56

, to JavaScript . So JavaScript

49:59

going to do a few more concepts is

50:02

a non-blocking language . So

50:04

in Python or pretty much

50:06

every other language , you can sleep

50:09

. You can have the current thread sleep

50:11

. You

50:15

can say threadsleep for 3000 milliseconds

50:17

, more reasonable , and

50:20

then that thread will wait that

50:22

long and then pick up where it left off . There

50:25

is no sleep in JavaScript And you could

50:27

do just some while loop that locks

50:30

the execution

50:33

. In

50:36

JavaScript and the web

50:38

. You're probably working on

50:40

the UI thread , unless you're doing

50:43

web workers or anything like that . That's

50:45

additional complexity . But

50:49

if you have some hot while loop like

50:52

that that's just waiting for three seconds

50:54

to pass , then the page will be stuck

50:56

. People don't do that . So

51:01

you have to use set timeout

51:03

, set interval and

51:05

similar functions to schedule things

51:08

, and I do

51:10

actually really like to

51:12

see a solid understanding of

51:14

the event loop . There's

51:19

some fantastic resources around the event loop that I

51:22

found . I don't have them on top of my head

51:24

right now , but event

51:26

loop if that's confusing

51:28

to you , then look that up in JavaScript and

51:30

I'm sure you'll find something good . Yeah

51:36

, javascript is

51:38

one of the few languages that

51:40

is

51:43

non-blocking , so

51:47

there's additional complexity

51:50

and significance to set

51:52

timeout and set interval . Yeah .

51:54

Okay , All right . Well , I appreciate

51:57

how much you've really dug into some

51:59

of the technical details to explain some

52:02

of these concepts . I think you do a really good job

52:04

at that . But anyways , yeah , I

52:07

do want to be conscientious

52:09

of your time . We're pretty much out of time . Matt

52:13

, like I said , I meant when

52:15

I said this . I do think if you and I

52:17

had a one-on-one session , I do feel

52:20

like you would be someone that

52:22

would be able to be empathetic and thoroughly

52:24

explain things but also help

52:27

me understand the problem in a way that , where

52:30

your whole philosophy is like okay , break this

52:32

down into its concept . So what do you truly

52:34

need to understand And what are those building blocks

52:36

? Let's learn those and then we'll build up to this

52:38

, Because I feel like that's the way

52:40

you do things And I think that's a great strategy

52:43

. But yeah , I guess I'm just

52:45

shouting out a bit . But

52:47

if you wanted to share anything , if

52:49

people wanted to connect with you on social media

52:52

or get further help

52:54

, if they're truly stuck with data structures and algorithms

52:56

or trying to get interview prep , anything like that

52:58

, what would you like to share with us ?

53:01

Yeah , thanks . So

53:03

you can find me at coachmatio

53:05

. So , coachmatio

53:08

, i

53:10

do currently one-on-one

53:13

sessions And then I also do

53:15

asynchronous support . So I call the one-on-one session

53:18

synchronous support and then the other one asynchronous support

53:20

. I also have this platform that I've been mentioning

53:22

a handful of times where you can practice

53:24

algorithms , and there's this additional context

53:27

and graph

53:29

of concepts that you can explore And

53:32

there's some really exciting features that I'm going to be adding to

53:34

that shortly . So

53:36

I'm on YouTube

53:38

. You'll find everything through my site

53:40

. I'm going to be branching out

53:43

into other social platforms , but that's

53:45

all coming . Sounds

53:49

good .

53:50

Well , seriously , thanks so much for coming on , matt . In the

53:52

comments , let us know what

53:55

you thought . I feel like this is just an area

53:57

where there's so much advice going

53:59

on , so much advice given on

54:01

Reddit , twitter , and I feel like it's very

54:04

, very conflicting . So I wanted to

54:06

do this episode just because this could

54:08

even be an intro branch into

54:10

bringing other people on to

54:12

talk about data structures and algorithms . But

54:15

yeah , if you liked this episode , let me know . If

54:18

you have any questions , anything like that , you want to talk in the comments

54:20

, feel free to leave it there . But

54:22

yeah , matt , thank you so much for coming on

54:24

, thank you .