This is the second half of a better way to sell your skills as a developer than just "hire me!" or mass applying to jobs.

In part one, we went over why the "spray and pray" approach - where you send out hundreds of applications or just announce you're looking for work on Twitter/LinkedIn/etc - is typically a bad strategy.

Bad, because you sell your skills and experience with a totally generic pitch. One in which you end up looking like literally every other developer applying for those same positions.

We also covered how to research companies so that you can arm yourself with the knowledge needed to understand their business problems and technical challenges. Which is crucial in demonstrating to companies that you are exactly the person they need to hire to help solve their challenges.

But how do you actually demonstrate that to companies? How do you take the research and market yourself in a way that enables your potential future company to start seeing you as someone they need to hire?

This is where step two of the process comes in.

And this could honestly be a whole book by itself - marketing your skills as a developer is a massive topic.

But what we'll cover here is taking your research, figuring out how it lines up with the experience you have, and crafting a "pitch".

And the way you get that pitch out there can take many different forms - email, application form, informal coffee with someone who works at the company, etc.

But the form it's in matters less than being able to speak to how you can help a company based on your skills and experience.

Step two, show how you can help solve those problems

1. Match your experience to their problems

Now that you have a list of problems/challenges a company has, the first step in creating a pitch is making a list of your experience and skills that can help solve those problems.

Basically, think of "matching up" your experience with the company's challenges. How could you leverage your skills and experience to help solve their problems?

Obviously this will vary by level of experience, but even people looking for their first developer job can leverage school experience, extracurriculars, practice projects, experience from other careers, etc. You might have to get more creative, but don't count out non-developer experience.

One thing to consider: it can be more helpful to think of yourself as an employee who helps solve problems, and code just happens to be how you do that. And when you think of it this way, if you don't have a lot of developer experience, that starts to matter less and less. As long as you can identify past experience that matches up with what the company needs.

2. Put it into resume format

Whether or not you need a resume for the job you're applying for, I've found it useful to take the list from the previous step and modify your resume to suit.

Not only so you have a better resume, but also because it helps you in creating your "sales pitch".

So if in your research you've found the company you're applying for has had a large increase in users in the last 6 months, and thus has had a heavy hit on performance... and you happen to have experience speeding up API's to shave seconds off response times... on your resume you would put as a bullet:

• Reduced API response times by 35% after getting 50% increase in traffic to core application Remember (for both your resume and your "pitch") it's best to always quantify and/or qualify things.

Think of things in terms of - "Why did what I built matter?". Not "What did I do?" but "Why did I do it? Why did it matter? What outcome did it have?".

For example, don't put:

• Built React application for customers to view and update their orders

DO put:

• Built React order application that resulted in 5% revenue increase and increased customer retention by 4%

And for your resume you don't only have to list things that would help the company. Creating a totally unique resume for each application is a bit of work, after all.

But you do want to definitely use the "why, not what" format for whatever you include. This is because, even if your experience may not be of direct benefit to the company right now, it doesn't mean it won't in the future. And you want them to see that you have a history of solving problems.

If you've done that at other companies, then the hiring manager or whoever is looking over your application, talking to you in person, etc. will more easily be able to see how you could do that at their company.

3. Create a short pitch

Next step is to create a short pitch. I shoot for 1-2 paragraphs, mostly because that feels like it's enough to sell yourself, but not too long that the person on the receiving end loses interest.

And this should actually be pretty easy - all these steps build on one another and this is no different.

Take the bullet points from the resume step above and then choose the ones you think could help with the company's challenges the most. With the resume, you listed out what you've done and most importantly, why those things mattered. And you included things that would help solve the company's (the one you're interested in joining) problems.

With the pitch, you're really just making it a bit more explicit as to how your experience would help the company. If they haven't connected the dots based on your resume, the pitch will connect the dots for them.

Using our example from the resume step above:

• Reduced response times by 35% after getting 50% increase in traffic to core application

Putting this into pitch format becomes something like:

I saw from the recent news section on your website that with your recent product acquisition you've had a large increase in traffic with all the extra customers. This is something I have had a lot of experience with and would love to help out with. At ABC company over the course of 3 months we had a huge increase in traffic, and I was able diagnose bottlenecks and reduce API response times by 35%.

4. Modify the pitch to fit the context

Lastly, it should be obvious but you'll need to modify your pitch a bit to fit whatever context.

If an application requires a cover letter - I put the pitch there. If they don't, I put the pitch in the body of the email and attach the resume.

If it's an online application, I put the pitch in a freeform text box (they usually have these).

If it's an informal coffee chat, meeting up in real life, I just make sure to cover a few things from the pitch but tie it into the conversation naturally, definitely not just blurting out the pitch in one go. Even though I've been calling it a pitch, if you're having a conversation with someone in person, I wouldn't literally state the pitch like you might in a sales meeting or whatever haha.

Like I mentioned at the beginning of this post - the pitch may take many forms given the context, but the key is demonstrating how you can deliver value by aligning your skills and experience with their needs.

A mock example

Let's apply the tactics from above to a mock example - there is an imaginary company (that probably exists, actually) named "Infotech" that we are interested in working for.

After looking through their website and their engineering blog, we've found the following:

• They've had issues scaling due to a large increase in customers, so implemented Redis in the last 3 months for a caching layer and a queue system for processing heavier background jobs
• They have a new product for doctors that automates requests for labs for patients
• One of their big customers is North State Hospital

And here's a list of our skills and experience:

• At CDE software company, implemented a caching layer in Redis (writing a wrapper module that helps clients call into Redis)
• At XYZ healthcare software company, worked closely with Product, UX, and end users to redesign a billing workflow within the iOS app
• One of this company's customers was South State Hospital (a regional competitor)

Fortunately for us, our skills/experience match up quite nicely!

Now, obviously things won't line up so perfectly every time. That's expected.

But with some creative thinking around how you would deliver value, and some creative research, you'd be surprised how often you do have a specific skill or specific experience that would translate to what the company needs (beyond what they simply list in the job description).

Now let's apply the process...

For aligning our resume based on the company's challenges, this is our experience:

• At CDE software company, implemented a caching layer in Redis (writing a wrapper module that helps clients call into Redis)
• At XYZ healthcare Software company, worked closely with Product, UX, and end users to redesign a billing workflow within the iOS app

That's a good start, but let's quantify/qualify it some more. Why does that experience matter, what was the outcome of those projects?

• At CDE software company, implemented a caching layer in Redis (writing a wrapper module that helps clients call into Redis); resulted in speeding up core API responses by 45% due to not having to make round trips each time
• At XYZ healthcare software company, worked closely with Product, UX, and end users to redesign a billing workflow within the iOS app, resulting in 20% less calls to the Customer Support team

That looks much better.

Now, based on what we know about the company, let's create a short pitch. Here's what it might look like (imagine we're emailing our resume and this is the body of the email, excluding the general introductions):

At CDE software company, I implemented a caching layer in Redis that resulted in speeding up core API responses by 45%. While I was working there, we had a huge increase in traffic in a short span of 3 months and really needed to scale up more. I know in the healthcare IT field this is often the case, as I saw from your news section you recently had a large increase in customers (congrats!). Performance and scaling can be painful, but fortunately I've had a lot of experience with it.

Speaking of healthcare IT, I noticed one of your customers is North State Hospital. When I was working at XYZ healthcare software company, one of our customers was actually South State Hospital. I redesigned a core billing workflow for them, which I know is somewhat similar to your new lab request product. I was able to learn a lot from the end users how they work and gain a lot of domain knowledge specific to those workflows that I know I could bring to Infotech.

Thanks for your consideration and I'd love to talk more about how I could leverage my past experience to deliver value at Infotech.

You might write it completely differently, using your own tone, but hopefully this is enough to get the point across.

What if you already have a connection at that company? Do you still need to sell?

If you already have a connection at the company, you'll likely automatically be brought in for an interview (maybe even skipping a few interview steps). But the interview process is still a sales process. It's an even bigger sale than just getting an interview.

With getting an interview, the company has bought your resume/application/whatever - your "pitch" - and they are paying with a 30 minute phone call from HR, an hour or two from one of their developers, etc.

But at the end of the interview process, if they decide to "buy" what you're "selling" there, they'll be paying a developer's salary, for as long as you work there. That's a lot more money.

So this is why I say that even if you don't have to sell your skills and experience initially to get an interview, this same process of - research company to discover their problems/challenges/true needs, then demonstrate how you can help solve those - is highly beneficial no matter what. You'll be using the research you did, the alignment of your experience, and your "pitch" in the interviews anyways!

Wrapping up

The job search process - sending out applications, meeting with current employees in person, etc. - all the way through the interview process requires a sales approach.

And one that seems to all too often be about just listing tech we know and what we've done.

Not quantifying/qualifying the impact that work made, not matching it up against what challenges/needs the company currently has.

But the process outlined here is one that is much more specific and actionable. And I think it puts you in a better spot to be seen as someone that the company needs to hire because they can visualize how you will help them and what problems you will help them with.

Above all, my recommendation is to avoid the spray and pray approach, and think of yourself in terms of the business value you provide.

I think you'll have a much better success rate, avoid the agony of being ignored that comes with the job search, and most importantly get the kinds of jobs that will be a great fit for you and the company.

One more thing

I usually write about JavaScript, Node, and software architecture. But I'm going to start occasionally writing more posts like this. There's a lot of vague career advice out there that is neither specific nor actionable - if you found the process and the steps covered in this post helpful (and you like learning about JavaScript/Node), sign up below to receive all my new posts delivered directly to your inbox without having to remember to check back here.