You've been diligent.

You've spent a few months (or years) grinding out code in your spare time. Dozens upon dozens of brain-melting hours doing coding problems.

It's finally time to take the first steps to your new life as a Software Developer.

You prepare your resumé, and make some applications. No responses. That's okay. You keep trying "It's a numbers game", you tell yourself. You send in a few more.

Silence.

Dozens of applications turns into hundreds. It feels hopeless. You'd be lucky to get an interview let alone a job.

Typically when debugging the interview process, it looks like this:

• If you aren't getting interviews, there's something wrong with your resumé
• If you're getting lots of interviews, but no jobs, then there's something wrong with how you're interviewing
• If you're getting lots of jobs, shut up and stop complaining.

You're caught at option 1.

You made a mistake with your Resumé - and it was you didn't show your greatest strength as a self-taught developer: your ability to learn and grow.

What the employer is looking for

When you're tailoring your job applications, you should always ask yourself this question: what is the employer looking for?

Postings listing "Junior" or "Entry Level" can mean companies are looking to hire anything from an experienced developer (with a deflated salary), to a true beginner they can mold and grow.

You aren't in the first category (and you don't want to be), so you really want to go all-in on the second: employers looking for someone to grow.

Notice here that the focus isn't on your current ability as a Software Developer. Truthfully, it's not nearly as important as how easy you are to work with, and your ability to learn.

We want Juniors to have some coding ability, but it's not what's going to make you stand out. Everyone applying for the job has coding ability. You need to show that you're able to learn new things effectively.

Getting your Portfolio ready

You need some kind of portfolio.

You do not need to build a portfolio site. Please.

Building a portfolio site is a waste of your time and effort. It doesn't provide nearly as much benefit as smaller and more varied projects.

Instead, you should use GitHub. You'll need to learn the basics of git, but that's a plus. Every tech job uses git, and being able to use it will be a big plus over any candidate that can't.

The other secret here is that your portfolio doesn't need to be full of big, impressive projects.

Remember: you aren't trying to show that you're an impressive coder. Your primary goal is to show your ability to learn and grow.

You want your portfolio to tell a story that shows your growth as a developer.

1. Projects don't all need to be complete. It's okay to leave some half-baked stuff up, so long as you made progress on the learning goal.
2. Projects don't need to be useful. It's enough that the project was an opportunity for you to play with a particular technology/way of doing things.
3. Projects should all include a README.md file at the top level. Write a few words about what you were trying to learn from the project and any challenges you faced. This will be seen by employers looking through your projects.

You may think that you don't have enough projects, and that might even be true. You may need to do a few more practice projects to flesh things out.

However, since we're not trying to blow the recruiter's mind with our coding awesomeness, it's okay to blow the dust off bits of older code. It may not be as good as your recent stuff, but it's all part of your growth story.

Caveat: Be careful including cookie-cutter projects from YouTube or online courses. Everyone includes these, and the recruiter has seen them thousands of times. Your goal is to show growth, and it's hard to say how much of the resulting code was you.

How to tailor your resume

Employment has lots of local practices and expectations. If anything here contradicts local standards, your local standards win.

Dealing with a lack of experience

Recruiters are busy people. Usually, your resumé only has around a minute with a recruiter before they decide on the future of your application.

This makes it very important that you front-load any important information for your application.

Normally when applying for a new job, this would be any relevant job experience or qualifications, however as a self-taught dev you don't have these luxuries. Instead, dedicate the majority of your resumé to your projects.

Now, you don't want to put every project you've ever done on there, but you want to call attention to 3-5 stand-outs from your portfolio. These don't need to be impressive, but they should be relatively complete.

For each project, you want to include a short summary with the following information:

• Why you did the project. This should ideally be what you hoped to learn, but can also be some problem that you wanted to solve
• Challenges you had to overcome, especially if they were unexpected.
• When you did the project. This isn't super important, but it can help recruiters and hiring managers build a timeline of your development.
• What technologies you used. Recruiters tend to be keyword-oriented, so listing specific tech can be very beneficial.

If you're stuck with between choosing different projects to include, err on the side of the ones that relate to the role you're applying for. Front-end roles should include mainly front-end projects and technologies, etc.

Addressing automated filtering

Modern hiring practices often (but not always) put your resumé through an automated filter. You may get rejected before it's ever looked at by a human.

To combat this, you're going to introduce a "Skills/Technologies" section to your resumé. In it, list out keywords for every technology you've ever worked with. It can pay to make groups like "Confident" or "Skilled", vs "Familiar" to show your relative strengths.

The result should be a list like "JavaScript", "React", "Vue", "Angular" "HTML/CSS", "Front-end", "Express", "git", "OOP". Really just anything and everything you've done.

This list will help hit the keywords the automated filter looks for. It also helps you with human recruiters, who tend to be keyword-oriented when looking at resumés.

Fair warning: anything you put in this list is fair game to be talked about in an interview. Don't misrepresent your capabilities, and don't put anything on the list you wouldn't be comfortable talking about to at least a cursory depth.

How to present your work history

If you don't want to look like you're applying for your first job ever, it might pay to put the tiniest of something about your work history.

Typically however, this is not going to be important so you want to keep information to the bare minimum: Where you worked, your job title, and dates of employment.

The exception to this is if you've worked in the same (or an adjacent) industry as the company you're applying for.

Domain knowledge is very helpful in software engineering and might give you a leg up in your application. I once lost out at a financial services app to someone who was less qualified but had accounting experience.

Preparing for interviews

The majority of your interviews are going to be simple discussions with recruiters, managers etc.

At some point though, you're going to get a technical interview. These can range from take-home projects, to an engineer talking to you about your projects. More likely it's going to be a coding interview.

In these interviews, you'll sit with one or two engineers who work with you on a problem. You'll be the one in control, and leading the discussion and problem solving.

The problem will be straightforward, but may contain one or two gotchas that you should be looking out for.

The goal for the interviewers isn't to see what code you write, it's to determine how you work and how easy you'd be to grow. Don't feel stressed over what you actually produce.

So here's my big advice for coding interviews:

• Your interviewer is a resource. Ask for clarification, or help on a particular point. They probably won't give you the answer but they might help point you in the right direction.
• Similarly, listen to your interviewer. If they call your attention to something, or ask a question they might be providing you with a hint.
• Talk out loud. Explain what you're thinking, and why you're doing things in a particular way. This is what the interviewer actually wants to know, so hand it to them on a silver platter.
• Code the stupid way first, then improve it. Don't add additional hurdles for yourself by making your code complicated from the start. Add them once you've already shown you can solve the problem.
• When you have a solution, look for reasons your code wouldn't work. Would any inputs break your code? Are there any bugs you can see? You don't need to fix these problems, but showing your interviewer than you have an awareness of them is a big plus.

Should you do HackerRank or LeetCode problems to practice?

The short answer is No.

The long answer is No, but if you want to it doesn't hurt.

HackerRank/LeetCode is a really great way to practice code efficiency and learn how to solve abstract problems.

In practice, the industry has worked out that being able to do abstract problems is a poor indicator of how someone performs in a software development team.

You might get a HackerRank-esque coding problem in an interview. Practice some if you like, but I'd argue that it's not an effective use of your time.

Instead, dedicate that time to fleshing out your portfolio, and working on more and more practice projects.