Tips and advice for learning JavaScript and applying for tech roles

I have the privilege of mentoring and coaching JavaScript learners from all over the world. Most students are career-transitioning, recent bootcamp graduates, or front end developers trying to level-up.

Ultimately, everyone wants more or less the same thing: to gain a strong command of JavaScript so they can find their first job in tech.

The point at which you are “ready” is often imagined as this huge moment 🏆. You wake up, feeling at least 80–90% confident in your abilities, knowing you finally meet most of the criteria in the job descriptions and you can begin applying. It’s a momentous day.

I am yet to experience this. I don’t know any developer who has.

Having also career-transitioned many years back and now working as a senior developer, here is my take on how and when to get started applying for JavaScript roles.

Set your target on failing your first interview

Forget about “the momentous” day when you are finally ready. There is no such thing.

In other words, the point at which you start applying for jobs should NOT be the point at which you are ready to actually secure the job.

If your first interviews are in the hope of securing them, not only have you probably waisted a lot of time to get to this point, but now you have huge pressure on your shoulders. It’s challenging enough to remember everything you’ve learned in a stressful interview environment. Adding to that the desire and expectation of actually getting the job can be overwhelming.

Instead, set your target on failing your first interview.

Yes, you read that correctly. Apply to jobs knowing you will fail. Think of it as research. These interviews are opportunities to practice, understand what these jobs generally expect, and improve your JavaScript skills along the way.

It’s a much easier mindset to have, and far more effective in the long run.

After experiencing enough of these interviews, you’ll notice your confidence slowly starting to grow. You’ll no longer be failing in the first stage; perhaps you’ll make it to the second or third.

Now you can set the next target: apply to jobs with the intention of getting them.

Two targets, and two different mentalities entering the interview.

Reduce your portfolio expectations by 50%

Everyone has this perfect vision of what their portfolio should look like. They say things like, “Before I start applying for jobs, I am going to create a jaw-dropping portfolio.”

There are three typical outcomes of this mentality:

1. You succeed, and you gain the satisfaction of sending recruiters something you are truly proud of.
2. The pressure to create something amazing means you put it off for 6 to 18 months, and you don’t apply for any jobs during this time.
3. You attempt to create it, struggle, give up, and lose confidence. Another 6 to 18 months go by.

The last two outcomes are far, far more common than the first.

You do NOT need the perfect portfolio to get your first job. Instead, start with a GitHub landing/README page or a simple one-page website with links to GitHub. All you need to begin with is a short, succinct summary of your skills and some evidence to back it up.

Instead of working on a jaw-dropping portfolio, shift your attention to “boring projects” and “fluency” — the drill work that will boost your JavaScript competency. I elaborate on this further down.

Later, while still applying for jobs but now with a bit more interview experience, you can start working on an improved portfolio (notice I still don’t say “perfect”).

Focus on fluency

Whether you are a beginner or intermediate learner, your primary goal should be to improve your fluency in JavaScript. By that, I mean writing tons of code. Forget about getting the “correct answers” in code challenges or building something that actually works. This is irrelevant. What counts is the time you are dedicating to writing lines and lines of JavaScript.

If it’s messy, it does not matter.

If it doesn’t make sense, it does not matter.

If it makes you feel confused and frustrated, it does not matter.

Write some code. And the next day, write some more.

Here are some things you can do:

• Tackle one or two daily LeetCode exercises (basic/beginner level — nothing fancy)
• Exercises in a course you’re following (do ALL of them)
• A “frankenstein side-project” (as one student described it), devoting 30 minutes a day to it.

Consistency is key. I know while writing JavaScript you may feel frustrated that you’e not getting it. That’s normal. But just like your first goal of interviewing is not to get the job, your goal here is not to understand everything or even write good code.

The code itself is the goal.

Talk out loud

Most learners I speak to are self-taught. This usually means it’s just you and a laptop, sitting in an empty room. The problem here is that you are only practicing only one side of being a developer: the coding part.

However, there is another fundamental skill that developers need: communication. Writing code quietly in a room is not going to help you with this. It is surprisingly difficult to put code into words (let alone abstracted mnemonic images like the visual JavaScript learning aids I provide in The Great Sync).

Here are a few things you can do:

• When working on a LeetCode or Edabit exercise, say out loud what you are about to do before you write the code. For example: “Okay, my plan is to declare a variable that will store my result, and then I am going to use a for loop to access each item using its index. I will then use the .push method on arrays to add the item to the result.” This practice is pure gold.
• Use flashcards for explaining general web development and JavaScript topics. Don’t just “think” the answer; express it in words! For example, you can ask yourself questions like, “Explain what hoisting is” or “What is the difference between const and let declarations?”
• Start a blog. Even if only your granny knows about it, it doesn’t matter. Writing blogs is a precursor to writing technical documentation, something you will do frequently as a developer. It also greatly helps with the consolidation of knowledge.

Work on boring projects

Learning JavaScript is incredibly exciting because it allows you to bring your creative ideas to life. However, the temptation is to dive straight in immediately, even before you are ready.

For example, one student mentioned that he wanted to build a virtual coffee barista, which is an awesome idea and would look impressive in a portfolio. But in my opinion, it should be the very last thing you spend time on.

Why work on a never-done-before idea when you are still struggling with basic loops?

Why start your “business idea” when the DOM methods still confuse you?

Trust me when I say that once you have a solid JavaScript mental model, you can build whatever your heart desires.

But your goal for now is to create that mental model, and you don’t need virtual coffee baristas or Netflix clones. You certainly don’t need to be wasting valuable time and energy trying to be creative! You’re not practicing to be creative, you’re practicing to be a developer!

Instead, the tried-and-tested “boring” projects are ideally suited. There is a wealth of online resources to help you complete each of them, and the patterns you learn while building these will be the same patterns you use to create more complex apps.

Here are some project ideas:

• Tic Tac Toe
• Calculator app
• Hangman app
• Weather app
• A customizable form

Cultivate a habit of reflection

Finally, we come to the number one thing you can do throughout the interview and learning process: reflect on the code you have written.

I cannot overemphasize how powerful this practice is; it will transform your experience of learning JavaScript. In fact, this is how The Great Sync began— a visual JavaScript learning resource for using imagined environments. I review my knowledge repeatedly and incorporate it into a mental model that I constantly update, improve and build-upon.

Most people, after finishing an exercise, project, or course chapter, simply move on to the next item on their list. Maybe they take some notes or save code snippets somewhere. However, very few actually go back and review what they learned or did in the days or weeks prior.

Instead of rushing through every exercise, slow down and schedule “review” time. This means carefully and thoughtfully revisiting your past work, all the while asking questions such as:

• Why did I write this line of code?
• Could I have done it differently?
• What can be improved?
• Do I understand every line of this code?
• What are the main takeaways from this exercise?

Usually, this line of thinking will lead to “redoing” the same exercise, or at least refactoring it to make improvements. It may slow you down, be frustrating at times, and make you feel like you’re going in circles. However, this is where the real learning happens. If you skip this step, you are neglecting a habit that will take you far beyond the skills of an average developer.

I firmly believe in this habit, and all of the material on The Great Sync is designed to help with easier recall of knowledge and drawings links and comparisons with what you already know.

Whatever method you use, make sure you repeatedly reflect on your work.

In conclusion

I hope these summary tips and advice for learning JavaScript from my 1:1 sessions is helpful and actionable. Please don’t hesitate to get in touch directly via email or instagram.