So, You Want to Get a Job as a React Developer (Here Are 4 Not-So-Obvious Ways to Land It)

So, you want to get a job as a React developer. Great!

Now, you've likely done (or are doing) the following things to land it:

1) Learn JavaScript fundamentals
2) Learn React fundamentals
3) Become comfortable with layouts and styling using CSS/SCSS
4) Learn how to interact with APIs
5) Make an application that shows off your work

This is great work! I do think it meets the threshold of what is required for a React job.

However, I'd like to empower you with some not-so-obvious ways that you can stand out from a crowd of applicants and make a transition into a React job seamless.

This ways are not-so-obvious because they are the things that you end up doing day-to-day in a typical role that isn't talked about as much in the blogosphere.

1) Master Copying Designs From Existing Applications

Using an existing UI component library like Material UI for a project is totally fine.

In fact, that's the route I went to be able to make an application where I got practicing interacting with APIs.

However, the real-world workflow is much different.

On a product team, there will be a UX designer who will create "mockups" of a new experience that will have to be coded.

Meaning, you have to look at something and copy it.

Well, you don't need a UX designer to start practicing that skill.

Here's a fun idea: Try to replicate the look and feel of products that come out on Product Hunt. If you want to go a step further, you can try to replicate entire experiences (their workflow for loading a screen with data from an API).

The more comfortable you get with "monkey see, monkey do," the more comfortable you will be in interviews, and ultimately, when transitioning into a new role.

If you follow this step, even on a smaller scale (like creating components from a UI library from scratch), you will aggregate plenty of material for a portfolio.

2) Write As You Learn

I mentioned in a previous article, how this is a major key to bursting out the "tutorial phase."

I emphasized that forcing yourself to write as you are learning has several advantages:

1) It forces you to learn what you are trying to learn (if you don't get it, you can't write about it; if you can write about it, you must learn it).

2) It provides incentive to your learning, you get to see people like, comment, and share your posts. If you see that you are helping others, it will boost your confidence, love for the subject, and incentivize writing more.

3) It makes you explain technical concepts in a way that those less technically experienced can understand. It turns out, this is vital not only for if you become a senior dev, but when you work closely with a product team (which is a big part of the role that is often under asserted).

4) You will have more than just a resume to verify that you know what you're talking about. Even senior developers can stumble in interviews due to nervousness. If you have articles showcasing your understanding of technical concepts, you will be able to reset assured that the articles speak for themselves ("the proof rests in the pudding").

5) You can most definitely include these articles to sharpen your portfolio.

3) Mimic a Real-World Workflow

A major part of a real-world workflow of a React developer is being able to "break down" mockups into prioritized, estimated chunks.

At least once, fight the urge to treat your side projects like a "hackathon." Fight the urge to just pump out a bunch of code as you build something.

Instead, try to write down how the entire project can be broken down into chunks.

A chunk is an implementation of a feature/functionality required to complete the project.

Chunks should be recorded in the logical order that they will have to be done.

Lastly, chunks should be the equivalent of 1-2 days worth of coding (assuming a full-time schedule; 5 hours of undistracted work constitutes a day).

Use GitHub projects to record your progress for these chunks.

Now, if you really want to impress, do this:

Let every chunk be implemented through a single Pull Request. Reach out to a developer friend and have them review your changes. Respond to feedback and move on to the next chunk when all feedback has been addressed.

This sounds like a lot of work to do in spare time. It is.

However, even if you just did this process for a single chunk, and talked about it in an interview, or showcased it in your portfolio. I can guarantee you will stand out.

4) Don't Try to Over-impress Developers

When you get to an interview, don't try to over-impress developers that interview you.

Let's face it. Even if you had the same amount of knowledge and experience as the interviewer, you are bound to be at a disadvantage when it comes to impressing them. Nerves and on-the-spot questions are tough.

Now, if you are new to the whole field of being a developer, or even just as a React developer, you'll have to admit that it's very unlikely that you can outdo the developer interviewing in technical knowledge.

So, what are you supposed to do?

1) Remember that getting a React job (and doing well in it) is mostly about impressing the product team (the non-technical people) not the developers (the technical people).

With time, you're bound to learn technical skills that will eventually impress your developers. And that's important.

However, if you can showcase value as a team member that can get work done (in a real-world workflow), then you will be valuable (and therefore hire-able) to the product team.

2) Still try to impress the developers, just not in being technically superior. Don't try to impress with talking technical trivia.

Instead, you just need to show that you are competent in the skills required for the role. Beyond that, impress with your portfolio (i.e. how you've gone through a real-world workflow as you built a project).

If you can talk about an interesting project, demonstrate that you would be easy to teach and work with, and highlight the things you have done to stand above other candidates, then you will impress in the way that counts.