September 11, 2024 • 17 mins
Are your personal projects failing to get you hired? In this video, I break down the common mistakes aspiring developers make with their projects and why they aren't standing out to employers. Many think that just building a variety of projects is enough, but the scattershot approach often misses the mark. I’ll guide you through a more strategic way to approach personal projects that will resonate with hiring managers.
We’ll dive into the importance of targeting your projects towards the industry you care about, building meaningful and professional-looking projects, and understanding the Minimum Viable Product (MVP) concept to know when a project is truly "done." I'll also discuss how unfinished projects on your GitHub can send the wrong signals about your commitment and consistency.
Throughout the video, I encourage you to think beyond just coding for the sake of it. You need to create something that solves real problems, adds value, and even gains users. I'll share tips on showcasing your projects effectively to signal your potential as a valuable developer who can contribute real results.
If you're tired of your personal projects feeling like wasted efforts, watch this video to learn how to build projects that actually catch the eye of employers. Don't just build—build with purpose, build with strategy, and start turning your ideas into assets that move your career forward.
---------------------------------------------------
🔥 Webdev Career Help - https://calendly.com/donthedeveloper/coaching
🎮 Join Discord - https://discord.gg/TpQe2k8Ab3
❤️ Support What I Do - https://www.patreon.com/donthedeveloper
Disclaimer: Some product links are affiliate links which means if you buy something I'll receive a small commission at no extra cost to you.
===========================
WEBDEV COURSES I HIGHLY RECOMMEND:
🎓 Learn Frontend - Scrimba (20% off): https://scrimba.com/the-frontend-developer-career-path-c0j?via=donthedeveloper
🎓 Learn Backend - Boot.dev (25% off): https://boot.dev/?promo=DONTHEDEVELOPER - Get 25% off your first payment with code "DONTHEDEVELOPER"
🎓 Already Experienced? Level Up Here - Code Crafters (40% off): https://app.codecrafters.io/join?via=donthedeveloper
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Don Hansen (00:00):
All right, let's talk about why your personal
projects aren't getting youhired.
I hear this all the time.
You got to build personalprojects to show your experience
, to be marketable to employerswhen you don't have experience.
This is all true, right?
I think people just do it thewrong way, and you know,
(00:25):
understandably, because there'sa lot of advice on personal
projects.
There's a lot of differenttypes of personal projects that
you see come out of CS degrees,coding bootcamp, self-taught
people and different courses and, like you know, should you
build or include your tutorialbased projects in your courses?
What about that mini projectyou built to get a little bit
(00:48):
more comfortable with JavaScript?
Should it include a framework?
Like, it's really hard to know.
And you know why it's sodifficult, because I think
people have this misconceptionthat, quite frankly, that you
even need a personal portfolioto showcase your projects in
this traditional sense, right, alot of people think they need,
(01:09):
like, a variety of projects toapply to a variety of companies
and maybe one of those projectswill stand out to one of those
companies and you're kind ofjust throwing spaghetti at the
wall and that's the problem,right there, right, it's not,
not focused, it's not targeted.
A good, targeted approach is toapply for companies where
you're building shit thatthey're building right, um, at a
(01:31):
more basic level.
But you care about the industry, you, you want to work there
and you're probably going to fitinto the culture because, like
you, you just care about theproblems that they're solving.
You care about the users thatare going to use that product
and I I think this wholespitfire approach of just you
know, building is a variety andas much as you possibly can to
(01:51):
see if one thing sticks iswhat's hurting you, right.
So I want to encourage a moretargeted approach, um, but a lot
of people will build a varietyof projects and for a second I'm
going to contradict what I justsaid and you should.
You should build that varietyof projects to reinforce what
(02:16):
you're learning, to get exposedor to essentially use what
you're learning in a differentcontext to help reinforce that
concept a little bit deeper.
You should build a bunch ofcrappy stuff Initially.
You shouldn't be focused onthis capstone project.
I'm going to build this.
(02:36):
You know, over the next sixmonths I'm going to build this
really impressive project.
Why that's putting a lot ofpressure on yourself and a lot
of people that do this end upjust overwhelming themselves
with that project.
Build a bunch of shitty projectsfirst.
You don't have to show theseemployers these shitty projects,
but a lot of us, a lot ofpeople that have made it into
(03:00):
the dev industry we built a lotof really bad stuff initially.
Now we built a little betterstuff, a little bit of better
stuff, and then better stuff,and then better stuff and then
better stuff over time and wewere able to build more complex
projects and then finally, wemight have a project that, like,
really speaks to us.
Like this would be a reallycool tool to build for
(03:22):
developers.
Or if I had this-based softwarein my old industry, like it
would have made my job wayeasier.
What if I could, like, just tryto build the basic version of
this, put some pricing on it,make it look professional and
try to sell it to some peoplelike that is a phenomenal
personal project to list on yourresume and you are capable of
(03:45):
that.
You are.
It's going to take more timethan a lot of your crappy
projects, and the problem isthat when people tackle stuff
like this, they give up.
They don't come back to theproject.
It's easy to start new greenprojects.
(04:05):
It's good, it just feels goodto get that dopamine hit, to not
struggle and just like, getinto a little bit of a state of
flow.
And you got to struggle, man,you got to struggle.
One thing that hurts a lot ofnew developers is you look on
their GitHub and they just havea graveyard of unfinished
(04:28):
projects.
What do you think that tellsemployers?
Like, if I'm reading into it,that tells me that you don't
really have much commitment.
You don't really know what kindof problems you want to solve.
It's okay for a project to besmall and done, but the problem
is that signals that maybe youlet imposter syndrome overwhelm
(04:57):
you, you give up too easily, youhave commitment issues, you
can't follow through, you'rejust chasing those dopamine hits
.
It could be any of the above oreven other things.
Don't give that signal.
Finish your shit.
But more importantly, I think alot of people I would say some
people, portion of those peoplethat don't finish their projects
(05:19):
.
They don't finish them becausethey don't know when done is
done, and this is a skill thatyou need to build up as a new
developer.
It's what is the mvp minimumviable product?
What is the base version ofthis thing that I'm trying to
build without adding a bunch ofbells and whistles.
What is the base version ofthis?
(05:40):
Let me go ahead and create achecklist of technical
requirements and when I finishthis checklist, this project is
done and make it so you canbuild this project within a
month, three weeks, two weeks,and then you could build on top
of that.
An MVP is just the initiallaunch of something right.
It's just the initial usablething of whatever you're trying
(06:03):
to build.
That solves this really simpleproblem.
A lot of companies are built onthis concept and then they
build features on top of that.
When they get feedback, becausethey gain a user or two, that
gives them that feedback,because they gain a user or two,
that gives them that feedback.
So, if that helps, considerlike coming up with a checklist
of things that you should, uh,that you need to complete before
(06:25):
you move on to the next project.
Now I think it's okay to have afew like functions, random
functions you build to test acertain concept, or just smaller
projects where they're not thatmeaningful.
You were just trying tounderstand a certain concept,
that's.
That's okay.
(06:45):
I don't think you have tocomplete every single project,
but you just want to be carefulif your github is littered with
a bunch of unfinished projects,you really have to be real with
yourself.
Are you creating a bad habithere or is there true purpose of
having all of these unfinishedprojects?
It's probably the former.
(07:05):
Another thing is, like I talkedabout making your projects look
professional, right, if you'rebuilding even a simple tool that
all aspiring developers canbuild, eventually that is usable
to someone, which you couldbuild, a tool that's usable to
you.
Right, it does a little bitlike if it's a fitness app.
It does some things a littlebit differently than your
(07:27):
current fitness app, but you canbuild stuff for yourself and
you are the initial user andthat's a great product to build
because you don't need to go outand do a bunch of user research
.
You know what you want and youcould expand that into other
users and see you know if theywant things a little bit
differently than you and how youcan adapt your product and
(07:47):
build more features to to helpother developers and I keep
using the word product and Ifeel like a lot of people get
overwhelmed with this Like theycan't build a product.
Yes, you can.
People that are just tinkeringto code build products all the
time they might not call it aproduct, but you know, they
build a website for their church, they build a tool for their
(08:11):
guild in World of Warcraft.
They build something that isuseful to them.
Now, is that going to be themost marketable personal project
?
Probably not, especially ifthere's not a lot of complexity
to it and it's not serving a lotof people.
But you have the capability ofbuilding a real product and you
(08:31):
should start thinking ofyourself as a product builder,
as a developer, even without adev job.
Holding yourself to thatstandard with that main capstone
project that you're eventuallygoing to build, that makes you
stand out to employers.
You know, like that's wherepeople stand out.
(08:52):
It's.
You might've heard of somecoding bootcamps that
hyper-focus on like a onesingular capstone project that
they spend months on and theythey polish it up.
It looks like a professionalproduct because they're capable
of it, just like you're capableof it.
And they also will take time tocreate good documentation on
(09:15):
how to boot this app up.
Right, if another dev wanted tospin it up let's say, another
dev on the team wanted to spinit up they should have clear
instructions on how to do so.
And if you are heavily focusedon backend positions.
There's just niche, nichethings that you can do, like
having whether it's like a selfdocumented situation or you got
(09:37):
to build, like manually build adocumentation for your API, like
having documentation for yourAPI for backend developers is
really powerful.
I don't think you have to go tothat extent if you are applying
for frontend positions.
In fact, you should question ifyou should dive into the
backend at all.
But documentation is somethingthat will also make your product
(09:58):
, your professional lookingproject, feel more professional,
and that's what it's about.
It's making it feel moreprofessional to employers.
And so I got to stress thisagain.
Like a big thing is and I hatethis question it's when people
ask others what they shouldbuild.
(10:19):
You got into coding for areason.
Don't tell me you don't want tobuild cool shit.
What the hell do you want tobuild?
If you look at other apps likewhat would even sound cool to
work on and build, you can getideas from other people for
inspiration, but you should notbe asking people to tell you
(10:42):
what you need to build.
You need to find that withinyourself.
What kind of problems do youneed to build?
You need to find that withinyourself.
What kind of problems do youwant to solve as a developer?
And this a lot of people areuncomfortable with this because
they haven't trained their mindto think about this.
You can brainstorm.
There are YouTube videos thatwill help you form a
brainstorming process if youfeel like you need a system in
place to do that.
But a lot of times it's justlike you know, if I could build
(11:12):
something for myself, what wouldit be?
Let's start with that.
Start with something right.
But I don't think you shouldjust be building a random thing
because someone else told you tobuild it.
A lot of times it's just goingto end up as a graveyard project
.
That's how a lot of graveyardprojects become graveyard
projects is because you didn'treally have enough interest in
the first place.
Right to follow through withthat.
And so focus on, like, what youcan build.
(11:33):
Start with yourself, but whatyou can build for your friends,
your family, your gamingcommunity, your local community,
your previous industry.
And if you struggle withbrainstorming, like, use chat,
gbt or another AI model to helpyou brainstorm some ideas, but
give it as much context aspossible about, like, what
(11:55):
you've been learning, what youwant to be challenged with, what
sounds interesting, maybe a funproject you've built in the
past got to be related to that.
What did you like about it?
Right Was right.
Was it gamified?
Include that in the context youprovide to ai.
Right.
So that's how you can reallyutilize ai to basically be like
a second brain that just makesyours better and it helps propel
(12:17):
you in the right direction bygiving a lot of great context
that is very unique to you.
But eventually, with thatcapstone project, I want you to
start thinking about it like areal professional product,
because I've seen this type ofpersonal project make so many
(12:39):
aspiring developers stand outand the final thing would be
like a failure to demonstrate,kind of like an improvement with
efficiency or addressing userneeds.
Right, so you've builtsomething that can help people.
What have you done to put itout there in front of people?
(13:01):
What have you done to gain auser base?
Even having five people usingyour app actively is way better
than so many of these otherpersonal projects that serve no
purpose.
You'd be surprised how easy itis to stand out among many other
aspiring developers when youbuild something that's useful
(13:25):
and people are using it.
You can list those userstatistics.
You can list revenue thatyou're getting.
It doesn't have to be revenue,it could just be usage.
Maybe build a mobile app andyou list the downloads in the
app store, right, but if peopleare using it, you're giving this
.
Well, you're getting the socialproof that then you're showing
(13:45):
employers that, hey, I can buildshit that provides real value
to people and if it providesreal value to people, you can
gain revenue off of it.
You can monetize that.
You might not be good atmonetizing that, but it has the
potential to.
And now you're just signalingto employers that, hey, maybe
this developer that we're hiringcan build.
(14:07):
You know that they know enoughto be able to build something of
real value for users and theycould build real value for us
and our users and gain usrevenue.
Right, you don't have to be anentire marketing department to
know how to do this.
But taking that initiative totry to get your app in front of
(14:27):
other people um, you know,whether maybe it's product hunt
or another website like thatposting it on twitter, linkedin,
saying and posting it andasking mods first, but posting
it in subreddits of differentcommunities of where this app
would actually be useful, um,you got to take that initiative.
But if you can gain or if youcan mark down certain statistics
(14:48):
like usage for your app, thatI'm telling you that personal
project gets bumped way higherand it's way more competitive in
employers' eyes than all theseother random personal projects
that serve no purpose.
So you can also well.
Yeah, I think I'm going toleave it with that.
(15:10):
I think the big message that I'mtrying to deliver right now is
it's okay to start with avariety of projects.
It's okay to build a bunch ofcrappy stuff, but eventually I
want you to start focusing moreon the model of building that
capstone project, that finalproject that is useful, that
(15:35):
provides real value to people,gains a user base where it looks
professional, feelsprofessional on the source
control side you have a properreadme it feels professional on
that end as well.
You care about the code quality, because now you're scaling the
app, because you're asking foruser feedback.
So you're going through theagile process of wanting to
(15:55):
iterate on your app and you getuser feedback and you adopt a
scrum process.
You write tickets of featuresand bugs you've got to fix and
then you just launch you knownew fixes very quickly and push
it out and get more feedback,and this is a cycle.
So now you've involved yourselfin a professional process the
agile and the scrum processright, professional process, the
(16:16):
agile and the scrub processright, you're not going to do
this the right way the firsttime.
Right, and maybe what I'vedescribed to you sounds a bit
advanced and overwhelming andyou got to try it.
And it starts with justbuilding that one tool for
(16:38):
yourself and expanding fromthere.
If you're intimidated byeverything else, what like today
, if I could start a new projectand finish it in a month and
produce an mvp, and then I'llthink about, like, pushing it
out to other people, then if youcould build one project today
for one month and you have tolaunch it at the end of that
(16:59):
month.
All right, let's talk about why your personal
projects aren't getting youhired.
I hear this all the time.
You got to build personalprojects to show your experience
, to be marketable to employerswhen you don't have experience.
This is all true, right?
I think people just do it thewrong way, and you know,
(00:25):
understandably, because there'sa lot of advice on personal
projects.
There's a lot of differenttypes of personal projects that
you see come out of CS degrees,coding bootcamp, self-taught
people and different courses and, like you know, should you
build or include your tutorialbased projects in your courses?
What about that mini projectyou built to get a little bit
(00:48):
more comfortable with JavaScript?
Should it include a framework?
Like, it's really hard to know.
And you know why it's sodifficult, because I think
people have this misconceptionthat, quite frankly, that you
even need a personal portfolioto showcase your projects in
this traditional sense, right, alot of people think they need,
(01:09):
like, a variety of projects toapply to a variety of companies
and maybe one of those projectswill stand out to one of those
companies and you're kind ofjust throwing spaghetti at the
wall and that's the problem,right there, right, it's not,
not focused, it's not targeted.
A good, targeted approach is toapply for companies where
you're building shit thatthey're building right, um, at a
(01:31):
more basic level.
But you care about the industry, you, you want to work there
and you're probably going to fitinto the culture because, like
you, you just care about theproblems that they're solving.
You care about the users thatare going to use that product
and I I think this wholespitfire approach of just you
know, building is a variety andas much as you possibly can to
(01:51):
see if one thing sticks iswhat's hurting you, right.
So I want to encourage a moretargeted approach, um, but a lot
of people will build a varietyof projects and for a second I'm
going to contradict what I justsaid and you should.
You should build that varietyof projects to reinforce what
(02:16):
you're learning, to get exposedor to essentially use what
you're learning in a differentcontext to help reinforce that
concept a little bit deeper.
You should build a bunch ofcrappy stuff Initially.
You shouldn't be focused onthis capstone project.
I'm going to build this.
(02:36):
You know, over the next sixmonths I'm going to build this
really impressive project.
Why that's putting a lot ofpressure on yourself and a lot
of people that do this end upjust overwhelming themselves
with that project.
Build a bunch of shitty projectsfirst.
You don't have to show theseemployers these shitty projects,
but a lot of us, a lot ofpeople that have made it into
(03:00):
the dev industry we built a lotof really bad stuff initially.
Now we built a little betterstuff, a little bit of better
stuff, and then better stuff,and then better stuff and then
better stuff over time and wewere able to build more complex
projects and then finally, wemight have a project that, like,
really speaks to us.
Like this would be a reallycool tool to build for
(03:22):
developers.
Or if I had this-based softwarein my old industry, like it
would have made my job wayeasier.
What if I could, like, just tryto build the basic version of
this, put some pricing on it,make it look professional and
try to sell it to some peoplelike that is a phenomenal
personal project to list on yourresume and you are capable of
(03:45):
that.
You are.
It's going to take more timethan a lot of your crappy
projects, and the problem isthat when people tackle stuff
like this, they give up.
They don't come back to theproject.
It's easy to start new greenprojects.
(04:05):
It's good, it just feels goodto get that dopamine hit, to not
struggle and just like, getinto a little bit of a state of
flow.
And you got to struggle, man,you got to struggle.
One thing that hurts a lot ofnew developers is you look on
their GitHub and they just havea graveyard of unfinished
(04:28):
projects.
What do you think that tellsemployers?
Like, if I'm reading into it,that tells me that you don't
really have much commitment.
You don't really know what kindof problems you want to solve.
It's okay for a project to besmall and done, but the problem
is that signals that maybe youlet imposter syndrome overwhelm
(04:57):
you, you give up too easily, youhave commitment issues, you
can't follow through, you'rejust chasing those dopamine hits
.
It could be any of the above oreven other things.
Don't give that signal.
Finish your shit.
But more importantly, I think alot of people I would say some
people, portion of those peoplethat don't finish their projects
(05:19):
.
They don't finish them becausethey don't know when done is
done, and this is a skill thatyou need to build up as a new
developer.
It's what is the mvp minimumviable product?
What is the base version ofthis thing that I'm trying to
build without adding a bunch ofbells and whistles.
What is the base version ofthis?
(05:40):
Let me go ahead and create achecklist of technical
requirements and when I finishthis checklist, this project is
done and make it so you canbuild this project within a
month, three weeks, two weeks,and then you could build on top
of that.
An MVP is just the initiallaunch of something right.
It's just the initial usablething of whatever you're trying
(06:03):
to build.
That solves this really simpleproblem.
A lot of companies are built onthis concept and then they
build features on top of that.
When they get feedback, becausethey gain a user or two, that
gives them that feedback,because they gain a user or two,
that gives them that feedback.
So, if that helps, considerlike coming up with a checklist
of things that you should, uh,that you need to complete before
(06:25):
you move on to the next project.
Now I think it's okay to have afew like functions, random
functions you build to test acertain concept, or just smaller
projects where they're not thatmeaningful.
You were just trying tounderstand a certain concept,
that's.
That's okay.
(06:45):
I don't think you have tocomplete every single project,
but you just want to be carefulif your github is littered with
a bunch of unfinished projects,you really have to be real with
yourself.
Are you creating a bad habithere or is there true purpose of
having all of these unfinishedprojects?
It's probably the former.
(07:05):
Another thing is, like I talkedabout making your projects look
professional, right, if you'rebuilding even a simple tool that
all aspiring developers canbuild, eventually that is usable
to someone, which you couldbuild, a tool that's usable to
you.
Right, it does a little bitlike if it's a fitness app.
It does some things a littlebit differently than your
(07:27):
current fitness app, but you canbuild stuff for yourself and
you are the initial user andthat's a great product to build
because you don't need to go outand do a bunch of user research
.
You know what you want and youcould expand that into other
users and see you know if theywant things a little bit
differently than you and how youcan adapt your product and
(07:47):
build more features to to helpother developers and I keep
using the word product and Ifeel like a lot of people get
overwhelmed with this Like theycan't build a product.
Yes, you can.
People that are just tinkeringto code build products all the
time they might not call it aproduct, but you know, they
build a website for their church, they build a tool for their
(08:11):
guild in World of Warcraft.
They build something that isuseful to them.
Now, is that going to be themost marketable personal project
?
Probably not, especially ifthere's not a lot of complexity
to it and it's not serving a lotof people.
But you have the capability ofbuilding a real product and you
(08:31):
should start thinking ofyourself as a product builder,
as a developer, even without adev job.
Holding yourself to thatstandard with that main capstone
project that you're eventuallygoing to build, that makes you
stand out to employers.
You know, like that's wherepeople stand out.
(08:52):
It's.
You might've heard of somecoding bootcamps that
hyper-focus on like a onesingular capstone project that
they spend months on and theythey polish it up.
It looks like a professionalproduct because they're capable
of it, just like you're capableof it.
And they also will take time tocreate good documentation on
(09:15):
how to boot this app up.
Right, if another dev wanted tospin it up let's say, another
dev on the team wanted to spinit up they should have clear
instructions on how to do so.
And if you are heavily focusedon backend positions.
There's just niche, nichethings that you can do, like
having whether it's like a selfdocumented situation or you got
(09:37):
to build, like manually build adocumentation for your API, like
having documentation for yourAPI for backend developers is
really powerful.
I don't think you have to go tothat extent if you are applying
for frontend positions.
In fact, you should question ifyou should dive into the
backend at all.
But documentation is somethingthat will also make your product
(09:58):
, your professional lookingproject, feel more professional,
and that's what it's about.
It's making it feel moreprofessional to employers.
And so I got to stress thisagain.
Like a big thing is and I hatethis question it's when people
ask others what they shouldbuild.
(10:19):
You got into coding for areason.
Don't tell me you don't want tobuild cool shit.
What the hell do you want tobuild?
If you look at other apps likewhat would even sound cool to
work on and build, you can getideas from other people for
inspiration, but you should notbe asking people to tell you
(10:42):
what you need to build.
You need to find that withinyourself.
What kind of problems do youneed to build?
You need to find that withinyourself.
What kind of problems do youwant to solve as a developer?
And this a lot of people areuncomfortable with this because
they haven't trained their mindto think about this.
You can brainstorm.
There are YouTube videos thatwill help you form a
brainstorming process if youfeel like you need a system in
place to do that.
But a lot of times it's justlike you know, if I could build
(11:12):
something for myself, what wouldit be?
Let's start with that.
Start with something right.
But I don't think you shouldjust be building a random thing
because someone else told you tobuild it.
A lot of times it's just goingto end up as a graveyard project
.
That's how a lot of graveyardprojects become graveyard
projects is because you didn'treally have enough interest in
the first place.
Right to follow through withthat.
And so focus on, like, what youcan build.
(11:33):
Start with yourself, but whatyou can build for your friends,
your family, your gamingcommunity, your local community,
your previous industry.
And if you struggle withbrainstorming, like, use chat,
gbt or another AI model to helpyou brainstorm some ideas, but
give it as much context aspossible about, like, what
(11:55):
you've been learning, what youwant to be challenged with, what
sounds interesting, maybe a funproject you've built in the
past got to be related to that.
What did you like about it?
Right Was right.
Was it gamified?
Include that in the context youprovide to ai.
Right.
So that's how you can reallyutilize ai to basically be like
a second brain that just makesyours better and it helps propel
(12:17):
you in the right direction bygiving a lot of great context
that is very unique to you.
But eventually, with thatcapstone project, I want you to
start thinking about it like areal professional product,
because I've seen this type ofpersonal project make so many
(12:39):
aspiring developers stand outand the final thing would be
like a failure to demonstrate,kind of like an improvement with
efficiency or addressing userneeds.
Right, so you've builtsomething that can help people.
What have you done to put itout there in front of people?
(13:01):
What have you done to gain auser base?
Even having five people usingyour app actively is way better
than so many of these otherpersonal projects that serve no
purpose.
You'd be surprised how easy itis to stand out among many other
aspiring developers when youbuild something that's useful
(13:25):
and people are using it.
You can list those userstatistics.
You can list revenue thatyou're getting.
It doesn't have to be revenue,it could just be usage.
Maybe build a mobile app andyou list the downloads in the
app store, right, but if peopleare using it, you're giving this
.
Well, you're getting the socialproof that then you're showing
(13:45):
employers that, hey, I can buildshit that provides real value
to people and if it providesreal value to people, you can
gain revenue off of it.
You can monetize that.
You might not be good atmonetizing that, but it has the
potential to.
And now you're just signalingto employers that, hey, maybe
this developer that we're hiringcan build.
(14:07):
You know that they know enoughto be able to build something of
real value for users and theycould build real value for us
and our users and gain usrevenue.
Right, you don't have to be anentire marketing department to
know how to do this.
But taking that initiative totry to get your app in front of
(14:27):
other people um, you know,whether maybe it's product hunt
or another website like thatposting it on twitter, linkedin,
saying and posting it andasking mods first, but posting
it in subreddits of differentcommunities of where this app
would actually be useful, um,you got to take that initiative.
But if you can gain or if youcan mark down certain statistics
(14:48):
like usage for your app, thatI'm telling you that personal
project gets bumped way higherand it's way more competitive in
employers' eyes than all theseother random personal projects
that serve no purpose.
So you can also well.
Yeah, I think I'm going toleave it with that.
(15:10):
I think the big message that I'mtrying to deliver right now is
it's okay to start with avariety of projects.
It's okay to build a bunch ofcrappy stuff, but eventually I
want you to start focusing moreon the model of building that
capstone project, that finalproject that is useful, that
(15:35):
provides real value to people,gains a user base where it looks
professional, feelsprofessional on the source
control side you have a properreadme it feels professional on
that end as well.
You care about the code quality, because now you're scaling the
app, because you're asking foruser feedback.
So you're going through theagile process of wanting to
(15:55):
iterate on your app and you getuser feedback and you adopt a
scrum process.
You write tickets of featuresand bugs you've got to fix and
then you just launch you knownew fixes very quickly and push
it out and get more feedback,and this is a cycle.
So now you've involved yourselfin a professional process the
agile and the scrum processright, professional process, the
(16:16):
agile and the scrub processright, you're not going to do
this the right way the firsttime.
Right, and maybe what I'vedescribed to you sounds a bit
advanced and overwhelming andyou got to try it.
And it starts with justbuilding that one tool for
(16:38):
yourself and expanding fromthere.
If you're intimidated byeverything else, what like today
, if I could start a new projectand finish it in a month and
produce an mvp, and then I'llthink about, like, pushing it
out to other people, then if youcould build one project today
for one month and you have tolaunch it at the end of that
(16:59):
month.
Popular Podcasts
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.
Dateline NBC
Current and classic episodes, featuring compelling true-crime mysteries, powerful documentaries and in-depth investigations. Follow now to get the latest episodes of Dateline NBC completely free, or subscribe to Dateline Premium for ad-free listening and exclusive bonus content: DatelinePremium.com
On Purpose with Jay Shetty
I’m Jay Shetty host of On Purpose the worlds #1 Mental Health podcast and I’m so grateful you found us. I started this podcast 5 years ago to invite you into conversations and workshops that are designed to help make you happier, healthier and more healed. I believe that when you (yes you) feel seen, heard and understood you’re able to deal with relationship struggles, work challenges and life’s ups and downs with more ease and grace. I interview experts, celebrities, thought leaders and athletes so that we can grow our mindset, build better habits and uncover a side of them we’ve never seen before. New episodes every Monday and Friday. Your support means the world to me and I don’t take it for granted — click the follow button and leave a review to help us spread the love with On Purpose. I can’t wait for you to listen to your first or 500th episode!