Stop Letting the Job Description Reject You Before the Company Does

BridgeTech • ISSUE 002

Do you think job descriptions are written to deceive you?

That every company posting a role is asking for the perfect candidate who checks every single box?

Maybe not. But sometimes we read them like they are.

When I was first trying to break into tech, I never let a job description stop me from applying and I didn’t have the luxury of being choosy.

I had to be delusional because, honestly, I was desperate. I needed something to give. I needed an opportunity.

I knew I couldn’t sit there waiting for a job description that perfectly matched where I had already been.

So when I looked at roles, I wasn’t asking myself, “Have I had this exact job before?”

Most of the time, the answer would’ve been no. So I had to find the connections.

What in this role looked familiar to me?

Which skills had I already learned or used that translated to what they were asking for?

Different title, different industry, whatever.

If I could connect what I had done before to the work in front of me, then I knew I had something to work with.

Little did I know, that small shift in thought would shape how I looked for every opportunity that came after.

The titles didn’t always match, but the work underneath them did.

And that was my introduction to the term transferable skills — a term it took me two years of grinding to even learn existed lol.

When I went from the credit union, to one of the largest pharmaceutical companies in the country, and eventually to LinkedIn & Google, I discovered something:

Your next opportunity can begin where your imagination ends.

Everything I had learned dealing with customers eventually helped me land a Customer Success Analyst contract at LinkedIn — my first analyst role.

When that happened, it felt like a whole new world opened up.

Like I had somehow discovered that anything was possible if you focused on it enough.

But eventually I realized there was actually a method to what I had been doing.

I was strategically job hopping, and in order to keep doing that, I had to get better at understanding what companies were actually looking for.

I stopped reading job descriptions by the nouns.

The title. The industry. The degree. The years of experience.

Those were the things that told me what box the company expected somebody to fit into.

But I never really looked at those things and thought, “I’m unqualified.”

I thought, “They just don’t see what I bring yet.”

And to me, that became my responsibility.

If my experience wasn’t obvious on paper, I had to make the connection obvious.

I had to understand the language they were using, figure out where my experience matched it, and then be able to explain why that experience mattered.

So instead of only reading the nouns, I started paying attention to the verbs.

What was the job actually asking somebody to do?

Analyze. Improve. Present. Solve. Coordinate. Build.

Words matter.

If I could understand exactly what they were asking for, I could start figuring out where I had already done some version of it before.

That’s when the job description started feeling less like a test and more like a puzzle.

What pieces do I already have?

Which ones fit somewhere else?

And which pieces am I actually missing?

Take a line like:

Sounds like a lot.

But strip the language down.

Work with different teams. Figure out what people need. Look at information. Find what isn’t working. Recommend something better.

Now I have something I can compare my experience against.

Maybe I’ve already done that.

Maybe I’ve done something similar in a completely different environment.

Or maybe there’s a part of it I genuinely don’t know how to do yet.

And that distinction matters.

Transferable skills were never about convincing myself I was qualified for everything.

Sometimes the gap was real.

Maybe I needed SQL. Maybe I needed stronger technical knowledge. Maybe I needed a project that proved I could actually do the work.

But there’s a huge difference between having a gap and believing you are the gap.

That’s why, when I look at a role now, I’m really sorting it into three buckets:

That last bucket didn’t mean I stopped applying.

A lot of the time, it became my learning plan.

If I kept seeing SQL in the roles I wanted, I started learning SQL. If a certain tool or skill kept showing up, I started figuring out how to learn that too.

And once I was actively learning something, I would add it to my resume as something I was building toward and tailor my learning around where I was trying to go.

I wasn’t replacing the experience I already had.

I was stacking on top of it.

The transferable experience was the foundation.

The new skills were the stack.

That’s really how I started looking at job descriptions.

Not as a list telling me why I couldn’t apply.

More like a roadmap showing me what I already had and what I might need to go get next.

If I had most of the puzzle already, I wasn’t going to throw the whole thing away because I was missing a few pieces.

I’d learn the missing skill.

Build the project.

Take the course.

Get more comfortable with the tool.

Whatever made sense for where I was trying to go.

And then I kept moving.

Your next opportunity might not look anything like your last one.

That doesn’t mean you’re starting over.

You might just need to translate what you already have, figure out what’s actually missing, and stack something new on top of it.

See you soon,

Teshawn
Founder, BridgeTech