I was in a very similar situation myself when taking the self-taught path to this career.
It took me almost 5 years of learning (I wasn’t constantly disciplined with it the whole 5 years) before I got my first job, but I had felt job-ready for a long time.
5 years later, I moved up quickly, have been at 4 different companies, and the last 3 years has been at a consultancy where I work on a massive variety of projects and clients at varying scales. I also filter resumes and conduct interviews now, and so I find myself thinking a lot about what I would say to that past version of myself who felt job ready but just couldn’t get interviews.
I would say this.
Build an app that you already know the rules of. It’s ok if it exists already, you’re not starting a company you’re building a portfolio.
Don’t design it from scratch dumb dumb, you’re not a designer. Go look at existing apps and use them as a starting point, or even just use a component library.
Regardless of what that app is you should have these features:
- User login/management
- password resets
- user settings
- roles and permissions
- Email notifications at a minimum
- (optional) push notifications
- (optional) sms notifications
- Every app has at least one thing where the UX can be improved at least slightly by real-time updates
- Handle payments
- Can be configured to not allow real payments, but you should be using an actual payment processing platform like Stripe or PayPal
- CRUD on at least one resource
- A user should be able to create, read, update and delete at least one thing. This could be a blog post, a comment in a forum, a task in a todo app – doesn’t matter. Just CRUD on anything that’s not a user so that you can demonstrate your roles and permissions working
Not everything has to be tackled all at once. Be iterative about it.
There is also all the non-feature stuff. Some of these details can be considered “Dev/Ops” depending on who you ask, but a lot of it is just tooling, processes, and developer experience (DX).
You should have the following:
- Clean git history (no “did stuff” commit messages)
- Consistent format to your messages
- Any branching strategy but choose one that’s recognized by the industry
- Bonus points if you can automate your git standards
- At a minimum you should be using lang files for all static messaging even if you only support 1 language
- Bonus points for supporting multiple languages
- locale should be configurable in user settings, fallback to browser settings
- Linting/Formatting should be automated
- Use ES-Lint for linting, and Prettier for formatting
- Linting should run in your CI
- Have a CI (continuous integration) step in your PR process
- With GitHub Actions and other similar offerings setting up CI has gotten so much easier. The only excuse to not set it up is you haven’t learned it yet. If you’re job-ready, you should be able to figure this out in a day or less.
- This should at a minimum being running a linter
- If you have tests, this is where you run them
- Have CD (continuous delivery)
- Deployments should be done automatically either by clicking a button or merging a branch into a long living branch like main/master or develop
- Even if you’re an entry-level developer there are lots of options out there to get tests into your app that don’t require you being a seasoned veteran. Don’t worry too much about what’s “best” and focus on coverage and easy setup. Cypress is definitely most people’s friend here.
- Database migrations
- Only applies if you have a backend
This might not be 100% complete, but if an entry-level applicant sent me a resume and had a project that ticked 90% of what’s in that list, they’d be one of the best applicants I’ve seen. I’d have to bring them in for an interview regardless of their lacking work history.
Where you focus your efforts is going to largely depend on what your goals are. If you want to be a frontend developer you want to try and avoid building the backend yourself. Use 3rd party services as much as you can. Your “backend” can just be proxying calls to these 3rd party services (to hide your API keys) or even explore serverless options (which would be huge bonus points). Put all your effort in making the frontend super awesome (not just visually, but keep performance and architecture in mind as well)
Or if you think you want to be fullstack or backend, then build the API with only as much focus on the frontend as you need, or build a MPA in an MVC framework like Adonis, Rails, Django or Laravel.
Point is, whatever you build, you want to demonstrate that you know how to do the 90% of what’s common between almost every application out there. The team you’ll be working with can teach you how to do it better, as well as how to handle the last 10% that’s different.