LinkedIn is sort of a love-it-or-hate-it kind of platform.

Some people love it for the opportunities it provides and the ease with which it facilitates professional connections.

Other people hate it because it often seems like it has a veneer of genuine connection while the substance is mostly self-serving networking.

In reality, both of these extremes have a degree of truth to them.

LinkedIn is not a magical solution where you can create an account and instantly be discovered by hundreds of companies eager to throw money at you.

But it is also not the cesspool of recruiters and fake networkers sending out spammy connection requests all day.

Despite what you might think about the platform, the reality is that, when used correctly, LinkedIn provides an excellent opportunity for you to stand out, get noticed, and get hired, even if you don't have professional experience.

The key lies in the when used correctly part of that sentence.

So today we're going to go through some strategies that you can can use to leverage LinkedIn to get you that crucial first job.

We'll cover both profile setup and connection/networking strategies. These will help you increase your visibility to recruiters and employers searching for developers, and start to form relationships with people in the industry who can bring you valuable opportunities.

I love examples, so I'm going to walk you through this using an example as if I was a new React developer trying to get my first job.

You can follow along using your specific situation and goals.

How to Set Up your LinkedIn Profile

The main goal with setting up your profile in LinkedIn is to make it easier for the right people to find you, mainly recruiters and employers.

Recruiters are not the only people scouring LinkedIn for good candidates. Small agencies and other small companies that may not have the resources for a recruiter also use LinkedIn in order to find good talent.

We want to be visible to both groups of people here, so when they are searching for someone matching your skillset they find you.

Let's go through each component of a strong LinkedIn profile.

Use the Right Keywords

It all starts with the keywords. Your keywords are how you are going to structure the content of your profile. We'll include these keywords in relevant parts of your profile where it makes sense. But we'll make sure to maintain readability so you don't sound like a robot and still appeal to the humans actually looking at your profile.

Some keywords I might want to include might be React, GraphQL, and Node if I'm going for a full-stack JS developer position.

I like to go more specific and put the specific technologies I am learning and want to work with, rather than going too broad, like JavaScript.

At the same time, there's a balance here. You can also go too narrow and put things that not a lot of people are going to be searching for.

An example of something too narrow might be Next, Firebase, and Tailwind. Those are very specific technologies and the likelihood of someone searching specifically for those is less than React.

But, somebody who knows React and can demonstrate some basic proficiency in a few different stacks based in React will be appealing to someone even if the specific stack they are using differs from your specific stack.

The main thing we want to communicate here is that you have knowledge using certain technologies you want to work in while communicating the fact that you are capable of learning others.

For this example I'm going to go with React, GraphQL, and Node as my keywords.

Compose Your Intro

The intro portion of your profile is comprised of your photo, headline, banner image, name, location, and your URL.

It forms the first impression people will get of you and your profile, so it's important to get it right. Let's go through each component of the intro section one at a time.

First, the big three.

These first three components are what will show up anytime you interact with anyone on LinkedIn or show up in someone's feed.

They are the only parts that people will see even if they don't click through to your profile, so make them count.

Your Name

Pretty self-explanatory. Use your real first and last name. Nicknames are fine, as long as that is what you would go by if you were to get hired somewhere.

Keep it consistent across all your profiles and your website if possible, as this strengthens the branding aspect of your online presence.

Example: My name is Kenneth Rogers but my LinkedIn says Ken Rogers because that is usually what I go by, and that's what I go by on all my social media profiles.

Profile Photo

Your profile photo is an important part of your profile.

There's some disagreement about whether or not you should have a photo of yourself in your social media profiles.

Some people think it can cause unnecessary unconscious bias in people who look at your profile.

While this may be true, let's look at the alternative.

Whether we like it or not, having an empty spot where you profile photo gives the look of incompleteness.

So the unconscious bias is unavoidable. It's part of the process, whether we like it or not.

I think having a high-quality photo is a much better decision that leaving it empty or using something that is not actually you.

For the photo, the basics apply.

Clear, high-quality headshot, preferably smiling, with a neutral background that is not distracting.

If you are able to do so, hire a professional, but I realize not everyone can do that.

Luckily smartphones have amazing capabilities these days. By asking a friend who knows what they are doing or by learning a bit about phone photography yourself, you can take a great picture that gives a good first impression.

Make it so that if someone met you in person after looking at your profile, they would easily recognize you. No pets or family, just a clear headshot of you.

Headline

The headline is one of the most important pieces of your LinkedIn profile.

Even though it's short, it has a high impact on your search visibility and on whether or not somebody will click through to learn more about you.

So what makes a good headline? It needs to appeal to both human readers and the LinkedIn search engine at the same time.

That means it needs to be clear and concise in communicating exactly what it is you do (or want to do).

One thing I do not recommend doing is putting words like "Junior", "Aspiring", or "Student", in your profile.

If you currently create things using code, you are currently a developer, you just may not have an official job title.

Get rid of any language that says you are not currently a developer. It's not about lying, we're not going to fake any experience you don't actually have.

It's about having confidence in your abilities and yourself to call yourself what you are, a developer: someone who creates things with code.

Your headline should include your specialty (what you want to work in) and your unique value proposition (what you specifically bring to the table).

The first part is pretty self-explanatory, but how can you have a unique value proposition as a brand new developer?

This can be as simple as what you want your specialty to be or unique things you have accomplished with past projects.

Do you have an interest in accessibility and did you build a project that incorporates accessibility? That's a recipe for a compelling headline that helps you stand out.

Something like, "React developer building highly-accessible web applications."

We've got one of our keywords in there, potentially two if you identified accessibility as a keyword, and it clearly communicates the value you bring to the table for companies.

For my profile, I'll go with "Building excellent user experiences in React and GraphQL".

I want to be a React developer and I have a passion for crafting excellent user experiences.

For you, this might be clean code, well-tested code, and so on.

Choose something that you uniquely focus on that adds value to organizations.

This doesn't have to be technical, either. If you come from a background that utilized other soft skills that are relevant to development, integrate that in there.

Let's say you used to work in customer service, so communication is one of your strong skills.

You might make your headline "Building React applications that effectively solve client problems" because your communication skills allow you to ensure that you are clear on the client needs and the tools you build accomplish that task well.

Something to decide here is which part of your headline you want at the beginning. Only the first 65 to 80 characters will be shown in search results and content feeds depending on if you are on mobile or desktop.

So you need to decide which aspect of your work is more important and put that first.

Banner Image

Customizing your banner image is another one of those little details that communicates that you took the time to customize your profile and really care about how it looks.

There are two options for your banner image.

If you can find a stock photo or a photo you took that communicates something about you, you can use that.

For example, I live in Colorado and love the mountains, so I might choose a mountain photo.

It does not necessarily have to communicate something professional about you, but it shouldn't be generic.

For example, don't use a picture of a computer with code on it, since that doesn't do anything to differentiate you from other new developers.

The other option is to create your own banner image that communicates your career goals.

Lots of consultants do this, and I have something similar on mine.

You can do this using Canva or hire someone on Fiverr.

Some things you could put on the banner:

• Icons of the tech you work with
• Another picture of you with an overlay and some text describing what you can bring to the table

Here are a few examples of this:

Here Justin highlights his primary professional driver and lists his website.

This is a great example if you have a specific mission that drives you to code.

As you can see, the banner image doesn't have to be fancy or complicated, simpler is usually better.

Here's what mine looks like:

Personally, I would go with this second style of banner, where you have some text describing what you do, over the first. It gives more clarity on you as a person.

Although if you are having trouble coming up with something like this, a beautiful picture that still communicates something about you is better than the default.

URL

Customizing your URL is one of those little details that takes 10 seconds but adds that little bit of polish to your profile.

Change your URL to some form of your first and last name. You can also add in initials and other forms of your name if necessary.

For example, I usually go by Ken Rogers or Kenny Rogers, but those were both taken so my URL is https://linkedin.com/in/kennetharogers, which uses both my full first name and my middle initial.

Summary

Opinions vary on the best length for a summary, but I am personally inclined to recommend shorter summaries.

One thing I've noticed is that people feel like they need to include their entire life story in their summary or in places like their portfolio site about page.

Think about your online profiles like online writing.

In writing, the only goal of the headline or introduction is to get the reader to read the next line.

Your goal with your LinkedIn headline and summary is not to get hired, it's to get the person viewing your profile interested enough to just take the next step. That might be sending you a DM on LinkedIn, sending you an email, or visiting your portfolio site.

This job hunt process should be viewed in this step-by-step manner. It helps keep you focused on what each component is best used for and avoids overwhelming people with too much information too soon.

So how can we apply that to your summary?

You want to hook the reader in on the first two lines of the summary, since LinkedIn requires you to hit the "Show More" button in order to view beyond that.

To make this a bit easier to write, I like to use the following structure:

• Hook
• Mission
• Expertise
• Proof
• CTA

In the hook, you want to use something unique and interesting about you and open up a loop that can only be closed by reading further. This is how you'll get the reader to read your entire summary.

I like to integrate something from my background and why I got into coding here. You can also hint at something that happened to you during that process that gets explained later in the summary.

So if I was doing this for my example, I might write something like this:

"It was many late nights spent coding after driving a forklift all day before I built my first web app. But when I did, I learned something unexpected about myself."

This captures the reader's attention by showing that I am motivated to learn and dedicated to doing so, briefly mentions I've built something from start to finish, and hints that I learned something, which we'll continue explaining in the mission section.

"I learned why I truly love to code. That particular app was built to solve a small problem I had in my life, consistent journaling, and by completing it I realized the immense satisfaction I get from building something real, that makes someone's life easier, using nothing but code and my own effort."

Now we're starting to get into why I actually code. This is more important than people realize. Hiring, as much as some companies try to make it, is not an automated, robotic process.

It's people who will be looking at your profile, reaching out to you, and hiring you. You need to connect on a personal level in order to catch someone's attention.

Now let's dive into our expertise by moving into talking about how we actually accomplish the "what" and "why" listed above.

This is another spot you'll want to use those keywords you chose earlier. In this example, I chose React, GraphQL, and Node. With that in mind, here's how I might write this section of my summary.

"I'm obsessed with solving complex problems using React, GraphQL, and Node by building web applications with an emphasis and accessibility and usability."

Anyone can say these things, you also need to back it up with proof. That means you need to have a built a complete project or two using the exact tools and concepts you discuss in this section.

We'll go into that in just a second, first let's round out this section with a clear CTA so readers know what we are looking for.

"I'm currently looking to contribute my skills to a team where I can prove my skills while growing in my capabilities. If you are looking for a competent, highly-motivated developer, let's chat. You can reach me at email@example.com or by DMing me here on LinkedIn."

This gives people a clear action to take and shows them exactly what you are looking for.

Now, on to that proof we were talking about.

Rather than just listing it out here, I like to include links that link to a project or two, and maybe a piece of writing that showcases the attributes you've written about here.

You can utilize the "Featured" section for that.

Featured

The featured section is simple but very powerful.

What I recommend doing here is linking to a project or two that lines up with the skills and attributes you listed in your summary, and maybe a piece of writing or two that does the same.

For the projects, don't just link to a live version of the project or a GitHub page. You should have a dedicated page on your portfolio site that walks readers through how and why you built the project.

Building a portfolio site is outside the scope of this guide, but I highly recommend reading Josh Comeau's book on building great portfolio sites.

Experience

What can you put in the experience section when you don't have any experience?

There is almost always relevant experience that can be used even if your other jobs were in another field.

Learning how to communicate they ways in which your soft skills learned in other fields are relevant to web development is going to be critical here.

What I recommend doing is looking at this list of skills that virtually every employer values. Then see which of those you had to utilize in your previous jobs and how that translates to being a good developer.

Be sure to list any specific accomplishments and awards you received as well as concrete examples of demonstrating those skills.

For example, I used to be a server and drove a forklift before I became a developer.

A couple of skills from that list that I had to use quite often were communication and adaptability.

So let's see how I could integrate that into my experience.

I might write something like this in my server experience section:

"Simultaneously served multiple tables while ensuring their orders were correct and guests were satisfied. Adapted to changing demands by performing multiple duties such as hosting and bussing as restaurant traffic increased and decreased throughout multiple shifts."

This is a simple example, but it communicates that I am able to handle multiple responsibilities while maintaining good communication and customer service, and that I am adaptable and willing to help out the team even if it means doing a job that is not necessarily my primary function.

One mistake I see a lot of people make is just stating that they have certain skills instead of showing it with examples. This is one way to do that.

If you have done any freelance work, you can also put that here as relevant work experience if you did it under a company name, or even your own name.

Make sure to focus on results delivered to clients or employers. If you can, list specific things you accomplished and how that contributed value to the organization or person you worked for.

Education

If you have formal education or a bootcamp under your belt, you can put that here.

Besides that, put any course work you've completed here. Things like Udemy courses or freeCodeCamp curriculum certificates should be included here as well. Any structured training program or course you've taken should be included in the Education section.

Skills

For your skills, I recommend choosing the top three based on the keywords you've chosen. These top three are the most crucial and will be used to filter your profile.

As for the rest, my preferred rule of thumb is to include any skills you have used to build a complete project.

Don't list every piece of tech you've ever touched here, as that is a subtle hint to employers and recruiters that you are desperate to get whatever job you can. And it's virtually impossible for someone to be proficient in that many things.

Recommendations

If you can get them, recommendations are great. Try to get recommendations from people you have worked for in the past.

These aren't required as getting them depends on external factors, but get one or two if you are able to.

How to Amplify Your Reach on LinkedIn

You've got your profile nailed down, now it's time to get it in front of people.

The other half of LinkedIn is using it properly in order to meet the right kind of people and get on their radar as someone who will be a valuable addition to their organization.

You have the foundation in place in your properly created profile, now you need to get it in front of as many eyes as possible.

You've optimized your profile to take advantage of LinkedIn's search functionality, but you don't only want to be passive in this process.

You also want to be active in getting in front of the right eyes.

This isn't going to be some awkward process. We'll mostly just be connecting with people and posting content.

You won't have to send any DMs or try to sell yourself on LinkedIn.

This is a two-part process:

1. Connecting with people
2. Writing compelling content

How to Connect with People on LinkedIn

Let's talk about connecting with people first.

You want to be intentional about the people you are connecting with. The best way to do that is to connect vertically.

Most people focus a good chunk of their networking on horizontal connections. This means that they connect with people at the same level as they are.

There's nothing wrong with this, and I'm not saying you shouldn't do that. But your effort is better spent on people who are either in a position you want to be in, or are in a position that hires people like you.

So a good place to start is to start looking up companies you admire and would want to work for, and start connecting with employees at that company, people that currently do what you want to do, and people in charge of hiring at that company.

As you do this, LinkedIn will start to suggest relevant people to connect with, making this process a lot easier and faster.

I have conflicting feelings on connection request messages. On one hand, I understand the value of customized messages, but on the other, I actually tend to see better acceptance rates with the default message. So I don't write custom messages anymore.

This is something you'll want to experiment with for yourself.

Try both and see what works better for you. For your custom messages, keep it simple and say you are a new developer looking to connect with other people in the industry.

That's it. You don't need to send a personal DM or try to form a friendship with them now. You're just trying to grow your network and increase your visibility. The long-term connection is going to come in the form of creating valuable, interesting content.

How to Write Good Content and Share it on LinkedIn

So how do you write engaging content on LinkedIn that makes people want to learn more about you?

My favorite method is to be working on a project, and write about what I'm learning during your process But – and this is an important distinction – write about it from the perspective of a teacher/authority.

What I mean by this is that instead of writing "I learned this today" write "Here's how to do this."

And LinkedIn is better for high-level, conceptual types of content rather than overly technical types.

So write about the high-level lessons you are learning, rather than the technical things themselves.

So let's say I was working on a project using Gatsby and after a bit of struggle, I figured out how to turn it into a PWA without following a tutorial, just the docs.

I might write a post along these lines:

"Today I managed to accomplish turning my Gatsby site into a Progressive Web App without following a tutorial.

Tutorials and courses are great, but the real learning occurs when we struggle through implementing a solution on our own, dealing with the inevitable bugs and setbacks along the way.

Whenever you're slogging through a problem and struggling to come up with a solution, know that struggle is your brain adapting to a new situation and learning.

This is where real growth happens."

You want your content to communicate the fact that you are learning every time you build something, and that you are constantly on a journey of discovering the best ways to be a developer, and share those insights with others.

This gives people a great insight into how your mind works and what kind of a developer you will be.

By consistently creating content like this and getting it in front of the intentional connections you've been making, you can start to build a profile for yourself that will help you stand out among other new developers.

Slowly, you'll start to have people reaching out to you who are interested in hiring you. And then when you start to see job openings show up for these companies, you will already be on their radar as someone who is competent.

The key to coming up with great content is to learn to see inspiration everywhere. As you are browsing Twitter, working on projects, reading articles, listening to podcasts, and so on, start writing down content inspiration and ideas you have.

Then, set aside some time every week to write your content for the week and try to post a new piece of content every day.

Wrapping Up

By following these steps you will drastically increase your chances of being found on LinkedIn and building new relationships with people in the industry.

It's not a magic bullet, but it is one piece of a strong job-hunting strategy and an important piece of the puzzle when hunting for that first job, which can be very challenging.

For the rest of the roadmap, Lever.so can help. It's a step-by-step course and mentoring community designed to help new developers land their first jobs, regardless of experience or education.

In my last article, I shared my thoughts on how to prepare for a software developer interview.

In this article, I am going to switch gears a bit and talk about common patterns you can use to solve problems in technical interviews. We'll discuss the frequency counter pattern in depth to help you tackle it effectively.

What is the “Frequency Counter” pattern?

The Frequency Counter pattern uses an object or set to collect values and the frequency of those values.

This pattern is often used with an array or a string, and allows you to avoid nested loops (quadratic time complexity O(n²)).

When should I use the Frequency Counter pattern?

The Frequency Counter pattern is most helpful when you have multiple pieces of data that you want to compare with one another. Let me walk you through an example to see the Frequency Counter in action.

The "sameSquared" exercise

• Write a function called sameSquared which accepts two arrays
• The function should return true if every value in the first array has its corresponding value squared in the second array
• The frequency of the values must be the same

What is the optimal outcome?

After our function is written, we should expect our sameSquared function to return these values.

sameSquared([1, 2, 3], [4, 1, 9]); _// true_

sameSquared([1, 2, 3], [1, 9]); _// false_

sameSquared([1, 2, 1], [4, 4, 1]); _// false_

sameSquared([2, 3, 6, 8, 8], [64, 36, 4, 9, 64]); _// true_

Getting started

First, using the function keyword, we create a function with the identifier sameSquared:

function sameSquared() {

Our function sameSquared needs two parameters, a first array and a second array. In this example, we are passing these values [1, 2, 3] and [4, 1, 9].

function sameSquared(firstArr, secondArr) {

Check edge cases

Inside of our function block, we want to address a few edge cases. First, we need to check that both parameters have truthy values, that is not null, undefined, and so on.

We can check for a falsy value by using the ! operator. If firstArr or secondArr is falsy, we return false.

function sameSquared(firstArr, secondArr) {
  if (!firstArr || !secondArr) return false;

The next edge case we want to account for is to ensure that the length of both arrays are the same. If they are different, we know that they can not contain an equal amount of shared values.

By checking the length property on both parameters, we can determine if they are the same. If they are not, we return false.

function sameSquared(firstArr, secondArr) {
  if (!firstArr || !secondArr) return false;
  if (firstArr.length !== secondArr.length) return false;

Build a "dictionary" to avoid nested loops

We need to keep track of all values in at least one of the arrays. To do this, and to avoid a nested loop, we can store these values in a hash table (object). I’ll call mine lookup.

function sameSquared(firstArr, secondArr) {
  if (!firstArr || !secondArr) return false;
  if (firstArr.length !== secondArr.length) return false;

  const lookup = {};

Using a for of loop, we iterate through the firstArr. Inside of the for of block, we assign the key to the result of value * value.

The value in this key/value pair will be a frequency counter that reflects how many times a specific value is “seen” in the firstArr.

First, we check if lookup contains an entry for value * value, if it does, we add 1 to it. If it does not, we assign the value to 0 and then add 1.

function sameSquared(firstArr, secondArr) {
  if (!firstArr || !secondArr) return false;
  if (firstArr.length !== secondArr.length) return false;

  const lookup = {};

  for (value of firstArr) {
    lookup[value * value] = (lookup[value * value] || 0) + 1;
  }

Once the firstArr is finished looping, the lookup should contain these values:

{
  1: 1,
  4: 1,
  9: 1
}

Compare array values

Now that we have iterated through all of the values in the firstArr and stored them as their respective squared value, we want to compare those values to the values in the secondArr.

We start by creating another for of loop. On the first line inside of our new for of block, we write a conditional statement to check if the current value from our secondArr is not inside of our lookup. If it is not, we stop looping and return false.

If the value from the secondArr is in our lookup, we want to decrement the value of that entry. We can do so by using the -= assignment operator.

function sameSquared(firstArr, secondArr) {
  if (!firstArr || !secondArr) return false;
  if (firstArr.length !== secondArr.length) return false;

  const lookup = {};
  for (value of firstArr) {
    lookup[value * value] = (lookup[value * value] || 0) + 1;
  }
  for (secondValue of secondArr) {
    if (!lookup[secondValue]) return false;
      lookup[secondValue] -= 1;
    }

After we are finished looping through the secondArr, our lookup should have these values:

{
  1: 0,
  4: 0,
  9: 0
}

Wrapping up our "sameSquared" function

If we finish iterating through the secondArr without returning false, that means that our firstArr contains all values that are in a squared state in the secondArr. Therefore, we return true outside of for of loop.

function sameSquared(firstArr, secondArr) {
  if (!firstArr || !secondArr) return false;
  if (firstArr.length !== secondArr.length) return false;

  const lookup = {};
  for (value of firstArr) {
    lookup[value * value] = (lookup[value * value] || 0) + 1;
  }
  for (secondValue of secondArr) {
    if (!lookup[secondValue]) return false;
    lookup[secondValue] -= 1;
  }
  return true;
}

Let me show you another example which is used very commonly in coding assessments (so you might’ve seen this problem before).

The "isAnagram" exercise

• Write a function called isAnagram which accepts two strings
• The function should return true if the two strings parameters are anagrams of each other

What is the optimal outcome?

After our function is written, we should expect our isAnagram function to return these values.

isAnagram(“silent”, “listen”); _// true_

isAnagram(“martin”, “nitram”); _// true_

isAnagram(“cat”, “tag”); _// false_

isAnagram(“rat”, “tar”); _// true_

Getting started

First, using the function keyword, we create a function with the identifier isAnagram:

function isAnagram() {

Our function isAnagram needs two parameters, a first string and a second string. In this example, we are passing these value, silent and listen.

function isAnagram(firstStr, secondStr) {

Check edge cases

On the first few lines of our function block, we want to address a few edge cases, just like in the first example.

Similar to isAnagram, we need to check that both parameters have truthy values, that is not null, undefined, and so on. We can check for a falsy value by using the ! operator. If firstStr or secondStr is falsy, we return false.

function isAnagram(firstStr, secondStr) {
  if (!firstStr || !secondStr) return false;

The next edge case we want to account for is to ensure that the length of both arrays are the same. If they are different, we know that they can not contain an equal number of shared values.

By checking the length property on both parameters, we can determine if they are the same. If they are not, we return false

function isAnagram(firstStr, secondStr) {
  if (!firstStr || !secondStr) return false;
  if (firstStr.length !== secondStr.length) return false;

Build a "dictionary" to avoid nested loops

Remember, we are using the frequency counter pattern and we need to keep track of all values in at least one of the arrays. Now we know that the best way to handle this is to store these values in a hash table (object). To keep things consistent, I’ll call mine lookup again.

function isAnagram(firstStr, secondStr) {
  if (!firstStr || !secondStr) return false;
  if (firstStr.length !== secondStr.length) return false;

  const lookup = {};

Using a for of loop, we iterate through the firstStr. Inside of the for of block, we assign the key to the result of the expression value * value.

The value in this key/value pair will be a frequency counter that reflects how many times a specific value is “seen” in the firstStr.

Using a ternary operator, we check if lookup contains an entry for value * value, if it does, we use the += assignment operator to increment the value by 1. If it does not, we simply assign the value to 1.

function isAnagram(firstStr, secondStr) {
    if (!firstStr || !secondStr) return false;
    if (firstStr.length !== secondStr.length) return false;

    const lookup = {};

    for (first of firstStr) {

        lookup[first] ? (lookup[first] += 1) : (lookup[first] = 1);

  }

Once the firstStr is finished looping, the lookup should contain these values:

{
  s: 1,
  i: 1,
  l: 1,
  e: 1,
  n: 1,
  t: 1
}

Compare array values

Now that we have iterated through all of the values in the firstStr and stored their values, we want to compare those values to the values in the secondStr.

We start by creating another for of loop. On the first line inside of our new for of block, we write a conditional statement to check if the current value from our secondStr is not inside of our lookup. If it is not, we want to stop iteration and return false.

Otherwise, if the value from the secondStr is in our lookup, we want to decrement the value of that entry. We can do so by using the -= assignment operator.

function isAnagram(firstStr, secondStr) {
  if (!firstStr || !secondStr) return false;
  if (firstStr.length !== secondStr.length) return false;

  const lookup = {};

  for (first of firstStr) {
    lookup[first] ? (lookup[first] += 1) : (lookup[first] = 1);
  }

  for (second of secondStr) {
    if (!lookup[second]) return false;
    lookup[second] -= 1;
  }

After we are finished looping through the secondStr, our lookup should have these values:

{
  s: 0,
  i: 0,
  l: 0,
  e: 0,
  n: 0,
  t: 0
}

Wrapping up our "isAnagram" function

If we finish iterating through the secondStr without returning false, that means that our firstStr contains all values that are in the secondStr. Therefore, we return true outside of for of loop.

function isAnagram(firstStr, secondStr) {
  if (!firstStr || !secondStr) return false;
  if (firstStr.length !== secondStr.length) return false;

  const lookup = {};

  for (first of firstStr) {
    lookup[first] ? (lookup[first] += 1) : (lookup[first] = 1);
  }

  for (second of secondStr) {
    if (!lookup[second]) return false;
    lookup[second] -= 1;
  }
  return true;
}

In Summary

I hope this in-depth overview of the Frequency Counter pattern was helpful. Now that you know how the pattern works, I am confident that you will be able to impress your interviewer by showcasing your skills at an even higher level.

In my next article, I will be discussing another common problem-solving pattern called the Sliding Window. Thanks for reading, and happy interviewing!

In this article, I will share the steps you should take to increase your chances of getting an interview as a software developer.

Whether you are just starting out, or looking for something new, I am confident that you will find value in what I share below.

I'll be sharing other interview insights in future articles, as well. So look out for them over the coming weeks.

Alright, let’s get started!

How to determine your ideal role

This might sound strange, but I think it is a question that is often overlooked.

Due to the eclectic nature of our industry, it is common to just apply to any kind of job.

This is tricky because, on the one hand, you want interviews and experience with different technologies. But I have found that answering a few questions can put you ahead in your search. So what are those questions?

What kind of developer do you want to be?

If you are looking for your first job, this might be the hardest question you have to answer.

Although this might seem overly simplified, I do think it is most important to pick a niche of software that makes you happy. After all, you are the one that will be doing this work 40 hours a week, right?

If you are brand new to software development and are not sure what you like best, I suggest browsing freeCodeCamp, Code Academy, Treehouse, or Udemy. Then take a course that sounds interesting to you.

It is easy to get caught in a state of limbo when you are not sure what to do next. My advice when that happens is to just pick something and try it.

What kind of company do you want to work for?

This might be a tricky question to answer, but it can really save you lots of headaches down the road.

In software development, there are typically three types of companies:

Startups

Startups typically have under 500 employees, are less than 5 years old, and embrace a fast-paced environment.

Pros:

• You will play a large role in the problems that your company is trying to solve
• You'll work with cutting edge technology in the industry
• There will be lots of opportunities to learn from senior developers

Cons:

• You'll be responsible for (you'll “own”) more pieces of the codebase
• Processes such as code review and a team code style might not be established
• You might have to quickly throw out code you contributed to because the team is trying out other ideas

Mid-sized companies

A mid-sized company will typically have 500–5,000 employees and be at least 5 years old.

Pros:

• There's a high chance that the company will be profitable (job security)
• There will be more onboarding resources and documentation
• You'll have solidified planning strategies and clear goals for each quarter

Cons:

• More processes can mean more meetings and less time spent coding
• A larger team can mean less individual input/direction of a project
• It can be harder to adopt newer technologies due to legacy applications, and so on

Large corporations

Large corporations typically have 5,000+ employees and are over 10 years old.

Pros:

• They usually have the resources to pay higher salaries
• Traditionally there's a more vetted process to get hired, and so lots of opportunity to learn from team members
• Stock options (you benefit when your company benefits)

Cons:

• It tends to feel like you are a small fish in a large pond (contributions are not as tangible)
• Career advancement (like promotions or switching teams) can be a long-winded process
• It's often harder to bond as a team if you're globally distributed

All of these factors are good things to keep in mind when you're looking to switch companies or if you are looking to join your first company.

How do you learn more about a company?

A lot of resources have surfaced over the last 5–10 years that help folks get an “inside view” into a company’s interview process, culture, and salaries. A few that are particularly useful are:

• Glassdoor: Employee reviews, interview experiences, and common salaries
• Blind: Anonymous employee reviews, interview experiences, common salaries, and employee referrals
• Levels.fyi: Title hierarchy, title comparisons to other companies, and common salaries

Once you've answered these questions and figured out what sort of company you want to work for, and in what kind of role, you're ready to prepare for the job hunt. So what does that involve?

Update Your Résumé

I like to think that everyone on the job hunt has a personal billboard that they carry around with them. You can write on it, or decorate it however you like. That billboard is your résumé.

What you decide to put on your personal billboard will greatly affect your chances of getting an interview or not. So here are some things to keep in mind when writing a résumé:

• Keep it short (1 page, or 2 pages if you have 10+ years of experience)
• Tailor your resume to the job you want
• If past technology/experience is not applicable, try to make it applicable or leave it out
• Write 3–5 bullet points for each job
• Make your contributions impactful by using metrics (Wrote a function that processed 10,000k data points, cut down on processing time by 60%, and so on)

Keep in mind that a recruiter or HR representative will only spend 10–15 seconds (at most) scanning your résumé, so you do not have much time. You want to make sure you include details that will help illustrate that you can help this company.

With that being said, a few things you might want to leave out are:

• A personal photo

Instead: Make your name and the position you want catch the reader's eye

• Graph representations of skill level

Instead: Try replacing it with a sorted list of technologies, starting with your highest comfort level

Or: List your skills in alphabetical order and make your best skills bold

• Listing jobs that are not relevant to the career field

Instead: Use that space to expand on the experience you have in the software industry. If you don’t have much experience yet, this is a great place to expand on a project(s) you have worked on.

Try out your résumé on a friend (or tool)

Another great way to determine if your résumé conveys what you would like it to is to have a friend read it for 15 seconds.

After that time is up, take the résumé and have them tell you what they remembered from it. This can be a company name, skill, or contact information.

This is a great trial run to determine what grabs a person’s eye when they scan your résumé.

Here are some helpful tools to improve your résumé:

• Grammarly
• Google Drive Resume Template (Serif)
• Google Drive Resume Template (Swiss)

How to Conquer the Job Hunt

"By failing to prepare you are preparing to fail." - Benjamin Franklin

Let’s just face it: the job hunt is an exhausting and grueling affair for most. I have found that the best way to approach the job search is to have two important things before you start:

• Goals (daily and weekly)
• A plan of action (daily and weekly)

Let's talk about how you can establish both.

Set Goals and Create a Plan

I know what you are thinking: ummm, my goal is to get a new job? Of course, this is the end goal. But, in my experience, spending the time to determine what your goals are early is a great way to feel productive and confident.

The reason I break down these goals into two categories is that it is important to feel like you are being productive every day, even if you are not getting emails or calls back.

Some examples I have used in the past for daily and weekly goals are:

Daily Goals:

• Submit 10 applications
• Spend 30 minutes on a side project

Weekly Goals:

• Schedule a phone interview
• Spend 2 hours on technical interview prep

These might seem overly simplified, and you’re right! That is the idea. You want to make sure you make your daily and weekly goals are things that are easily measurable, and sustainable.

Make the Most of Your Time

So far we have talked about the importance of determining your ideal role, refining your résumé, and setting a schedule for yourself. To ensure that these tasks are not wasted effort, you want to make sure you are making the most of your time.

What do I mean by that? Think of the old sayings Set yourself up for success or Put the right foot forward. Basically, you want to make sure you are equally balanced in your journey to getting more interviews and being successful at them.

Besides doing the items mentioned above, a few others that can carry great importance are:

• Practice what you're learning (and what you already know)
• Work on side projects
• Develop an online presence

Practice What You're Learning

Out of all the things I mention in this post, this one should come as the least surprising.

To get better at coding, problem-solving, interviewing, or underwater basket weaving, you have to practice. A LOT. There is no getting around this step.

I, like many, have fallen victim to a cycle of planning too much, taking too many tutorials, or telling myself I’ll start tomorrow.

For me, this was, and still is the hardest part about preparing for interviews, or quite honestly just being in this industry in general. Things move really quickly, and no one wants to feel like they are falling behind.

But, tech is a mentally draining profession. It is more than understandable that the thought of practicing coding interview questions in any capacity is exhausting.

I have some good news, though. When you think about practicing, try to think of your current skills as water in a bucket. Each time you practice, even something you think is small or not enough, think of that as drops of water that fill your bucket.

All experiences, good or bad, frustrating or rewarding, fill this bucket up and make you a stronger developer every day.

I think a great way to get into the habit of practicing writing code is to give yourself a goal per week. Remember, the ultimate goal is to practice and stay consistent, so avoid setting the bar at an unrealistic level for yourself. All this will do is make you feel bad on days you just don’t feel like coding.

Remember, you are the only person like you. There will never be anyone else like you, and that is awesome. So be nice to yourself, this stuff is hard.

If you make a habit to practice just a little bit, each time that bucket will fill up and you will surprise yourself after just a few weeks of staying consistent. You got this!

Here are some helpful tools to get you in the habit of practicing consistently:

• freeCodeCamp
• Leetcode
• Code Academy

Work on Side Projects

This is something else that I am sure you have heard a million times. But I do think that working on a side project can really help you stand out as a candidate. And it'll also help you stay engaged on days you don’t feel like practicing your coding skills.

In my experience, it has been easier to get started when you can think of answers to both of these questions:

• What tech do I want to learn or get better at?
• What is a product I really like, or I wish existed?

With the answer to these two questions, you have a framework for your project! Do you like the new look of Twitter? Pick a feature and try to recreate the look and feel of it. Can’t find a habit tracker app you like? Try building one yourself.

If you would prefer to contribute to a project that is already established, that’s great as well. This can be a daunting task if it is your first time. But there is a great website that lists tons of projects on Github that are looking for first-time contributors. So check it out.

Here are some other helpful tools:

• “12 Great Ideas for Programming Projects That People Will Use” by Filipe Silva
• “app-ideas” repo by Florin Pop

Develop an Online Presence

I like to think of the web as another place that allows us to have our own “personal billboard”. There are many advantages to having a solid presence online, and some of them include:

• Networking / meeting other developers
• Showing off projects
• Getting potential interest from other companies

Putting in the extra effort to make your online presence solid can take you a long way, and the ways you can achieve this are relatively straightforward. Here are a few things I suggest you do:

Build a portfolio site

This does not have to be an extravagant, complicated website if you do not want it to be. As long as it has contact information, links to your various profiles, and a blurb about yourself you should be good-to-go.

This can be a great place to showcase your technical skills or talk about your passions and work history, too.

Get a personalized URL

A lot of common websites that developers use (like Github, LinkedIn, Medium, Dev.to, Twitter, and others) allow you to change your URL. I suggest you make it your user name. I would also suggest trying to use the same name for each website.

Start a blog

If you are not interested in building projects and would prefer writing, this is a great way to show your skills and build an audience.

Have a consistent profile photo

Ideally you want to use a photo that is professional, but lets your personality shine through as well. Once you find one, try to use that same photo across all your sites/social media profiles.

Be active on social media

This is certainly not a requirement, but if you want to leverage social media as a platform for your development, I suggest that you post about things you learn and try to engage your audience often.

Finding the balance between letting your personality show while also adding value via sharing your knowledge can be tricky, but your followers will appreciate it!

In Summary

Whether you are new to the field and are looking for your first job, or you are an experienced developer looking for a new challenge, I hope these insights help.

The job hunt can be a daunting, exhausting process. But remember, it is a marathon, not a race. You got this. Consistency is key. Every rejection is an opportunity to improve your skills for the job you were meant for.

If you are struggling with any aspect of the job hunt, please feel free to send me an email.

If you enjoyed this blog, please keep a lookout for the next entry in the Interview Insights series. My next article will be focused on preparing for technical interviews, look for that in 2 weeks. Thank you for reading!

Tom is no longer in your extended network

It's been almost 10 years since we saw massive changes underway at MySpace. If you don't remember what MySpace was, it was the popular social network before Facebook was king (though technically it still exists).

Tom's MySpace Profile

This was when everyone started with a new friend named Tom who was the co-founder of MySpace. Everyone could set their own "top 8" that could make or break the best friendships if you snubbed someone.

You could also set a song for your profile which would be added as a little player, back when it was “okay” to automatically play a song when your page loaded.

But MySpace is now a thing of the past, so why am I talking about it?

Making MySpace, your space

MySpace had a unique characteristic about it that you don't see in any of the popular social networks these days – it allowed you to add HTML and CSS into the page so that you could really do whatever you wanted with the your profile.

Example of custom code in a MySpace profile from dummies.com

Though from a simplistic perspective, this gives you some limited options. Maybe you can add some CSS that updates how the headers look and change a background color.

But realistically, this opened the door to adding full webpages that you could overlay on top of your profile by positioning your new layout above the original content with some z-indexing.

Custom MySpace profile for the band Filmore

The trick was, you had a limited amount of characters that you could put in each input. That had limitations, but these limitations helped promote creativity whether it was figuring out how to strip all of the whitespace in the code or by figuring out a way to add something with less overall code.

Learning through hobbies

Building MySpace profiles was addicting! It was a social medium that you could customize to make your own and stamp your name on it to show everyone what you did.

While you could do the same with your own website, it wasn't as easy at the time. And building out a profile on MySpace was easy, free, and you could connect with all of your friends.

One of my portfolio custom profiles

Each time I made a new page, I tried to think about what else I could do. I was even involved with small communities where we would share our work and help each other figure out how to hack things into a profile page (shoutout DM!).

This whole time, as I was trying to learn what more I could customize, I was learning how to code! I learned about how I could squeeze every inch of HTML I could out of a document and I also developed an understanding of how CSS selectors worked. I also learned how positioning allowed me to do cool things on the page and how to center things back when we didn’t have the option to flexbox all the things.

Flexbox all the things!

And this led to “business Colby” developing a sense of entrepreneurship. At this point, I was still in high school, but I was able to spin off a little business from building these pages.

While a modest $50 per profile seems low, that's a lot for a highschooler in 2004, not to mention that was a lot of money for another highschooler to pay to get one created!

STK Counter-Strike 1.6 team website

But this was the start of my code journey. Building off of MySpace, I started creating actual websites for Counter-Strike teams (CAL anyone?) and bands which would ultimately lead me to make a career out of coding.

Turning hobbies into jobs

I've heard others with a similar story, even others who similarly started with MySpace that eventually turned their interest into a coding career. While the MySpace era is something we all look back and laugh at, it really inspired a lot of people to find what they love to do.

Finding this kind of inspiration can be important to discovering how you want to spend your time. Whether it's a hobby or learning on the side to turn it into a career, keeping engaged with something you're actually interested in is important to learning a new craft.

But it's important to pay attention to how you engage with that new interest. You don't want to force it into a career and quickly burn yourself out. That will lead to regret and resentment.

While I got lucky that my interest in coding ended up turning into my career, I make sure to not "take my work home" as it's important to separate the work from your personal interests like random OSS projects on the side.

Find what motivates you

The important thing is to find something that can motivate and inspire you to develop your passion whether for a career or hobby. Each of us have our own journey, whether code related or not, and we should try to find something that will make us happy.

What was your inspiration for your interests? Share with me on Twitter!

This is for those of you out there who are about to start your job search and who may be worried that you can’t land a top-tier tech job without a Stanford CS degree. Someone told you that you’re not good enough to get a job at Microsoft or Facebook.

But I’m here to tell you that you can get that job. Here’s how I landed my dream job at Twitter.

Read more about my courses here to learn how I prepared.

You can read about my experiences after a year at Twitter here.

What this article covers:

• My background
• How I landed interviews with top tech companies in the world: Facebook Google, Amazon, LinkedIn, Microsoft, Twitter, Pinterest, Snapchat, and others.
• How I landed multiple offers as a full-time software engineer
• Lessons from my interview experience
• Subscribe here for more article updates from me

If you prefer to watch my story instead, I made a video here:

Background

I did not graduate from an Ivy league school. I went to a community college in Idaho for two years, and then finished my CS degree at a small Catholic university.

I started learning computer science in my junior year of college, because it sounded fun to me at the time. The only thing resembling a computer I had growing up was a Chinese copycat of the Nintendo SNES. Even then, it would break every time I put a cartridge in it.

To support myself through college, I took multiple part-time jobs like cleaning floors and working stand-up concessions.

When I graduated, I didn’t have a job lined up. I applied to as many big tech companies as I could, and had the good fortune of landing a few phone interviews.

At this point, I didn’t have a single notion of what a technical screen would be like, much less how to prepare for it. I headed into these interviews thinking that the interviewer would ask me what a linked list or binary tree was.

I didn’t pass any of those interviews.

Moving forward

I didn’t delve too much into whether I was good. I knew that I could learn things fast. I just needed an opportunity.

As the saying goes, cast your net far and wide. So that’s what I did.

What I did next is something I’m particularly proud of. I wrote a simple Python script that scraped job listings on Craigslist with titles containing keywords from a list, and collected the emails in a spreadsheet. For the actual war story, you can read the article here.

It wasn’t the smartest solution, but people who post on Craigslist are surprisingly accurate with their titles.

Craigslist, however, didn’t like people scraping their website. To work around this, I ran my script through a VPN, and had a timer that would pause the script every few minutes or so. It wasn’t perfect, but it worked well enough.

In the end I collected about 500 emails from around San Francisco, Portland, Spokane, and Seattle. I filtered the results by how specific and recent they were, and kept improving it by adding more and more features.

As it turned out, there were a few bots in the market already that crawled Craigslist and sent out automated emails. These were mostly offshore companies that were looking to pitch their company to the US market.

One of my workarounds was that I crafted emails that used keywords from their listings in the title of my emails. I then added more details using the body of the postings to make it seem more personable. I did a quick A/B test, and the replies I received had increased quite a bit from around 2–3% to 10%.

Out of the 500 or so emails, I received about 50 replies, and landed phone screens with a small percentage of those. I stopped at 500 because I was short on time and needed to finalize a job as soon as possible. I was optimizing for results rather than reach at that point.

As luck would have it, I finally landed a job at a startup in Seattle as a junior software engineer. The startup was located in Kirkland at the time, so I had to take a 45-min bus ride to make it in time for the interview.

I then stayed there for the next 3.5 years, where I learned a great deal of stuff like Amazon AWS, EC2, DynamoDB, SQS, and Docker. I grew a lot during this period. I learned how to write modular, maintainable code. I learned how to reason about software design. And I learned how to handle people problems.

I was working next to a group of smart people who held jobs at Microsoft, Amazon, and LinkedIn, and I tried to be the “sponge” in the group. I absorbed anything and everything they threw at me. I believe this made a huge impact in my career.

Startup Days

During my stint at the startup, I worked almost exclusively on backend development, with some dev-ops in between. I started out writing some functions to add/modify a feature that were mostly small in scope. But it was a great opportunity to understand the codebase and get some code reviews.

A year into it, I started owning parts of the codebase, and then I was tasked with turning a set of features into a service. That was the start of the SOA phase for the startup. We started turning various components of the site into services, and that’s how I started learning more about RESTful services, authentication, AWS services, pub-sub, distributed systems and so forth.

The interesting part here is that I didn’t learn about any of these through books or formal education. Rather, I needed to get that set of features done and there were the bottlenecks.

So I thought, let’s go solve it!

There were many times where I was stuck in analysis paralysis — a state where I over-analyzed scenarios and ended up not able to make progress.

Those trying times were the greatest learning opportunities. I started to learn feature scoping, negotiations, monitoring, alerting, and documentation. Each step of the process revealed more things I needed to learn. I grew the most during these 2–3 years, both as an individual and software engineer.

How I prepared for my interviews

After suffering through my first job search, I told myself that I must be prepared in future interviews.

I started preparing for interviews by charting out an overview of what I was good at, bad at, and where I could improve. I broke it down into three categories: data structures, algorithms, and system design.

Having worked in PHP for most of my professional career, and C++ in college, I wanted to try something a little simpler and less verbose for interviewing.

For this reason, I picked Python. It is a great language to learn, easy to pick up, supports many data structures out of the box, and can be written quickly on the whiteboard. I learned Python by going through YouTube tutorials like these, and also reading their documentation. I prefer Python 2.x, but you can go for either 2.x or 3.

Also, another reason why I picked Python is that it’s highly readable and easy to write on a whiteboard. Here’s a trivial comparison between C++ and Python.

A C++ program to sort in descending order:

#include <bits/stdc++.h>
using namespace std; 
int main() {   
    int arr[] = {1,10,0,4,5};
    int n = size(arr)/sizeof(arr[0]);   
    sort(arr, arr + n, greater<int>());   
    for (int i = 0; i < n; i++) {       
        cout << arr[i] << " ";   
    }    
    return 0;
}

Compare that with Python’s version:

a = [1,2,4,5,1000]
a.sort(reverse=True)
print a

I’ve received feedback from interviewers to err on the side of brevity in an interview. In a 45-minute interview, you want to use most of your time solving the actual problem.

Pro tip: pick a language that’s less verbose so that you can write the code more quickly on the whiteboard.

Preparation mode

I spent about a week going through simple challenges on LeetCode, HackerRank, and Project Euler to familiarize myself with their interfaces, and to get used to writing code in Python.

The first week gave me insights into my competence level at certain programming languages. I spent another week going through some design challenges like “design X” and went as wide and deep as I could.

This was a lot of fun for me, because I often looked at iOS apps and tried to figure out how they did it. For example, how would you build Instagram from scratch? (I was asked this at Facebook.)

My background is in API designs and service-oriented architecture, so I took this opportunity to show how I would design my own version of Instagram. And because I have some iOS programming experience from my side-projects, I could talk a little bit about callbacks and push/long-polls here.

I started the conversation with some features I’d like to have on my own version of Instagram: likes, upload a photo, and a simple timeline. Feature scoping enabled me to build a very solid API because I know these scenarios well.

I then drew some pictures of a high-level design, of how the client would interact with the backend, and of how the backend would store the data.

I started small, and then added more components where needed and proactively sought where the bottlenecks were. I made educated guesses (read educated, not blind guesses) on what the requirements would be, and how each technology would fit in well. And also equally important, what technologies would not fit well.

For example, why would you use Cassandra over MySQL to store certain information (hint: scale, speed of development, schema reviews), why use OAuth over simple authentication, Redis vs Memcached for caching data, streaming vs batch processing, and so on.

There are many areas you can explore here, so typically a one-hour session is not enough. To do well on these questions, you have to read and learn about trade-offs. Pros and cons of technologies in the industry. For this, I recommend a site like HighScalability.

Take it like a typical brainstorming session with a coworker, so explore as widely and as deeply as you can.

It’s crucial to know that these design interviews are meant to explore how much you know and how well you know it, and it’s an opportunity for you to shine. I watched this YouTube video from an ex-Facebook engineer about how to solve design problems, and it gave me insights that helped me tremendously with my design interviews. My two main lessons from it: drive the design conversation, and show what you know.

I listed out my competency level for: data structures (linked list, hash map, binary tree, binary search tree, heap, array), algorithms (binary search, hashing, dynamic programming, sorting), and language-specific syntax and libraries (like sort, lambda for Python, appending, indexing).

I picked the area I was worst at, and started working on it: algorithms.

Algorithms have never been my forte. It’s been a while since my college days, and I didn’t spend much time doing binary search in my day-to-day career. I had an inkling of how each algorithm would perform, and in what scenarios to use them. But I wasn’t 100% comfortable with writing a binary search in under 10 mins. On a whiteboard. In front of an interviewer.

I also picked up a bunch of fine-point markers from Amazon, which work amazingly well. Perhaps it’s just me, but the fine-point markers in interviewing rooms usually don’t work at all. I’d usually scramble for 2–3 mins looking for a working pen, and that’s 2–3 mins you can’t afford to waste. Plus, fine-point markers allow you to write 5–8 more lines of code on a typical whiteboard vs. thicker ones. :)

Pro tip: Get your own set of fine-point markers.

I got a whiteboard from Costco for $50, some books from Amazon (listed in the tools I recommend section below), and started practicing. I made sure I ramped up on binary search, recursion, dynamic programming, BFS and DFS. A lot of interviewing questions revolved around recursion and binary search or some variations of it.

The best interviewing questions I’ve seen had many different solutions to them, and there’s an additional layer added on top as you progress through.

One Google question I had was related to file-system directories, and how to traverse them (hint: recursion). I solved that relatively quickly, and the interviewer asked how to identify a missing file in that directory. That was a little more difficult, but I got through it. And we then moved into how to rebuild the directory, how to serialize/deserialize it, and we spent a good chunk of time debating how file directories work underneath the hood. It was a very enjoyable session for me.

Interviewing at top-tier companies

It was a nerve-wracking experience, to say the least, and a real roller-coaster.

I allocated my time in the following manner: 20% resume, 20% research and 60% interview preparation.

I spent 20% of my time fixing up my resume, which hadn’t been updated in at least three years. I took a hard look at the stuff I’ve done in the past, and picked projects I handled end-to-end, regardless of complexity.

The reason for doing this is two-fold. Taking a project from start to completion demands discipline and leadership — two of the traits I’d like to be identified with.

Secondly, ownership of a project end-to-end means I can talk about each aspect of the project at length and in depth. This proved critical in helping me navigate my design round at Twitter, where they grilled me hard on not only the designs of my projects, but also the decisions behind them.

20% of my time was used for research. Research in this case meant doing due diligence on companies I was interested in and reaching out for referrals. Having referrals helps with return calls.

From my experience, I sent out 20 or so cold messages to startups and mid-stage companies, and only heard back from a handful. But, almost all the companies I was referred to by an existing employee sent me a message within a week. This is anecdotal, but there’s value to be had there.

I am not that sociable, and I didn’t know many people who’d be able to refer me to a company I was interested in. To solve that problem, I went on LinkedIn. They have a search functionality that I used to search for 1st and 2nd-level connections. 2nd-level connections are people who’re one hop away from your immediate circle. In other words, we have mutual friends who can vouch for my credibility.

LinkedIn search

This is incredibly important, because cold-calling someone for a job is very, very hard, especially in today’s market. People tend to err on the side of caution when it comes to cold-callers. Using LinkedIn was super helpful for my research phase.

Looking back at all the companies I interviewed at, here are my thoughts on each of them:

• Facebook/Google — very mechanical. The standard interviewing process, and I didn’t feel any personal connection to them.
• Pinterest — not the best interviewing experience, but a cool product and company.
• Microsoft — loved the team and especially the manager and her manager. Standard interviewing questions, but very personable. Close-second choice. Your mileage may vary, though — each team at Microsoft interviews differently.
• Amazon — standard interviewing process. About 50% of the people love it, the others don’t.
• Twitter — incredibly fun and personal. Loved the interviewing process, gave a lot of emphasis on the individual and what I’d done in the past.
• Snapchat — cool office in LA, great bunch of people who decided to jump on the startup bandwagon. Felt like things were shrouded under a cloud of secrecy.
• Lyft — near to where I live, nice office, standard interviewing process. No strong feelings about it.

Let’s talk about my favorite

In many ways, I’d say Twitter’s interviewing style was hard. But at the same time, it was more interesting and personable than other companies I’ve interviewed at.

Their interviewing process starts with an introductory phone call with an engineering manager. That’s followed up by one or two technical phone screens, depending on how you perform. If you do well, they’ll fly you out to the office you’re interviewing for, which was Seattle in my case. There are three 1-hour-and-15-minute rounds, each with two interviewers.

The first two technical phone screens are the standard, run-of-the-mill technical screens where you solve coding problems on a shared coding doc.

The onsite rounds, however, are much more conversational and feel much less intimidating. The interviewers will ask you in-depth questions about your past projects, and they’ll grill you on what you’ve done in the past. If you claim ownership of a project, you should expect some questions about it. You’re encouraged to use them for references and to bounce ideas off of.

I never felt any pressure to magically come up with a fully working solution, and it felt highly collaborative.

The others

In comparison, interviewing at Facebook and Google felt much more mechanical. They have one or two technical phone screens, and five to six onsite coding rounds. Each round involves some coding on a whiteboard, and you’re expected to come up with a near-perfect solution in a reasonable amount of time.

Facebook has two coding rounds, one design round, and one behavioral round.

I went through an additional shadow round at the end of the day, which didn’t count towards my overall score.

Google had five coding rounds, none of which focused on designs, and not a single interviewer asked about my previous projects. I don’t necessarily think this is bad. But I think it felt very mechanical and didn’t give much opportunity for the engineer to show what they’re capable of. Some people do well in these scenarios, much like some students do well in exams.

I did not enjoy my interview with Pinterest. I think the product itself is interesting, and their engineering team seems to be working on very cool technical problems. But I definitely had a negative experience during my interview there.

Pinterest has three coding rounds and one design round. Of those four rounds, the design round was most disappointing to me. Here’s why:

The interviewer came in late, and he spent a few minutes glancing over my resume before proceeding to draw some APIs on the board. He gave a short description of what he expected the API to do, and asked how I would solve it. We clarified the features of the API, and I started describing my solution using the whiteboard. About 5 minutes into it, I turned around and saw him taking a nap!

Not cool.

I gave the recruiter my feedback in a survey, and I didn’t hear back from them after that.

I won’t delve into specifics of the questions I was asked during all the interviews. Instead, I’ll share some of the insights and useful tips I learned from my preparation process.

What I learned:

• Be honest on your resume. Most companies will ask you questions about your resume, and they can tell if you made it up. It’s better to be able to know 100% about one project than to know 10% about 10 different projects.
• One-page resumes are recommended. This is especially true for tech companies, and it seems that the wisdom within the tech sphere is that you should reserve two pages and longer for post-doctoral work, or if you’ve done a lot of projects that you know and care deeply about. A friend of mine runs a company called Jobscan that scans resumes and makes specific, actionable improvements on them. They’re pretty awesome, so try them out :)
• Socialize and establish a network. There’s a lot of competition for software engineering jobs, and these top tech companies are filtering through thousands of resumes a day. Having a referral will help you get some eyes on your resume.
• Nail your pitch. Every company that’s interested in you wants to know why you’re interested in them. A bad answer: I just need a job right now to pay bills. A less-bad answer: I was browsing online and found you guys. Sounds like you’re working on interesting things. A good answer: I know you’re doing some interesting work in X to achieve Y. I’ve done some work in the past and here’s what I learned about A, B, C that might be related to X. I am passionate about Y because blah. (Don’t use this as a template. Instead, you should see the pattern here — do your research, use your background, and show the company why both of you would fit well together.)

Some more advice

Technical interviews are incredibly difficult, and sometimes it’s a hit-or-miss. The best opportunities, however, are reserved for those who are prepared.

• Prepare early, prepare well. Everyone knows that they should prepare for an interview, but most don’t know how to do it well. As with anything worth doing, it takes deliberate practice to do well at something. And deliberate practice means you need to have a system.
• Build a system to practice technical skills. I started by rating myself from 1–10 on how good I was, and worked on the ones I was worst at. I spent days on different types of questions until I fully mastered each concept. And I wrote notes daily on Evernote. I had a note that serves as a brain dump for all things programming. It is full of programming tips & tricks, common errors and misconceptions, frameworks for solving specific types of questions, and much more.

My notebook

• Keep a notebook of the things you’ve learned. I use both Evernote and OneNote to keep track of things. OneNote for technical stuff/code, because I like that I can easily format the note any way I like. I use Evernote for essays/thoughts. The image above shows a note I keep on architecture and system designs.

Evernote for thoughts/tips

• Jot everything down, even if you don’t think you’ll use it. I tend to forget very easily, so anything that I learn I write it down, including shell commands. I read technical blogs from time-to-time, and if I find anything interesting I jot it down on Evernote right away. I’ll revise it every week or month and reorganize accordingly. This has helped me tremendously over my career.
• Get mock interviews. This was definitely very valuable and I highly advise it. I had mock interviews with friends and tried to practice as much as I could. If you can’t find friends to practice with, then I recommend Refdash, which is an Interview-As-A-Service. They have a group of interviewers who work at big tech companies like Google, Facebook, and Microsoft. These interviewers will assess you on your coding and design skills. The best part of it is they’ll give you a score at the end of it with specific actionable items on how to improve.
• It’s OK to fail. I failed multiple interviews during this whole process. Sometimes you just have a bad day. It’s not the end of the world if you fail. Companies are biased towards saying no because it’s a lower risk for them. A false positive costs more than a false negative in the long run. The first few rejections definitely stung the most. I failed multiple phone screens when I first started interviewing, and my confidence level sunk. I had doubts in my mind about my abilities and started fearing that my skills weren’t relevant in today’s job market. However, I gave myself a tip: If you fail 10 times, then try 10 times more. All you need is one success. That reassurance gave me a lot of confidence to keep pushing through and when my first offer came through, the other offers came much more easily.

It took me about 2 months of deliberate practice and preparation for my interviews. I spent about 20 hours/week, or 80 hours/month, learning and writing notes on top of a full time job.

To build up my resume, it took 3.5 years of focused, deliberate work. I intentionally picked things that were tough and icky so that I could learn more than anyone else. Even though I don’t have a brand name university or top-tier tech company on my resume, I made up for it with a clear, thorough understanding of the projects I worked on. And this was possible because I researched and wrote down notes of everything I learned, and have a system to review them.

Remember: the strong survives, the tough thrives.

TL;DR: Don’t give up, set yourself up for opportunities, practice a lot, and stay hopeful. Focus on the process, and take a disciplined, dedicated approach to the process.

Tools I Recommend

• Designing Data-Intensive Applications: Awesome book for learning about scaling distributed systems! Highly recommended.
• Elements of Programming Interviews: Great for solving coding problems.
• Cracking The Coding Interview: Great for covering foundational CS coding problems.
• Daily Coding Problem.com: This is a free-to-try website that offers free daily coding problems. You can sign up for interesting daily coding challenges, and you can pay for solutions if you want.
• Dropbox: I keep all my files, pictures, resume here. Easy access, installed once and available everywhere. Love it ❤️ (If you sign up thru this link, both of us will get free 500MB!
• CodeRunner: I love this Mac app! I used this multiple times to run ad-hoc Python scripts/functions and it just works amazingly well. ?
• Kafka the Guide: I used this book as a reference guide, and enjoyed it for the high-level description.

(I share more resources I personally have used and recommend on zhiachong.com, if you’re interested in learning more.)

Thanks for reading my story! You can find me on Twitter and LinkedIn. I would love to connect and talk more about tech, startups, travel :D

Credits:

Brandon O’brien, my mentor and good friend, for proof-reading and providing valuable feedback on how to improve this article.

YK Sugishita, an up-and-coming Youtube star who left his job at Google to pursue his dreams, for proof-reading and giving critical feedback.

In my first year of working in the industry (6 months as an intern, 6 months as a full-time employee), I worked at startups that were less than 10 people large. I was one of the only 2 or 3 developers, and usually one of the first. Throughout the year I spent working at startups, I learned a lot, and I failed a lot. Most importantly, I experienced amazing growth in my career and my technical abilities. Here are some of the biggest benefits of working at a startup:

Ownership

Being one of the few people on the development team, I was always able to make a pretty big impact on the code base. In one of my jobs, I created the front-end of the app almost entirely by myself. In another, I re-wrote the entire front-end of the app.

I was able to take this level of ownership as a new developer because, quite simply, there was no one else to do it. Through ownership of the code base, I learned a lot of important lessons very quickly. If I wrote a method longer than 10 lines or had Components (I was using React at my previous position) that were longer than 100 lines, I knew that I had to comment on everything. If I looked at the code next month, it would be time-consuming to remember what I did and why. I wrote thorough documentation regarding certain decisions we made — whether it was for refactoring code, implementing new features, or just upgrading React (I actually wrote an article on how to upgrade to React Router 4 that was born out of this).

I learned these lessons out of a feeling of responsibility for the code I had written. It was mine, and it was my job to make sure that in the future, I, or anyone who would look at this after me, would easily be able to see what it was doing.

Fast-paced

When I started these jobs, my managers didn’t waste any time on getting me started. By the second week of working, I usually had already made a PR or two and had some tasks assigned for the sprint. Within a month of working, or once I felt acquainted enough with the code base, I was already tasked with implementing new features by myself. We had deadline after deadline, and there was never any shortage of work or interesting things to do. I was constantly learning new things, and I was rarely bored. My GitHub commits share the same story:

Contributions I made while I was working there are shown in the red box

These contributions illustrate changes made to the default branch of the repository. Commits added through PRs, mostly. It was a rare day when I didn’t make a PR for something. It was usually because I was working on a particularly large project.

Mentorship

This is one of the biggest advantages of working at a small company. My manager only had one person to focus on — me! Whenever I needed help or was confused about something, all I had to do was turn to my manager and ask.

When my manager had decisions to make — whether it was UI/UX decisions or decisions about what to focus on next, we usually had a discussion about it.

I learned a lot about UI/UX, product management, hiring, and creating technical roadmaps because my manager was willing to have this dialogue with me. After all, who else was he going to talk to? It was mutually beneficial for us to have this dialogue — I learned a lot, and my manager had a sounding board.

Impact

When you’re one of ten or fifteen people at a company, your work makes an impact on the overall growth of the company. Especially if the company’s mission is something you’re passionate about, you’d be actively making an impact on that mission every day. Your work isn’t just one small part of a much larger machine — your work is the machine.

Caveats

Startups can be tricky to navigate — toxic behavior and a negative environment are rampant in startups because no one has held them accountable just yet. So, if you’re thinking about working for one of them, there are some red flags you should look out for!

• Lack of clear leadership — do the founders and your manager have a vision for where they want the company to go? Do they make decisions quickly and do they know what they want?
• Lack of growth — when was the last time they hired someone? How many people are they planning on hiring in the next 3 months? How about 6 months? How are sales? What are the next steps to grow the company and the team?
• Undervaluing Employees — I’ve seen startups who try to undercut employees when it comes to pay and benefits severely. Know what your minimum or expected salary/equity is, and use your judgment and talk to people you trust if you have reason to believe that accepting an offer lower than what you expect will pay off.
• Not the right mentor — The mentorship aspect I mentioned earlier is only worth something if you have a good mentor! Be sure that your manager is knowledgeable, patient, and wants to mentor you.
• Overworking Employees — Ask how many hours a week are expected of employees. Ask whether you’d ever be subjected to unusual (late evenings/weekends) hours. I usually only ever worked 40–45 hours a week. There were a handful of occasions where I needed to stay an hour or two late.

You can usually find out this information when you’re interviewing — either by observation or just directly asking!

In addition to asking if the startup is a suitable place to work, you should ask yourself if it’s a good fit for you, too!

• You’re okay with risk — When you work at large companies, you generally know what you’re getting. You may have had friends or distant cousins who work at those companies, and people’s experiences are pretty well-documented or established. You can expect that not much will change from the time you accept your offer to the time you start working to 5 years from then. But when you’re at a startup, things can change on a day-to-day basis. You may not know what you’re getting until you get there. Additionally, a lot of startups fail — there’s a chance your company may not be around as long as you’d like it to be!
• You want the experience for your career, not your bank account — As I mentioned before, a lot of startups fail. And a failed startup is worth $0 — as is your equity.
• You like fast-paced environments — Fast-paced environments are not for everyone! Know what environments you thrive best in, and if ‘fast-paced’ isn’t how you’d describe your ideal environment, then you may not want to join a startup. At the end of the day, you need to do what’s best for you and your career — which means being in an environment that’s best for you.

And that’s my case for why you should consider working for a startup, especially as a new developer. I’ve seen a lot of people in the dev world who leave college and chase prestige. They only look for work at Google, Facebook, Microsoft, or IBM-type companies.

There’s nothing wrong with wanting to work for large, successful, and innovative companies, of course. I think that this is another alternative that should be considered when searching for your first job! Even if you’re not a huge fan of startup environments, or you just can’t seem to find a good one, you can find a lot of these benefits at slightly more established (between 50–100 people) startups or small companies.

If you have any questions/comments about startups or working for one, please feel free to comment below!

Getting a tech job after a coding bootcamp is very possible, but not necessarily pain-free.

The days/weeks/months after a bootcamp is completed come with a learning curve of their own, and often include rejection and serious contemplations of what you’re doing with your life.

(Unless you come in with a job offer or some serious leads — lucky you!)

In the bootcamp, you learn more than you ever have in a short period of time. You will build strong foundations for learning how to code.

However, you are not going to learn enough to pass most coding challenges. You will not be ready to have discussions where you confidently share your opinions on different languages and technologies. To top it all off, you might not have any professional technical experience to show your worth.

You will feel like an imposter.

Due to your un-readiness, as well as some skeptics in the industry who doubt the legitimacy of these non-accredited programs, you are going to constantly be rejected for not meeting expectations.

It takes on average six months to find a job after a coding bootcamp. Thankfully, after nearly seven months, and moving across the country, my misery came to an end. I got (and have) a job that I love.

If you’re contemplating a12-week coding bootcamp, remember that it is not a quick $15k hack for changing the direction of your life because you are:

A. not satisfied with you current job or personal life

B. not happy with how much you make

C. assuming you will find a job shortly after the program ends

D. somewhat curious/interested/intrigued about what tech is like

You have to really want this to make it to the end.

Quite a few students in my cohort went back to their old industry/job function after a few months post-bootcamp. Some have also gotten very coveted jobs — it honestly goes both ways!

Here are some tips to stay motivated and to help you land your first job after the coding bootcamp.

Get some real world experience volunteering

It’s important to continue to improve your skills while also working on your team-working skills. Having your code out there that is actually in-production and in active use is the best way to prove yourself and contribute.

Taproot foundation connects nonprofit organizations with skilled volunteers.

I used this site to find opportunities in my area, as well as remotely. I worked as a frontend developer for a mental-health site, part-time, remotely.

My role was to convert Wireframes (created on Zeplin) to React components. I split my “free time” between job searching/interviewing and volunteering.

We had weekly conference calls and I was learning much faster and more efficiently than if I were to find another YouTube tutorial/project to follow along.

Not only was I contributing to a cause I cared about, I was given a lot of mentorship by my teammates and was also given some leeway if I had a busy week if I had something going on — such as interviews. Check it out here.

Get some real world experience, in general

Better than working solo, working on your own projects is being out there.

Be open to internships and apprenticeships. Many of them are open to bootcamp grads, and the chances of you getting accepted into those are much higher than landing a full-time job at the same company. The chances of you getting hired from completing an internship at the same company are very high too!

Ask around your network to see if anyone needs some help with something — maybe a professional website needs some fixing up, or ask a local business if you can offer some help. These are great to add to your portfolio!

Have a decent portfolio site — because it is being judged

This isn’t an industry where your resume tells all. Resumes are accompanied by websites. Those are your two assets, as you submit your faceless application.

Your website is an ongoing showcase of some of your best work.

There is where you tell your story. Take advantage of this opportunity to demonstrate competency and professionalism.

During many interviews I went on, my website was commented on. My Medium articles were sometimes also mentioned.

Here is a checklist of things you should include:

❏ Bio/about section

❏ Projects (ideally deployed) with documented source code (Github)

❏ Downloadable resume

❏ Relevant social media profiles: LinkedIn, Twitter

❏ Easy-to-find contact information

❏ Custom web url

❏ Responsive design

Here is some inspiration.

Use LinkedIn effectively

LinkedIn is the face you put out to the world, so put yourself in a good light. Often, as soon as your application is considered, employers look at your LinkedIn.

First things first, make sure your profile is complete, the more detail the better. Have a professional photo, a detailed bio and resume.

The more details you include about your work history, the less recruiters/hiring managers will have to guess about your background. The more chances you have for getting contacted.

Help recruiters find you by having the right preferences on the career interests section of LinkedIn where you can let recruiters know you are open to jobs. Put where you are in your job search, what job titles you are open to, what cities/locations and types of jobs you are open to.

You can also look for mentors in your industry that you would like career advice from, sort of like a mentorship program. You can select what sort of preferences you have in order to get recommendations.

You can choose to get advice from someone who is in your region, from your college, or is your 1st or 2nd degree LinkedIn connection.

Attend networking events, Meetups, Hackathons

The key message here is to put yourself out there.

PUT YOURSELF OUT THERE.

Do not hide behind a screen, applying to hundreds of applications and hoping for some good luck to kick in.

You are competing against thousands of bootcamp grads, who have the same tech experience as you, so go out there and put a face and personality to your name.

Meet people, attend events. I met great people who were also looking to increase their knowledge of tech, get a job, and some even helped me with my job search.

A great way to find these types of events is by going on Meetup.com, and looking in the Tech group category. You can search by city or zip code.

(FYI: a lot of these events have free pizza, snacks and drinks!)

Add who you connect with on LinkedIn, and this will only help you be more relevant in recruiters’ searches.

Another great event to participate in is a Hackathon. Not only is it a great way to show that you are actively involved in the tech community, but you’ll acquire industry-related skills, learn more, and network with peers and industry-level experts.

Study for the interview: coding challenges

The hiring managers will certainly question whether you have the skills to take on the job, especially if you don’t have any prior professional tech experience.

Coding challenges range from the simple FizzBuzz challenge or something more complex, such as building an entire app. You’re going to have to spend extra time beyond the coding bootcamp

You can use this website to practice technical interview questions: https://interviewing.io/

I also practiced by going on Glassdoor and reading what questions people posted that they were asked. I’d practice those questions, and topics that they covered.

Sometimes, they ask the exact same questions!

Have a support-group to lean on

You can’t get through this without your friends. The best support I got was from other students from my cohort, or former bootcamp-graduates who understood my journey and pain points.

Personally, at times, it was a bit tough leaning on non-tech/bootcamp friends (and venting to them). Often my well-meaning friends would ask after just two months of unemployment, “how long do you think it will be before you go back to your old job?”

But don’t let this discourage you…push on!

_Photo by [Unsplash](https://unsplash.com/@priscilladupreez?utm_source=medium&utm_medium=referral" rel="noopener" target="_blank" title="">Priscilla Du Preez on <a href="https://unsplash.com?utm_source=medium&utm_medium=referral" rel="noopener" target="blank" title=")

Photo by Unsplash

This article is about how I went through my job hunt for a full time position as a software engineer in New York City and ended up with my dream job. I had spent two years building my skills and had aspirations to work at a top tech company with a high bar for engineering excellence.

I knew this goal would not be easy to achieve, especially without a CS degree, barely having any network in New York City, and having to compete against engineers from top schools. It would be a long shot, and I was prepared for the long haul.

9 weeks later…

I’m ecstatic to say that I’ve accepted an offer from DigitalOcean to work as a Software Engineer II from their NYC HQ!

This success came after countless study sessions, mock interviews, hours of practice, and facing numerous challenges & rejections. But I kept my spirits up and came out the other end happier than I imagined possible.

How did you go from start to finish?

That question is what this article is all about! I’ll be detailing my preparation process for interviews, how I built my network, and managed myself during this job hunt.

That being said, everyone’s experiences are different and should pull from this article what they feel will benefit them. No two job hunts are the same and there are different factors in each one.

With that said, let’s dive in!

First things first: build a solid foundation

Photo by [Unsplash](https://unsplash.com/photos/vII7qKAk-9A?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener">NESA by Makers on <a href="https://unsplash.com/search/photos/software-development?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText" rel="noopener)

Before anything else, it’s vital that you have a rock solid foundation in the fundamentals of software engineering. Instead of chasing after the hottest technologies, what’s important is to have the technical foundation needed to learn new things quickly and deeply.

In my opinion, the best way to do this is to pick one industry-proven language and stick with it while learning about variables, functions, tools, software design, databases, APIs, and building web applications. This allowed me focus on depth in my knowledge, proficiency in solving coding challenges, and experience in building quality projects.

To build my fundamentals, I chose to study at Launch School which offers an extensive curriculum and rigorous assessment process that ensured that I had deeply learned the fundamentals before progressing.

Build a project that impresses employers & engineers

SpaceCraft demo

In the current day, there are multitudes of bootcamps and online tutorials that provide aspiring software developers with projects to help them land a job.

However, there is now a saturation in the market of developers with simple CRUD apps or clones of popular apps like Instagram, Netflix, Reddit, etc. These projects no longer impress employers or other engineers as they once did.

That said, many engineers need some way to evaluate you before giving you a referral and there is no replacement for showing your skills off with a solid project.

That’s why Gooi, Nick, and I built SpaceCraft, a real-time collaborative REPL that allows developers to write and execute code in the browser for Ruby, JavaScript, and Python.

It was an incredible experience, and also a TON of work. You can read more about how we built SpaceCraft in this article or read our case study.

We spent hundreds of hours researching how to build a REPL, enable real-time collaboration, use Docker to create isolated user sessions, and handle user requests with a proxy server.

Market yourself effectively

While SpaceCraft may showcase our skills, I still needed to get people to look at it. Since I had relocated to NYC for my job hunt, my professional network was close to nil and I did my best to put myself in front of as many engineers as possible.

That’s why our team wrote our case study, an article on HackerNoon, and presented at Meetups. These efforts helped us stand out among the sea of other applicants and generated interest from employers & engineers.

Presenting at Meetups were a game changer for me as they got my name out there and procured referrals to several companies, along with giving me the chance to practice and refine my communication skills.

I also built a personal website and beefed up my LinkedIn & AngelList profiles in order to make it easier for prospective companies to find me and see my work.

Devoting time to market yourself and skill set through writing articles, presenting at events, and professional networking sites can lead to a big payoff in the interview process.

I had a big increase in the number of engineers and companies reaching out to me after seeing my updated profiles and hearing me present, and having a video of my presentation to include in my outreach emails resulted in a higher response rate and more interviews.

Reach out to engineers & companies

In the same vein, I made sure to consistently reach out to engineers at companies I was interested in. Using LinkedIn Connect requests, I had over a dozen coffee meetings with engineers from DigitalOcean, Cockroach Labs, Oscar Health, DataDog, Peloton, and more. These meetings helped me get a feel for the job market in NYC, hear an insider perspective on company culture and teams, and gain referrals.

My advice is to approach these meetings casually and with interest in your fellow engineer’s work, career, and company. Don’t go in asking for a referral at the beginning, many times they will offer to refer you if you’re nice and the conversation goes well.

Another form of outreach that I did was more directly emailing engineers. Whenever I found a job posting that I really liked, I would reach out to an engineer who works at the company through LinkedIn Inmail, using Clearbit Connect when needed to find contact info.

In the email, I would include an introduction on my background, my most impressive project, a link to one of my presentations, and ask if they were open to chatting about the position.

This form of outreach lead to my highest response rate out of any other avenue with nearly 1/3 of all my emails getting a response. Remember, the job hunt is entirely a numbers game and it’s best to try out all forms of outreach to see which nets you the highest returns.

Study, practice, repeat

Photo by Unsplash

That said, none of these efforts would go anywhere if I didn’t have the skills to succeed in the technical interviews. With a solid foundation in the fundamentals, I needed to spend my time solving coding challenges and studying topic relevant to the positions.

The types of questions and challenges you can face in interviews are VAST and often times you won’t know what to expect. Many of the top companies will focus on algorithms and data structures, while startups and mid-size companies may focus on more “practical” problems like refactoring an existing class or adding features to a basic project.

My advice is to study a variety of coding challenges and do your best to predict the questions they will ask you. For algorithms and data structures, my main resources for building a foundation and conceptual understanding were:

• A Common-Sense Guide to Data Structures and Algorithms

• Cracking the Coding Interview

• BaseCS

I also solved 2–3 problems a day on LeetCode for 5–6 days a week.

Many companies will also have a system design interview to assess what level to hire you for. If you’re aiming for mid-to-senior level roles, you’ll need to devote more time to this area.

I found the best resources to be Grokking the System Design Interview and reading various blogs on specific topics. Here are a few blogs I’d recommend:

• All Things Distributed

• High Scalability

• Gainlo

• BaseDS

Another very common step is to complete a take home challenge. The variety of these challenges can make it hard to prepare for, but there are some common topics. Several that I saw were:

• Build a RESTful API that handles several provided cURL requests

• Build a CLI app that stores inputs (like albums, artists, and release year) and allows users to retrieve them

• Build a game using React/Rails (ex: Tic-Tac-Toe, Blackjack, Minesweeper)

• Given a spec and example of the finished product, create a web page that is as close to pixel perfect to the example as possible.

The upside is that you have more time to complete them in the comfort of your own home, and there are lots of opportunities to impress by writing a comprehensive test suite, identifying & addressing edge cases, and finding extra touches to add.

Over my job hunt, I typically spent Monday-Thursday applying to companies, doing outreach, and solving LeetCode challenges or studying system design. I reserved Friday-Saturday to practice building a take home project. Here are some to consider:

• https://x-team.com/blog/how-to-create-a-ruby-api-with-sinatra/

• https://www.discoverdev.io/blog/series/js30/

• https://daveceddia.com/react-practice-projects/

• https://medium.freecodecamp.org/how-to-build-a-react-js-chat-app-in-10-minutes-c9233794642b

• https://codeburst.io/writing-a-crud-app-with-node-js-and-mongodb-e0827cbbdafb

• https://codeburst.io/learning-react-js-by-building-a-minesweeper-game-ced9d41560ed

• https://github.com/karan/Projects

To prepare for live coding challenges, I used Pramp for mock interviews 3–4 times a week, which improved my performances by leaps and bounds.

I’ve written before on this topic in Why You Need an Interview Script, but essentially when under pressure our mental abilities can suffer due to the feeling of being evaluated. The best way to combat this issue is to have mock interviews to recreate the experience until we’ve adjusted to it. Having a problem solving process also really helped to give me a leg up, and the best one that I’ve found is PEDAC.

Know what you’re looking for in a role & company

Photo by Unsplash

With all that said, it’s important to take the time and consider exactly what you’re looking. Do you have a strong preference between backend, frontend, or full stack positions? How big of a company do you want to join? Which industries interest you? And in which direction do you want to grow your career?

Your answers to these questions can have a dramatic effect on which companies you choose to interview with. As software developers, we’re lucky to have no shortage of jobs and companies looking to hire, but it’s important to remember these points:

1. There is a large variety of roles and areas of work to choose from, and you should consider which areas of software development you want to specialize in.

2. You should try to find a role and company that you’ll be happy to work in for several years. My personal opinion is that it’s important to build your experience, credibility, and professional network as an engineer and it’s best to work 1–2 years minimum in each role, rather than job hopping every 6 months — 1 year.

3. Just as there are a lot of good jobs in software, there are also a lot of bad jobs that you want to avoid. Not every job will have you work on mature, experienced teams building ambitious, challenging projects. There are jobs in which you could mainly handle tedious tasks, clean up legacy code, or simply minor UI components day-in & day-out.

So take the time to think about what you want and list the things that you look for in your dream job. For myself, I wanted a role that focused mainly on backend development with the opportunity to:

• Learn a compiled language like Go.

• Work on distributed systems and possibly microservices.

• Join an experienced team of engineers to learn from.

• Have the ability to work remotely from time-to-time.

• Work at a company that values diversity and inclusion.

• Have benefits toward continued education.

I aggressively sought out companies that offered most of them and didn’t spend time applying to those that didn’t. While not every company would have everything I was looking for, I knew that I would be happier with the end result than if I just mass applied everywhere.

A side benefit was that by targeting the specifics of my next role, I was able to focus my studies on relevant topics that allowed me to improve with every interview, which I feel gave me the needed edge to land my role at DigitalOcean.

Manage the interview cycle

Photo by Unsplash

The interview process for software development is grueling, and the potential for burn out is very high. Typically, the process can comprise of 3–5 steps, or even more, like so:

• Initial phone screen with HR or a recruiter

• Phone call with a company engineer or hiring manager

• Live code challenge with a company engineer

• Take home project

• Onsite at the company

• Potential offer extended

Exhausting, right? And every company is different, with some having only 1–2 interviews before the onsite and others taking months!

From my job hunt, I experienced a cycle that repeated itself. First, I would have initial phone screens with multiple companies. These would then lead to code challenges, take home projects, or technical phone screens. After several of these steps and opportunities getting filtered out, any onsites would get clustered into the same week or two.

Since the intensity of these stages increased the further I went in the process, I had less time for new applications due to increased studying, culminating with my onsites which had me studying full-time without sending fresh applications. If no suitable offers were extended, then I would start again with fresh applications and the cycle would start over.

Here are some tips when going through this cycle:

• Try to keep your application activity high throughout the cycle. It’s important to keep applying and doing outreach in order to fill your interview funnel with new opportunities.

• Have a daily goal of applications and outreach to complete. My daily goal for Monday-Thursday was to submit at least 5 applications (often with cover letters) and reach out to 5 engineers for coffee or to ask about open positions.

• Think critically about what to expect in each interview. You may get some details in your initial phone screen about the interview process, but always ask for more info in order to prepare.

• If you have a call with a CTO, know that it’s common for them to ask you technical questions regarding your resume as well as behavioral questions.

• Don’t schedule onsites on back-to-back days. They are by far the most exhausting steps and need more preparation. Always give yourself at least one day of rest in-between onsites to recharge, review topics, and mentally prepare.

Avoiding burnout through the process

At this point, I want to address the importance of avoiding burn out during the job hunt. With the sheer number of interviews to complete and associated stress, it can easily feel overwhelming at times.

Don’t overwork yourself by studying & coding for 6+ hours a day on top of interviews, and dedicate time each week to disconnect and recharge. It’ll help you maintain your energy & focus as you steadily ramp up the intensity of later stage interviews.

At most, I studied 4 hours a day and prioritized deep work as described in Cal Newport’s Deep Work, which is where you focus intensely for a period of time on a task that is more difficult than what you’re used to without any distractions.

This meant solving algorithm problems or practicing projects that were harder than what I had already completed. This made sure that I kept improving my skills, while also identifying where I struggled and needed to study more.

And no matter how busy my week was, I always took at least one day off to relax and recharge for upcoming interviews.

In the end…

I’m extremely happy with the results of my job hunt and feel that the approaches I detailed above worked well for me. For those of you out job hunting now, I hope that this article proves helpful to you. I also recommend reading the following article, which I found very helpful for my job hunt:

What it took to land my dream software engineering job — Sun-Li Beatteay

Good luck to everyone out there job hunting, keep it up!

Please let me know what you think in the comments! I’d love to hear more about your job hunt experiences and what has worked for you.

Avoid what you don’t need; learn and practice what you do

Like most people, I had no plans whatsoever to teach myself to code. The decision came when I lost my Customer Service job in 2015.

The transition came as organically as falling in love with a soulmate. We were old loves—I had tried to make it work in college, but the timing wasn’t right. Not to say it was easy! But, it was so much easier with so much emotion to drive the experience.

I got my first job in tech in about 10 months after I started teaching myself web development, after an incredible amount of work.

And please believe me when I tell you that if I can do it… you can, too.

I’m quite sure there are lots of guides out there on this topic—how to teach yourself to code and get your first coding job. But this one is written by me, so it’s different. I think you’ll appreciate my perspectives. :)

Now, I think it goes without saying that condensing the entire process down to 5 steps is over-simplifying. I’m going to give you the general sense of what to do. You have a couple of options for filling in the gaps, and honestly, you should do both!

Option 1: Lean on your communities for support
Option 2: Get some dedicated help and guidance

Both are actually my specialty! I’m a passionate community builder. I understand the importance of seeing and hearing from people who are trying to do what you’re aiming to do.

Option 1 is an important part of your growth as a developer. You’ll need a network of people. This industry is actually particularly awesome, and a ton of fun. We grow along with the tech—and each other. We see each other at conferences. We participate in weekly Twitter chats. It’s dope.

Option 2 has some barriers to access. Essentially, it involves having someone—ideally an experienced coach with a deep understanding of your situation and goals—take your hand, get to know you, explore your dreams with you, and plan out your journey from where you are, to where you want to be. Then, you delve into the skills with an actual map and pathway to your destination. At that point, the hard work is yours and yours alone.

I LOVE working one-on-one with newbie coders, but of course, with the level of attention and expertise required… it’s not free. Most of us do what we can to support newbie coders via blog posts, podcast episodes, books, and more—but some of us are willing to give more of our time and presence than others! As such, Option 2 is an investment in yourself.

So, this is indeed an over-simplified, but still a pretty thorough overview of the process of teaching yourself to code, and then getting your first dev job!

Step 1: Figure out what the hell you’re doing

I created an entire 14-page guide to this really early part of the journey because it’s the most easily-overlooked part. It’s also why a lot of people sputter out—they simply didn’t do their initial homework.

You can download that guide, called “10 Things You Need to Know BEFORE Learning to Code”, here:

Thinking about learning to code?
_Considering learning to code and changing careers? Before you take the plunge, find out what the industry isn't…_resources.lavieencode.net

First, why do you want to do this?

Have you been dreaming about coding since you were a little kid? Or maybe you just heard that coding is the future, which makes sense to you since technology is growing so quickly, so you’d like to get on the train. Regardless of your reason, you’ll need to establish that early on. It will be what pushes you forward when things get really challenging.

You’ll need to create a budget for yourself, which I know sucks because I, too, hate budgets. If you’re changing careers, you need to be sure you’ll be able to make your transition with as little stress as possible. Coding is tough enough as it is… do your due diligence not to make it harder on yourself.

Is there even a web development industry where you live? If so, tap into it, and start talking to folks. Attend Meetups. Get to know people who do something similar to what you want to do.

Ask questions about companies hiring in the area. Do people like their dev careers? What are their salaries like?

If there isn’t a lively dev industry in your local area, you’ll need to get creative. Remote jobs could be an option if that’s something you’re open to. Alternatively, if you have the resources and the flexibility, relocating to a new city could be an exciting change alongside your new career.

The entire point of Step 1 is to ensure that if you’re looking for a job, you’re not just jumping into things without scouting the territory first.

If you jump in, you may find yourself feeling unprepared and stressed out when bills come due, unexpected events come up, and generally speaking… life happens.

Step 2: Choose a job title, and work backward

Alright, so I approach this differently than a lot of people out there. When people start learning to code, one of the biggest questions I hear is “what should I learn?” (also, “where should I learn it?”).

Keep in mind, you’re not even coding yet by this point. Or maybe you’re just poking around, learning the basics, but you’re not actually building projects. You’re still laying the foundation, and learning about your tools and the purpose behind them. This is a super important phase!

With all those tools out there though… how do you know which are going to align for an actual job title?

Wouldn’t it suck to learn a bunch of fairly unrelated skills and language to a basic level, and then realize they don’t actually get you a job? Or that you’ll need to flesh just a few of them out with additional learning, in order to even be competitive for jobs in your area?

Yeah… that’s what ya girl did.

Quick, relevant side story

I learned HTML and then added on CSS. I kinda hated CSS at first, but we worked it out and we cool now. So far so good, yeah?

Then, I got to JavaScript. Basic tools like variables and even loops and some basic data structures, I was fine with. But, in general… things started getting tough for me.

I have a non-verbal learning disability. It’s kinda funny that wasn’t diagnosed until after I struggled through gaining the required skills to get that first job 10 months in. My struggles made so much more sense.

At this point, algorithms scared the crap out of me. freeCodeCamp’s algorithms were super challenging. A lot of my past learning trauma came up. I cried a bunch out of frustration when I simply couldn’t contextualize a mental model for my neuroatypical brain to “make it click”.

In a panic, I went off the rails. Or perhaps “on” the rails, as I started learning Ruby. Got to the same point. Panicked again.

Switched to PHP and WordPress. Actually, I really liked them both and primarily use them nowadays along JavaScript. But, I got to that same freaking point, and finally basically collapsed in exhaustion. What the hell was wrong with me?

I took a break around the time I wrote this article because I had had an existential crisis, wondering if I was even fit for this:

Why I’m scaling back on learning to code… and ramping up on learning Problem Solving
_Wow, it’s been almost a month since I’ve posted! I can’t believe time is flying by so quickly. I have a point to this…_medium.com

That story kind of serves as a cautionary tale, to show what can potentially happen if you do things out of order, or without an initial structure. You gotta be able to build these skills for a job if you want a job.

So here’s my question: why not just take the guesswork out, and figure out what kind of work you’d like to do first?

And of course, this is going to change over time! We grow and change not only as developers but as human beings over time. We learn more about ourselves, and we want to change up our goals. But starting with some kind of compass direction REALLY helps.

How do you figure this out? You’ll want to take a really deep inventory of your dreams, passions, and existing skills. Often, it helps to evaluate this with the help of someone else (ahem, like me). We have the skills and talents we bring to the table that other people don’t… and that we ourselves often overlook.

Look at what’s available in your area. Search on job search sites like Indeed. Ask in local online fora.

But the important part here is to pay attention to the skills that are listed: both tech and interpersonal.

Yes, interpersonal. We have enough problems with a lack of interpersonal skills like effective communication, empathy, compassion, and inclusion. Don’t come here bringing more.

But those coding skills are going to give you guidance and a path to your destination so that if you change your goals, you at least know what you’re deviating from and to.

Step 3: Build your skills

By this point, you have a good sense of your local development industry, and you’ve done your research on job titles. You have an idea of what kinds of skills you’ll need to build on your way to your first dev job.

Now, it’s time to build your skills.

It’s important to note that you’ll be doing this alongside Step 4, and alongside anything else, you may be doing (we want to keep those things limited). You always need to be learning and building your skills while also building projects with them.

I generally recommend that web developers start with the front-end since all roads lead to the user’s experience. But this really varies based on those initial goals. See where it was helpful to identify them first?

For example, your starting point will be different if your goal is to work with data. Perhaps your goal is to learn, say, Python, since Python is natively very efficient with data management. You’ll naturally lay out your skills-building journey differently depending on your end goals.

The important part here is that no matter where you’re headed, you have a roadmap. You want to avoid getting caught up learning things you don’t need because they will get in the way of you getting a job ASAP.

You should have a list of resources that you know to work for you. Knowing how you best absorb information is absolutely integral to this part. Don’t waste time with books if you learn best from videos. Again, time is of the essence, so you need not just to learn but learn intelligently, efficiently, and effectively.

Spend a good amount of time on this section. You’re adding tools to your toolbox, and you’ll be using them every day once you start working.

Step 4: Build your portfolio and resume

Remember, Step 4 is happening alongside your skills building. You’re learning daily, and applying what you learn. And of course, there are a couple of really important parts here that I find coding students overlook. So let me hit on those real quick!

Hot Tip™️ #1: Projects get you The Edge™️ as a self-taught coder

You don’t have the long resume dating back to your Computer Science major at MIT. Neither do I. But, like… woe is us?

Nah.

As a self-taught coder without the CV to back up your skills, you’re going to need to show whatcha got. So, even though you will be focusing on your resume as well, you REALLY need to put time into that portfolio. If nothing else, your resume will grow along with your portfolio as you add skills!

Hot Tip™️ #2: You don’t need a ton of projects!

First, you don’t need a ton of projects. I think a lot of newbies get overwhelmed at the thought of having to build tons of projects in order to show what they know.

This is why we’re aligning those skills toward the actual job description. If you build even ONE project but maintain it intelligently—you’re going to be leagues ahead of your peers.

Ok, so you created one project, you’ve been posting some commits on GitHub, and you’re already feeling you need to jump onto the next one. Hold it right there, padawan.

Did you make the absolute most out of the project? Because you’re learning skills toward a job, they’ll probably come together as a stack. And you can more than likely apply many of your newly learned skills to the same practice.

Let’s say you’re working toward becoming a front-end web developer. You just built your first website.

Can you turn a website into a web app, so maybe users can log in?

If you didn’t build your page mobile-first (you should have!), how about refactor it as mobile first?

Take the time to look at your projects as not only an asset but a glimpse into the inner workings of your brain. This is INCREDIBLY important to hiring managers. They want to know how you think, so they can determine if it brings something valuable to their company and team.

So, to piggyback off Hot Tip™ ️#2…

Hot Tip™️ #3: Become a storyteller, not just a coder

What better way to show people the inner workings of your brain than to document your journey?

One of the most slept-on resources for getting a job is… drum roll…

…your README.txt file.

This shouldn’t just be where you tell people how to run your program. This is where you should be telling hiring managers:

• Why you added that feature
• Why you abandoned adding that other feature and removed it
• Your next plans for expanding
• What you’d like to see in terms of feedback
• What you learned at each step
• What you feel proud of, and what you could’ve done better

Why are we ashamed of writing our stories? We don’t have time for that we need to get you a job!

Make it funny, even. Make it epic. Your journey is epic.

But yeah, leverage your README.txt file, and you’ll seriously be so much more attractive to the people checking out your portfolio and considering you for employment.

Step 5: Apply for those jobs!

There’s SO much to unpack in this step, it’s just not possible to cover it all in a single post! ? So, I’ll go with just dropping a bunch of value bombs on all y’all.

Hot Tip™️ #1: Just apply already

One of the most frequent questions I get is “when should I start applying for jobs”? My response is something along the lines of “yesterday”.

Seriously. Go ahead, apply. The worst they can tell you is “no”.

So, here’s the thing about applying for jobs as a newbie self-taught coder. You want to do it right, and really demonstrate:

• Your willingness to learn
• Your growth so far
• Your enthusiasm for the industry (and specifically, company!)

When you communicate with hiring managers, you’re going to want to be honest with where you are, while showing what you’ve done. Those two components will put you on the radar. You’re being vulnerable, and you’re still retaining some control over your perceived image.

Another important thing to remember: when you apply to a company, it’s not a one-shot deal. Many newbies make the mistake of thinking it is.

Ok, so let’s say you’re rejected for an interview. Now, you have a window to ask for feedback. If they respond, that’s a really good company. ??

If you really like the company, and they know you’re self-taught (they’ll know from your resume anyway, so just be transparent), tell them that you’d like to grow your skills in their direction and re-apply in the future.

Boom. You just formed a connection with hiring managers and showed how determined you are to improve your skills in order to meet their requirements.

Hot Tip™️ #2: You need to develop solid tech interview skills

Alongside building your portfolio, you’ll need to grow those interview skills. But not just any interview skills—tech isn’t like every other industry out there. We’re edgy. We like you to prove what you know.

This is especially important for self-taught coders. You’re going to need to know how to do things like:

• Explain what different tech concepts are
• Solve algorithmic challenges—while explaining your approach
• Write out your steps to the solution
• Read your interviewers
• Do a bit of a dance to maintain control over the interview (this is my specialty haha)

There are lots of resources out there for this, like Gayle Laakmann McDowell’s “Cracking the Coding Interview”. Plus, it doubles as a blunt weapon.

Cracking the Coding Interview: 189 Programming Questions and Solutions
_I am not a recruiter. I am a software engineer. And as such, I know what it's like to be asked to whip up brilliant…_www.amazon.com

You’ll need to be yourself. They need to want to hire you. It’s hard to be yourself when you’re not sure what’s expected of you, but why get hired as someone you aren’t? That just sounds like fodder for a whole lot of Imposter Syndrome.

By this point

By this point, you have a growing toolbox of skills.

You’re learning every day. You’re building projects, but making the most out of them instead of just ditching them and moving onto the next thing. You’re telling a story with your GitHub README.txt.

But most importantly, you have an idea of where you’re going. That internal compass, alongside a supportive community (like #CodeNewbie!) is going to be what saves you when you get lost.

Build on, grow, and gain confidence in yourself. You’re a total warrior, and you can do this! ??

What we should do though, is learn from this. As a senior developer, I’ve made my fair share of mistakes. Here are the 7 big mistakes I made when I was starting out as a junior developer, and how to avoid them.

Taking the first job that comes along

If you’re teaching yourself to code, or coming to the end of your university degree, getting your first job will be one of your main goals. It’s the light at the end of a long tunnel.

And getting a job is not easy. There are more people than ever trying to get junior developer jobs. You need to write a killer CV/Resume, make it through many rounds of interviews, and the process can take forever.

Which is why it’s understandable how tempting it can be to jump on any job offer you get with both hands.

Yet, this can be a bad move. My first job was far from ideal, from a learning and enjoyment perspective. The developers had a “meh, it’ll do attitude” and often did things half-heartedly. There was a culture of blame, and I was often required to cut corners to meet tight deadlines. Worst of all, I wasn’t learning anything.

I ignored the warning signs in interviews because I was blindsided by the opportunity of getting a job. Any concerns I had were thrown out the window when I received the offer with a nice salary to boot.

Big mistake.

Your first job is important. It gives you a taste of being a true developer, and the experience and mentorship you receive will set you up for the rest of your career. Which is why you should thoroughly do your research on the role and the company before accepting any job offer. The last thing you want is a bad experience or bad mentors!

So, before applying or accepting any job offer:

Research the company

Search for the company on Glassdoor, the internet, their website, and read the reviews. This will give you a good feel for if the company is suited to your goals and needs.

Ask people you know

If anyone in your network has worked there or knows anyone who works there, have a chat with them. Find out what they like, what they don’t like, and generally what their experience was.

Ask the right questions in the interview

The interview is the best chance you have to learn about the company, so make sure you come armed with a set of questions to ask the interviewer. A few things you can ask are:

• Ask about the development process (what methodologies do they follow? Do they do code reviews? branching strategies?)
• Ask about testing (what sort of testing do they follow? do they have dedicated test engineers?)
• What is the culture like (is it a relaxed environment? what is the support like for junior developers?)

Not choosing a path

No doubt the path to becoming a fully fledged developer can be a confusing one. There are many languages, frameworks, and tools available. A mistake I made at the beginning was trying to learn everything. Funnily enough, I ended up not learning very much.

One minute I would try and learn Java, then JQuery, then C#, and then C++ …

Instead of focusing solely on one language at a time, I was jumping between things depending on how I was feeling that day. And trust me, that is a very ineffective way to learn.

I would have gotten much better results and climbed through the ranks faster if I had chosen a path or set of technologies, and stuck to learning them. For example, if you are an aspiring front-end developer, learn JavaScript, learn CSS/HTML, and pick a framework. If you’re focused on the backend side of things, again, pick one language and learn it well. You do not need to know Python, Java, and C#!

So narrow your focus, choose your path, and create a plan to become a pro in your chosen path (here’s a roadmap that will help you map out your path).

Being too “fancy” when writing code

So you’re preparing a project to show the interviewers, or landed your first job and working on your first task. You are trying your best to impress. What’s the best way to do that? Show off this super fancy coding technique you learned to complete the task, right?

Wrong.

This is a major mistake I made and a mistake I see junior developers do too often. More often than not junior developers will try and reinvent the wheel, or use some complicated solution in a bid to try and impress.

The best approach to writing code is the K.I.S.S principle (“keep it simple, stupid”). By keeping things simple, you’ll reap the benefits of easy to read, maintainable code (the next developer coming along after you will appreciate it!).

There’s more to life than code and work

An early bad habit I ran into was not learning to switch off. I would often bring my laptop home with me at the end of the day. I would sit for hours trying to complete a task or bug that could have waited until the next day. This unsurprisingly, left me feeling burnt out and stressed.

Part of the reason I did was this because I felt an urge to complete everything as soon as possible. Whereas, in reality, I should have realized that work is an ongoing process, and it can more often than not wait until the next working day. It’s important to switch off and remember the other things in life — friends, family, hobbies and having fun. Of course, if you like to stay up until the early hours writing code, by all means! But when it is not enjoyable, consider stopping and doing something else.

There is always tomorrow!

Not saying “I don’t know” enough

It’s easy to get stuck on a problem or task you are trying to complete, it happens all the time, even to the most senior developers. A mistake I made whenever I was a junior developer was not saying “I don’t know” enough. If management asked me a question I wasn’t sure about I would bluff an answer instead of saying “I don’t know”.

I felt if I said “I don’t know” people would think I didn’t know what I was doing. The reality is that this is not the case. Nobody knows everything. So if you’re asking a question and you don’t know the answer, say that. The benefits of this are:

• You’re being honest and not misleading the person who is asking the question
• You’ll learn something new when it’s explained to you
• You’ll gain respect for saying you don’t know something. Not everyone is capable of admitting they don’t know something.

Trying to progress too quickly

I’m sure you’ve heard the saying, “you have to walk before you can run”. Never does this saying have more relevance than in the field of web development. When you start your first job as a junior developer, you’ll be eager to hit the ground running, and get your hands on nice big coding tasks. You’ll even be thinking of how to get a nice promotion to the next level!

Whilst ambition is good, the reality is that these sort of things will not come straight away for a junior developer. At the start of your career, you will more than likely get the smaller, easier tasks and bugs to work on. These might not be the most exciting things in the world to work on, but it’s necessary. It allows you to put one foot into the codebase and get familiar with the process. Secondly, it allows your team and managers to gauge how you cope with working as part of the team, and where your skills lay.

I made the mistake of getting frustrated at these smaller tasks, and I let this frustration get in the way of my work. Have patience, perform every task you get to the best of your ability, and the more exciting work will come!

Not getting involved in the community & building a network

The development community is great. The community is always willing to help, provide feedback, and can even help with motivation. Being a developer is tough, and can sometimes take its toll. As a junior developer, the tough times would have been easier if I had got involved in the community earlier.

Getting involved is also a great way to learn. You can contribute to open source projects, see how other’s write code, and see how developers collaborate on projects together. These are all skills you can bring to your day job and will make you a better developer in the long run.

Find communities that interest you — freeCodeCamp, CodeNewbies, 100DaysOfCode are some good ones — and get involved! You can also get involved in local meetups in your home town or city. Check out meetup.com for this.

This also lets you build a network. A network is basically a bunch of people you know in your industry. Why is a network important? Let’s say you are looking to move into another job. By reaching out to your network, someone may be able to recommend a specific role, or even refer you to a company. This gives you a solid advantage going into the interview, as you’ll have someone to vouch for you, and will no longer be another “name in the pile of resumes”.

Thanks for reading!

To get the latest guides and courses for junior developers straight to your inbox, make sure to join the mailing list at www.chrisblakely.dev

Originally published at www.chrisblakely.dev on March 25, 2019.

I’m an engineer, but I also have an MBA and for this post I’ll be wearing that hat. I was seriously considering buying an actual hat with “MBA” printed on it, but some good people talked me out of it, so unfortunately it’s a metaphorical hat instead of a real one.

I often see engineers complain about recruitment processes: They are long, they seem totally irrelevant to the job, everything is stupid. We just don’t get it. Unfortunately, we’re probably right — some employers don’t have any idea what they’re doing, but does it really have to be that way?

One of the very best courses I took during my MBA was a course about recruitment processes and the research behind them. It left a lasting impression on me and affected my perspective on recruitment processes when I was hiring and as a candidate. When I hear these rants, I often try to explain the rational behind a good hiring process, and I think this is insight which can be useful for engineers and recruiters, which is why I’m writing this post.

Hiring is hard. Mistakes are expensive. We have no idea what we’re doing.

Of course we are excellent at it. It’s always someone else who has no idea what they’re doing.

So, What Can We Do?

First, let’s look at some common tools you have at your disposal, describe them and check how good they actually are, based on the latest academic research in the field:

The validity numbers given here are “predictive validity”. This means that the validity of the result on a specific test is the correlation with success on the job. A 0 validity score means there is no correlation and the test is worthless (you might as well toss a coin), 1 would mean the test perfectly predicts success on the job.

Intelligence Tests: IQ tests, SATs etc.
Validity: 0.51
Even if you don’t ask for the scores on these tests directly, you usually try to get them by proxy by checking the school they went to and their GPA. I know this seems unfair to many candidates who are excellent engineers even though they didn’t do very well at higher education (or didn’t go at all, i.e. bootcamps etc.) but it is a quick and cheap way of getting through a lot of CVs.

Work Sample Tests: Requires you complete a task related directly to the job.
Validity: 0.54
When done well and at home, this saves time for everyone . It also allows the candidate to display their best work with a minimal amount of pressure. However, the time it takes is often underestimated, and if it’s done at home candidates may “miss” something and get stuck without answers, while potential employers are missing valuable signals.

I’ve seen many engineers who seem to think that work samples are THE BEST AND ONLY way to really show their worth. For the life of me, I don’t get it. Many work sample tests are just a way for the employer to get you to put in time with close to no cost for them. As a candidate I really don’t see how they’re better than a coding interview — the task is either just as synthetic and unrepresentative of the actual work, or too complicated and time consuming.

Employment Interview: I’m sure I don’t have to explain what an interview is.
Validity (Structured): 0.51
Validity (Unstructured): 0.36
Ah, we’re finally getting to something here. What’s the difference between a “structured” interview and an “unstructured” interview?
Well, a structured interview has repeatable questions and clear and objective criteria for answers. An unstructured interview, ummm, doesn’t. Ultimately, an unstructured interview comes down to a “gut feeling” about the candidate. I’ve often felt thankful for having clear and objective criteria specified in advance, because it’s so easy to skew the interview result according to your first (entirely biased) impression of someone.

Job Knowledge Tests: Direct questions on the subject matter.
Validity: 0.48
Usually this is carried out by giving the candidate a questionnaire asking them domain knowledge specific questions. Things like “How does web routing work in technology stack A”, “What would happen if you tried to assign this value to a string in technology stack B” etc.

Not bad so far. Now I’m getting to the “good stuff”:

Assessment Center: When you pay a whole lot of money to send candidates to spend their day doing group dynamics with a bunch of strangers.
Validity: 0.37
Can you tell I think these are stupid? And not only me, their validity is relatively low and their repeatability (i.e. getting the same score on repeat tests) is also extremely low. If you’re recruiting — don’t do this, please. If you’re a candidate and you have the privilege of refusing — just say no.

Reference Checks: Asking past employers about the candidate.
Validity: 0.26
I know many employers insist on reference checks. But their validity is not so great and they should be used with caution.

Graphology: Sending a writing sample to a hand writing ״specialist״ who can tell if you’re a good match for the job. Usually used for integrity testing.
Validity: 0.02
Graphology is NOT a good recruitment tool. DO NOT use it. Have I stressed that enough?

The coding interview

Even though I already know these statistics, it still hit me hard while writing this post: even the best tests have only 0.51–0.54 validity, and that is far from amazing. Is this best we can do? What can we do with the tools we have to get better results?

Enter the dreaded “coding interview”. Whether done on a whiteboard or an online editor, it allows employers to pack a work sample, structured interview, and job knowledge test into a single session. By giving many such coding interviews, conducted by several different people, you can achieve better results, improve reliability and reduce bias (“gut feeling”). That’s why recruitment processes are so long and exhausting (for everyone involved).

I know I don’t have you convinced yet, but I’ll talk a bit more about how to assess the quality of this process later on.

Ok then, let’s see how it’s done.

Is this a good question?

You are given three containers.

• One box contains all white balls, one all black balls, and one a mix of black and white balls.
• Each box is labeled, but all the labels are wrong.

How many balls would you need to pull out to determine which box is which?

What about this one?

The count-and-say sequence is the sequence of integers beginning as follows:

1, 11, 21, 1211, 111221, ...

1 is read off as one 1 or 11.

11 is read off as two 1s or 21.

21 is read off as one 2, then one 1 or 1211.

Given an integer n, generate the nth sequence.

Or this question?

Are you pregnant or are you planning to become pregnant in the next year?

You’re wrong.

It doesn’t matter if you answered “yes” or “no”.

Questions are neither good nor bad.

Now, I’m not recommending asking someone if she is pregnant, because that’s illegal and usually quite irrelevant. But if the job is in a factory with dangerous chemicals and hard physical labor, that question might actually be an important question to ask!

Questions should be the last thing you do when you build your process.

First, ask the right questions

• What is the actual job definition?
• Which technical skills does one need in order to perform the job well?
• Which soft skills and personality traits do you value as an organization?
• How much time, effort and money are you willing to spend in order to find the right person?
• How much time and effort will the candidate be willing to spend in order to pass your process?

Only after you have the answers to these questions can you begin to create a concrete process. You can’t copy the answers to these questions from another organization. You have to figure them out for yourselves.

Create the right process

• Decide what your screening parameters are and screen ruthlessly. Do not waste your or your candidates’ time.
• Use structured interviews for technical and for soft skills interviews.
• If you feel the candidate will be willing and it saves you a lot of time an effort, you can also use a work sample.
• Call references and perform background checks only as needed.

Measure, refine, repeat

Every time I mention the validity of some process or other I’m asked how the validity was measured. I’ve actually read the articles and I can tell you the methods they used, but to be honest — it doesn’t really matter. What matters is what works for your organization. You may find that the “coding interview” doesn’t match your values or doesn’t give you the signals you need to decide who to hire. You may find your candidates love doing long work samples in the office and it allows you to get to know them better.

The point is that once you have your process in place, you must make sure it is working!

• How many candidates who passed your initial screening made it through the interview process?
• How many candidates who passed the entire process accepted the offer?
• How long do employees stay with you?
• How are their performance reviews?

Gather your data and refine your process accordingly. This is a continuous challenge!

Avoiding bias

Now you’ve built a process and have statistics on the candidates hired. How can you make sure you’re not testing for “rich white male” instead of “good programmer”? How do you verify you’re not hiring “people like us” instead of checking actual “culture fit”?

My personal pet peeve is open source contribution or other “after hour” projects as a requirement. If you’re an excellent programmer but have other hobbies, or if you god forbid have a family and actually want to spend time with them — that’s it, you’re out. That, to me, is an example of screening on irrelevant traits.

Unfortunately, some common quick fixes don’t seem to work. Implicit bias training doesn’t (usually) affect outcomes, it often makes things worse. Diverse interviewers do not necessarily make less biased decisions either, as they often show the same biases as anyone else.

You should remember that this is an entirely subconscious effect — you don’t have to be overtly racist or a bad person to be biased. It’s a natural part of how our brain works, so it’s up to the process to help us fight our biases actively.

The best way to tackle this issue is to add diversity measures and use the “measure, refine, repeat” cycle to check how you’re doing.

If you measure diversity and refine your process accordingly — you’re going to find where the problems are and take appropriate actions. If it’s a real pipeline issue — read Moran Weber’s excellent article. If it’s not really a pipeline issue, look at how you treat diverse CVs, how well they pass your process, how often they accept your offers, etc.

Aside: Integrity

This is a bit off topic, but it’s just too good to skip. You could skip it anyway, I won’t hold it against you.

I mentioned graphology as a bit of a joke, it’s validity is so low that it’s an absolute waste of money. So why do some employers still use it? You’d be surprised: to some of them it’s a way for someone else to decide what they feel they can’t! But some of them actually believe it’s accurate, how can that be?

Let me tell you a story: When I was taking this course, during one of the classes we were asked to give a writing sample. When the next class started, we each got a graphological assessment of our personality and were asked to rate how accurate it was. Most of the class graded it 4 or 5 for accuracy. Turns out we all got the same analysis… How could we be fooled like that?

This is called the Barnum effect, and basically what it means is that when we read a generic text like astrology or graphology, we will believe the parts that are true and dismiss/forget the parts that are wrong! The final impression we’re left with is that the text was very accurate.

Turns out the best way to measure integrity is by asking directly! There are pen & paper tests with a series of questions about integrity. The irony is that dishonest people believe they are normal people in a dishonest world, so they have no problem telling the truth! They will say “sure, I take boxes of pens home with me” or “why shouldn’t I lie about being sick?”, and expose themselves as less than worthy of trust.

If you are recruiting, I hope this gave you some insight into how to build a good process. If you’re a candidate, I hope this helped you understand what’s broken in recruiting and what actually works. For me — I’ll finally have a ready made answer for all the frustrated candidates out there. Good luck!

Over the past few months I’ve had quite a few inquiries from young black women who are starting their careers in tech. They’ve been asking for advice related to working in the industry, navigating through corporate, and flourishing in the workplace.

Out of the belief that black women can learn from each other and can support each other in our professional aspirations, I reached out to black women in tech and asked them three questions:

(1) If you could go back in time to the beginning of your career in tech and give yourself a piece of advice, what would you say?

(2) What’s one piece of advice you would give to black women entering the tech industry?

(3) If you could change one thing about your current work place to make it a better experience for black women, what would it be?

The advice in this piece comes from black women who work in design, research, advertising, engineering, IT, and product/program management; they work across major cities in the U.S. and most respondents were 25 to 45 years old.

This is their advice.

If you could go back in time to the beginning of your career in tech and give yourself a piece of advice, what would you say?

Themes: don’t be fearful, believe in yourself, secure the bag, be vocal about your aspirations, seek out wisdom and support.

“People will sometimes be trash towards you. They’ll tell you that you don’t know enough, or that your knowledge isn’t technical enough. Don’t listen to them. They’re going on some impossible standard that even they themselves could not fulfill. You simply loving technology is enough.”

“Just go for it! Stop making excuses for reasons not to go after something you really want.”

“Build a network of other black women in tech who have been in the industry. You’ll need them during difficult and discouraging times at work. More importantly, they’ll be able to give you advice on how to navigate corporate life, especially because you’ll find yourself in spaces where (more times than not) you’ll be one of the only black women there.”

“Prioritize self-care in your hustle. Don’t let relationships fall to the wayside just because you’re busy. Find the time and make the time for those close to you and prioritize your well-being.”

“I would say that even though the road aheads looks lonely, you are not alone. I would say to lean on the women who you have known and seen pave the way ahead of you, both inside and outside of the tech industry, and don’t be afraid that you will be a ‘bother’ by asking for help and admitting you are having a hard time. My greatest advice would be to extend grace and pride to myself for having the courage to move outside of a comfort zone to pursue a path that was not yet fully determined, but would ultimately lead me to swim in the depths of my own possibility and to not fear or doubt those depths.”

“Be more confident. Take the steps that will foster trust in your knowledge, expertise, and skills. For example, thoroughly prepare before each meeting, regardless of the meeting’s level of importance, reading key documents, annotating the documents, etc.. Confidence is nothing more than preparation. Build a reputation of being on top of your stuff.”

“You are the main character in your life, it’s your world, enjoy your journey, indulge in your passions, love yourself fiercely, you’ll make it.”

“Go for the money and also take heed of companies’ reputations. Seek out others’ insights about what the company is like to work at before accepting an offer, as well as meet your team.”

“Don’t be afraid to articulate what your interests and career goals are and stick to them. Don’t be afraid to counter offer.”

“Have faith in yourself. You forging your own way is a strength, not a weakness. I pivoted from working in the non-profit sector with a non-technical education and I felt so much like a fish out of water in Silicon Valley. However, as I gained more experience as a designer I realized that my background was an asset that set me apart.”

“Start to advocate for yourself earlier, you are your own best cheerleader.”

What’s one piece of advice you would give to black women entering the tech industry?

_Themes: sponsors > mentors, take risks, don’t give up on your career aspirations, be confident in what you have to offer, your thoughts and ideas have val_ue.

“Getting a sponsor is more important than a mentor. A sponsor is someone who can speak to the quality of your work/work ethic and will go to bat for your during performance reviews or in landing your next project/gig. In essence, they are willing to risk their social & professional capital in order to increase yours. That is not the same as a mentor. A mentor’s only risk and expenditure is their time.”

“If a job looks interesting, apply for it. Ignore the urge to fit 100% of the qualifications. Studies show that men only look at and fulfill maybe 25% of them. Imagine a woman who has 75% applying for the same job. You’d be a shoe-in.”

“Have confidence that your perspective, no matter how different, is worth being heard. Be bold in sharing the ways you think and experience things differently, because it could have a strong impact on the direction of a product or business that may not have had diverse perspectives without you. Know that your voice is of value, even if there is no one else that supports you or if there are others who try to tell you otherwise. Often when you lean into those moments and speak up, you will find that there are others who have felt the same but have felt as though they didn’t have the space or confidence to say it.”

“Network, you’ll realize later how important connections are.”

“Don’t stay at a company or team if you don’t like it or them, there is someone else willing to pay you more and be happy.”

“Write down your vision and make a plan. Find trusty mentors and sponsors that you can meet with for sound meaningful feedback.”

“Don’t be fooled into thinking that all ‘mainstream’ women will be your sponsor or allies in the workplace. I have been surprised by the people who have gone to bat for me or defended my reputation when things go wrong (which they inevitably will). Many of those people have included white men on my team. In fact, white men have been equally — if not more — supportive of me than white women.”

“In the majority of work team environments you will be the only black female. Be intentional in your decisions, speak up and never be afraid to make mistakes. That is how you will learn. Also, always have a goal that is targeted towards career growth that you are actively working towards.”

“Don’t give up. We need your thoughts options and ideas. Also relationships matter so get ready to network to help you get in and keep networking to move up.”

“Build together. Ask for help. Seek community wherever you can to support you. Even if that just means joining a Slack group for WoC.”

“Be confident in your value and skills others might doubt, but never doubt yourself — you are unlimited. Haters are immature.”

If you could change one thing about your current work place to make it a better experience for black women, what would it be?

Themes: increase representation by hiring more black women, safety to acknowledge white privilege and racism, white co-workers leading the conversation on diversity & inclusion.

“I would have encouraged black women even more than ever to apply for positions they think would be out of their realm. We need a lot of black women in management. And to stop looking for mentors after a certain point and start looking for sponsors. You need someone to drop your name in the decision room when the time comes. Start building those early (and never think you DON’T deserve the accolades).”

“MORE BLACK WOMEN! The worlds need you.”

“I’m the only black woman in our software company of (10000+ employees, Italian-based company). I’ve asked HR to improve our cultural diversity training as it’s affecting my comfortability at work (e.g. comments about hair, people trying to use ‘slang’ with me, assuming I’m ‘aggressive’ because I’m tall, black, and played basketball, being asked why I don’t make friends or eat with anyone when everyone groups together based on nationalities/cultures/race).”

“More black women. I work at a large, well-known tech company and even though we have several office buildings, I’m the ONLY black woman in my building. It can feel really lonely and like I always have to be crushing it in order to prove that I belong here.”

“To have white people own their whiteness and racist ideologies so we can have courageous conversations about race and why in 2019, I am the first African American to obtain promotion and tenure in my department. Also, why no one in the department wants to acknowledge it.”

“More of us! There is so few black women in design-tech jobs.”

“Provide more education on white privilege and white feminism. As the only black woman in my building, I find it difficult to join in conversations that my white women co-workers are having about equality because, well, the only perspective they’re talking about is what it means to be a woman. Whereas for me, it’s about also being a black woman. It’s a privilege to only see your gender as being a barrier to equality and not have to take into account your ethnicity and/or race.”

“I work in a remote and fully-distributed team that seems resistant to meeting in person. To me, I see this as a negative because relationship building happens in-person. No amount of Slack messages or video conferencing can replace in-person networking. For remote workers, have more opportunities for building relationships in order to foster social bonding and team trust.”

“Hire more of us! Be intentional and transparent about your hiring process when it is time for the team to grow and don’t leave inclusion out of the discussion when seeking candidates.”

“Just one thing? Unconscious bias training for management.”

“I would create more visibility of the black female leaders here … I would still like to have a solid network or space for black women specifically to lean into.”

“Please stop forcing black women into being the Diversity & Inclusion Champion. We’re tired and shouldn’t need to take on the responsibility to educating you on privilege, racism, and your own bias. No, we don’t want to talk about this all the time. I often feel like I have to talk about Diversity and Inclusion because no one else in the office is championing it or even discussing it. And as the only black women, that’s discouraging AF.”

“More internal groups targeted to mentoring and advancing career growth for women of color in the company.”

“I don’t have any other black women on my team. It would be nice to have more people that looked like me in the office.”

If you liked what you read, please increase the chances of this piece being read by others by sharing it on social media! Thanks!

But you’ll also have the not so amazing times. The times when you are staring at the same error for days or stuck trying to understand a new concept. You may be thinking, “I am just not cut out for this. Why am I trying?”

So what do you do if you feel yourself wanting to give up? I’ve got some tips for you, but first, here’s my story about when I almost gave up, and what I did about it…

Note: You can skip straight to the tips: Take a step back, and realize it’s normal.

Lights dim & dramatic intro music plays

Disclaimer: The following story took place not that long ago and within the current galaxy

When I first started programming as part of my Computer Science course, I felt super lost. People will say you’re not supposed to know much when you’re just starting out, but I really struggled in the beginning.

I just couldn’t grasp any coding concepts:

Abstraction: The idea of focusing on the ideas, rather than, the implementations… “OK Yoda, what does that mean?”

Interfaces: “Ah! I know this one! That's the thing the user uses to interact with the…oh wait”

Functions and Objects: “Not overly sure how many of these things I need or when I need them. So I’ll just use one for now” creates monolith file called MyClass.js

Arrays: “Arrays hold things. Got it. But only one type of thing. OK, fair enough I guess. Oooh look, you can make a 2D array…an array of arrays. EASY! I’m ready to start this assignment”:

Assignment: The following code is a 3D array, which is an array of arrays of arrays, containing random numbers. Iterate over the array and print the prime numbers and the frequency in which they appear, in order. Consider time complexity.

“…hmm…”

leaves the building

And don’t get me started on data structures and algorithms…

I wasn’t sure why I was so far behind in my course.

Was it that I just wasn’t cut out for coding?

Was it the quality of my course and lecturers?

Was it the copious amounts of beer and partying I did in my first few weeks of university (Nah, it couldn’t have been that).

After a few years of struggling and scraping by, I still couldn’t code the simplest apps. The final straw was being told by one particular company that I should consider another field when I was interviewing for an internship.

This was the lowest point for me, and I was tempted to give up and drop out. But technology was my passion, I wanted to become a developer more than anything. I was in my final year of university, and I decided enough was enough.

I sat down, opened my laptop, put on some AC/DC, and started practicing.

I would practice day in and day out. On coding websites, on my own small projects, following tutorials, if there was a way to practice code, I was doing it. When I wasn’t writing code, I was reading about code. I read other peoples code. I read about the people who wrote good code.

Slowly but surely, it started to click. All the concepts I didn’t understand were slowly coming to me. And like a phoenix from the ashes (or, something more computer related and less dramatic), I graduated and landed my first junior developer role.

After many years of experience, learning, and mistakes (those stories are for another day!) I’ve progressed past the junior developer stage. I’m currently working at a startup leading the product development. I’m also mentoring developers more junior than myself, and loving every minute of it.

I am now on a mission to pass my knowledge to junior developers all over the world. To show that anyone can crack their way into the world of web development with some hard work, and some dedication.

Hopefully, I haven’t bored you too much — still with me? Good, let’s get onto the tips to try when you’re feeling a tad defeated.

Take a step back, and realize it’s normal

The first thing to do before you throw in the towel on your web development career is to realize that it’s perfectly natural to feel overwhelmed at times. The best way to do this is to step away from the code for a while. Go for a walk, read a book or watch TV. Basically, take a break and relax for a bit. If you need to take a few days off, that’s perfectly fine as well.

When you return, hopefully, you’ll feel a bit more refreshed and fired up to go again! If not, here’s a few more things you can try.

Have patience

I don’t think this is stated enough, but patience is super important for developers of all levels. When learning to code, it can be frustrating to not understand something, especially if you’ve been looking at it for hours.

But the next time you feel yourself getting frustrated at a bug and error, remember the “step back” approach from the previous point and try telling yourself:

“OK this sucks, but getting frustrated won’t help anything. I’ll take a break and come back with fresh eyes and try again”.

You’ll be surprised how much this will help.

Celebrate the wins when you get them

A lot of junior developers I’ve met can be quite hard on themselves and fail to properly acknowledge their accomplishments.

“I finally got this button working on my app but it took all day!”

So? The point is it now works! Huzzah!

It’s important to celebrate the wins when you get them. Whether you are trying to get your first HTML page working or trying to create your own complex web app, whenever you get something working, celebrate it.

Scream “SUCCESS” at the top of your voice, jump around the room, dance with the neighbors. OK, that’s probably a bit much (I didn’t do any of that, I swear…) but you get the idea. By celebrating the wins, you’re acknowledging your accomplishments, filling yourself with joy, and motivating yourself to keep going for more wins.

Set smaller, definable goals

It’s easy to sit down and say “OK, my goal is to learn how to code”. This is a great goal to have, but it’s a difficult one to measure. When have you finished learning how to code? Is it when you have created your first website? When you have created your first large app? When you’ve got your first job?

However, what if you said, “Today I am going to learn what the arrow syntax is in JavaScript and ES6”? You have a clear definable goal, which is easy to measure, and you guessed it — gives you a win to celebrate once you’ve reached it.

By creating and reaching smaller goals more often, you’ll feel like you’re making progress.

Keep a journal of your progress

Even if you set your own goals, it can be difficult to remember everything. You may have started with the intention of completing one thing, and got sidetracked and ended up learning or doing something else (this happens to me all the time!).

A good way to keep track of your progress is to write everything down in a journal. At the start of your week, day or whatever it may be, write down the goal you plan to achieve. When you’ve met that goal, write it down, along with any notes that spring to mind that you want to remember. Didn’t meet the goal? No problem, write down why — whether it be distractions, doing something else that seemed more interesting, needed a break, and so on.

If you’re ever feeling defeated, look into your journal of wins — you’ll be surprised at how far you have come!

Look back at your early projects

Another great approach to seeing how far you have come is to look at your early code exercises and projects. This is your paper trail of progression, whether it was your very first HTML page, your first “Hello World” app or your first TODO app.

You might look back and think, “Oh I remember that it took me forever to figure out how to add those check-boxes! Now I can do it with my eyes closed”.

So put everything you do onto GitHub, or keep it saved on your computer. No matter how small it is, it was a part of your journey, and it’s important to remember.

Join the community

There is no better community than the web development community. From the open source software to the free resources to learning to code, it really is great to be a part of.

I wish I had gotten involved with the community earlier — it would have made the difficult parts of my web development journey a lot easier.

Why? Because of the support. There are many great communities from freeCodeCamp and CodeNewbie, to Subreddit and Twitter groups that are built to support fellow coders.

I highly recommend getting involved in these communities. Share what you’re doing, see what other people are doing, and get involved in the discussions. It’s a great motivator when you get a few likes, thanks or replies to a post you’ve made.

Work hard, and don’t give up

As I said in the beginning, coding is hard. Continue to put in the work, celebrate the wins when you get them, and don’t give up. It’ll be worth it in the end! In the words of Nelson Mandela:

Everything seems impossible before its done.

Thanks for reading!

I’m currently creating a bunch of guides, articles, and video courses to help you along your journey into web development. If you would like to be a part of it, make sure to join the mailing list over at chrisblakely.dev!

These books “are basically cheat codes” for leveling up your skills and knowledge as a developer.

Whether you’re a new developer or you’re fairly experienced as a programmer, you’ll come to realize that the amount of time you’ve worked at a job isn’t the best way to determine your skill and knowledge as a programmer (I know, tell that to the recruiters ?).

What you do in your spare time and how you choose to take learning into your own hands is what’s going to ultimately determine your success in this industry. That’s why it’s so important for us as developers to adopt a growth mindset.

There are some excellent ways to learn and improve as a developer. Some of those ways are pair-programming, online courses, meetups, work experience, building projects and finding a mentor.

One of my personal favorite ways to learn is to crack open a well-written book and try to absorb something from those who have distilled years of knowledge and insight into a permanent artifact.

Here are my personal recommendations that I think all developers (especially junior ones) should read at some point. These books are all highly regarded by professionals in our industry and have the potential to leave a profound impact on the quality of your work and your speed of development & learning.

Some of them stray from the technical details and focus more on giving you practical rules about what it means to be a good developer on the interpersonal and professional level.

Disclosure: Some of the links below are affiliate links. But, I’ve only added those books that I personally feel are useful for a junior dev.

1. Clean Code

by Robert C. Martin (Uncle Bob)

After you overcome the basic challenges of development and get comfortable figuring out how to write code to solve problems, it’d be a good idea to take a look at this book. It turns out that making the code work the first time is actually the easy part. The hard part is making your code read well so that others are able to understand it and change it in the future.

Remember the last time you had to read code like this?

function calculateIt (a, b) {
 if (a.delta < b.element.x) {
   var x = b.element.x;
   return x - b.delta.x
 } else {
   var y = b.next.y;
   var h = b.element.y * 2;
   return y - h
 }
}

Who knows what it really does. Code like this might work, but the moment we need to change it, we have to hope the author of the code is still in the company and pray that they are somehow able to decipher what they wrote potentially years ago.

When careful attention isn’t taken to write code that’s readable and maintainable, we end up with pockets of code like this that everyone is afraid to touch, and if it ever breaks, we’re in trouble.

Uncle Bob’s “Clean Code” teaches you how to identify what clean code looks like compared to bad code, and it teaches you how to transform it into good code. A task like this sounds trivial to most, but you’d be surprised at how turning a just a few clean software design principles into habits can help you write much more professional and scalable code.

We’re software craftspeople, you know. Building a house is not much different than building an application in principle. We need to pay attention to the details or else it can all become very expensive to fix in the future if not done right first time.

2. The Clean Coder

by Robert C. Martin (Uncle Bob)

This book is not necessarily a technical book as it is a book for teaching you how to be a professional in this industry. Professionals are those who, when faced with challenges, uncertainty and pressure, will continue to treat creating software as a craft and will be determined to adhere to their professional values.

The Clean Coder is full of practical advice on estimation, refactoring, testing, dealing with conflict, schedules, avoiding burnout, and much more. Trusted advice from someone who has spent decades doing this stuff.

One of the best things it teaches, is how to have integrity as a developer, when to say “No” and how to say it.

A book about professionalism.

3. Refactoring

by Martin Fowler

Martin Fowler is one of my favorite authors. The first reason is that he’s hilarious. His approach to writing software books is unmistakably “Fowler”. The other reason is that he’s incredibly good at explaining complex topics, and doing so very simply, in a way that doesn’t fatigue you as a reader.

Refactoring is a book that the creator of Ruby on Rails once said that you should “read before you write another line of code”. Fowler guides you through refactoring a simple application, introducing you to a number of techniques that he’s accumulated and cataloged over his years of consulting.

Fowler shows you how to flip between coding and refactoring, how often you should be committing your code and when you should be writing your tests. Highly recommended. The latest version of this book was updated to present the examples in JavaScript, which was an added plus for me since it’s my favorite language.

4. Design Patterns: Elements of Reusable Object-Oriented Software

by Erich Gamma, Richard Helm, Ralph Johnson, & John Vlissides

This is the seminal book on Design Patterns. What are design patterns, you ask? Design Patterns are well-known solutions to commonly occurring problems in software development. If you’re familiar with the patterns, you’ll find that you’ll be able to greatly reduce the amount of time it takes you to put forth the solutions to those problems.

Having a good awareness of design patterns also allows you to communicate your solutions effectively with other developers.

“Yeah, I just used a Facade overtop of whichever database Adapter gets loaded from the Strategy.”

“Ahh! Gotcha.”

Yeah, it’s an older book. But it’s still one of the best for reference. If you’d like something on this topic that’s a bit more recent and friendly, I’d also recommend the good “Head First Design Patterns: A Brain-Friendly Guide” by Eric Freeman.

5. Domain-Driven Design: Tackling Complexity in the Heart of Software

by Eric Evans

In order for large code bases to continue to scale, we need to logically split up code into different parts. The idea is to partition your code in a way such that it would be possible for separate teams to work on those parts of your system without affecting anyone else.

The underlying concept that enables moving your code base in this direction is Domain-Driven Design (DDD). It’s an approach to software development where we model the problems that exist in the “problem domain” (the real world) to a number of solution domains.

DDD is incredibly important when a code base gets sufficiently large. Large enterprise companies employ DDD in order to assign teams to parts of the company’s code base.

Eric Evan’s coined the term “Ubiquitous Language”, which is the term for building a common, all-encompassing language between the developers, the domain experts and any other users or actors in the domain. By using this Ubiquitous Language, it ensures that the most important domain concepts are well understood and get modeled in the software.

The book is a little more technical and challenging than the others, but if you get familiar with these concepts, you’ll be very well off in understanding how today’s largest companies keep their code bases manageable and scalable.

Update: April 17th, 2019

I’ve thought about this recommendation a little bit. Introduction to the DDD world is, in my opinion, extremely beneficial for Junior Developers. I believe this to be true because DDD places importance on familiarity with software architecture, design principles and design patterns. It’s a great way to practically introduce yourself to a higher level of programming.

That said, DDD is a large and challenging topic. For some readers, this book (the seminal “blue book”) by Eric Evans might be better treated as a reference. It was Eric Evans who wrote the first book on DDD.

However, I just recently finished reading DDD Distilled by Vaughn Vernon. It’s a really short and sweet intro to DDD, written in order to address the fact that most books on DDD are huge in size.

Definitely try DDD Distilled instead. I think this book would be a lot better for most developers in order to get ramped up on the DDD essentials first. For more practical details on how to implement the concepts, refer back to “the blue book” and “the red book”.

6. Soft Skills: The Software Developer’s Life Manual

by John Sonmez

We should strive to stay well-balanced as a software developer. Unfortunately, being well-balanced is not a trait that most people affiliate with software developers. The truth is, it’s incredibly important to invest in your learning, health and overall well-being as a developer.

“Soft skills” is about the important stuff that matters outside of actually coding, like productivity, career goals and personal finance. Sonmez also goes into investing, how he retired at 33, fitness hacking tips and maintaining relationships - things rarely addressed in the programming community.

It’s written in such a way that you can jump into the book at whichever chapter you think is most relevant to you today.

7. Clean Architecture

by Robert C. Martin (Uncle Bob)

What? Uncle Bob writes good books, ok?

In school, there’s a lot of focus on algorithms and less focus on software design principles. I think it’s kind of unfortunate because in reality, you don’t encounter that many algorithm challenges too often. Instead, it’s more common that you’ll be faced with the challenge of structuring your code in a way that’s modular, flexible, readable and will allow you to add new features quickly when requirements change.

Clean Architecture is about the essential software design principles and patterns that you’ll be able to use in order to face these challenges.

Some of the best takeaways from this book are the cost of dependencies, stable vs. non-stable code and the SOLID principles: a way to write code so that it’s more understandable, flexible and maintainable.

Other aspects of this book that were incredibly useful were concepts of “screaming architecture” and “packaging by component” which are opinions on how to organize your modules so that it practically screams to the reader exactly what the project is all about.

This book goes well hand-in-hand with Domain-Driven Design, which is enabled through the use of a “Layered Architecture” or as Uncle Bob calls it, “The Clean Architecture” (also known as Ports and Adapters). A great book for anyone who wants to up their architecture chops and learn how to effectively design a system at a high level, and do the dance of dependencies at the detail level.

8. The Effective Engineer

by Edmond Lau

Time is our single most valuable asset in life, and we should aim to be more efficient with it. It’s easy to get bogged down and spend a lot of time fixing bugs and wasting effort. Doing repeated work. Bleh. The Effective Engineer is all about getting more done in less time and removing repeated work.

We can mitigate wasted time and effort on repetitive tasks through a framework called “leverage”.

Leverage helps you identify the activities that you can do that produce the most disproportionate results- per unit of time invested. It’s a framework that can apply to anything, whether that be how you learn, how you code, how you debug… anything!

9. The Pragmatic Programmer

by Andrew Hunt & David Thomas

Praised for being easy to follow and understand, The Pragmatic Programmer is a book that should be on the desktop of developers of all levels. Andrew and David are programmers that not only spent many years doing what they do, but paying attention to what they were doing as they were doing it, and then trying to determine if they could do that better.

What came out of their years of introspection was this book, which introduces a number of essential programmer philosophies to follow throughout your career, like “programmers should have a “do it once, or automate” philosophy”.

It includes simple yet detailed advice that you should carry with you in the back of your mind before you write another line of code or start a new project.

Final Words

Books really are some of the best tools to improve your knowledge and skills as a new programmer or Junior Developer. Books tend to have a really high return on investment; did you know you can make a lot of money programming? ?

These are just a few of the best books out there right now in 2019! None of them are really new, but that’s because programming has maintained the same general philosophies and best practices for years. As a professor I once had to say, “you can make a lot of money in this industry, you just have to read the damn manual”.

Have you read any of these books? What did you think? Any books not on this list that you think newer developers would really benefit from reading? Let us know in the comments!

Additional Resources

Here’s a list of some really excellent articles that cover some of the topics from these books. If you don’t quite have the time to invest in fully blown books right now, familiarizing yourself with these concepts might assist you in your journey to become a better developer!

Surviving Your First Junior Developer Job [Guide] ??
https://univjobs.ca/blog/developer-guides/ultimate-guide-for-first-junior-developer-job-success/

Refactoring.guru
https://refactoring.guru/

SOLID Design Principles
https://stackify.com/solid-design-principles/

DRY (Don’t Repeat Yourself)
https://en.wikipedia.org/wiki/Don%27t_repeat_yourself

NodeJS and Good Practices
https://blog.codeminer42.com/nodejs-and-good-practices-354e7d76362

Implementing the SOLID and the onion architecture in Node.js
https://dev.to/remojansen/implementing-the-onion-architecture-in-nodejs-with-typescript-and-inversifyjs-10ad

Better Software Design with Clean Architecture
https://fullstackmark.com/post/11/better-software-design-with-clean-architecture

The Clean Architecture
http://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html

My upcoming free resource, an introduction to software architecture and design principles with Node.js and TypeScript

https://khalilstemmler.com/resources/solid-nodejs-architecture

Keep growing, and have fun while you’re at it!

If you’re a Canadian student or recent-grad looking for entry-level developer opportunities or co-ops/internships, you should check out our platform, Univjobs. We only post jobs specifically for students and recent-grads.