Two months of LinkedIn posts

A job networking effort

February 20, 2024 · Felipe Vogel · Table of Contents

But first: did it work?
“Reasons to hire me” series
“Job networking for engineers” series

A few months ago I was laid off and learned that job networking is crucial in the 2023-2024 tech job market.

As part of my job networking activities, I posted on LinkedIn every day for two months, minus weekends and holidays. Yes, every day, even though before this job search I’d barely logged in to LinkedIn, and I’d certainly never posted anything.

What, you may ask, did I post?

Content.

That’s right. Pure, unadulterated content. I became a one-person LinkedIn content mill.

But because I do have some self-respect, I adhered to a couple of guidelines:

I hand-wrote my posts in their entirety. I didn’t use AI.
I made each post as meaningful as I could. I avoided writing posts that felt like filler.

I wrote two series of posts, which you can see below: “Reasons to hire me” and “Job networking for engineers”.

I’m sharing them here on my blog because I think I did a good job with them, and I want to save them in a more accessible and navigable form than in LinkedIn.

But first: did it work?

Or in other words, was the effort worthwhile?

I’m really not sure.

I certainly got a lot more profile views, connection requests from strangers, and appearances in search results. But none of these translated into meaningful conversations (i.e., leading to an interview), as far as I know.

Still, I think the effort was worth a try, and at least along the way I got to reflect on my achievements and, conversely, areas where I would still need to improve before I could post “I’m good at X” about them.

On to the posts!

“Reasons to hire me” series

1. You’re looking at it!

I’m adaptable.

I’d never posted on LinkedIn before a couple weeks ago, but guess what? Now I’ll be posting every day.

I’m definitely going out of my comfort zone, but that’s what I do. I’m the kind of person who doesn’t do anything without doing it 100%.

Coming up: more reasons why you should hire me, all the way through February. But hopefully I’ll convince you before then 😉

2. I’m independent

In February 2022 I started my first software engineering job.

By summer I was rolling out major full-stack features with minimal guidance.

The role, the business, and even some of the technology were new to me, but taking the initiative and pushing forward were what I’d already been doing for years.

That’s not to say I’m a lone wolf. I’m a team player, which means asking for help to avoid wasting time (don’t try to be the hero solving everything alone), and keeping an eye out for where I can help others. That’s how teams thrive, and it’s also how how we can help each other thrive individually.

But part of helping the team is doing all I can, and learning all I can, in a self-driven and disciplined way.

This all sounds very abstract and maybe even paradoxical, so next time I’ll share a practical example of being independent while also helping others.

3. I aim to help

Previously I said I’m independent and self-driven, but also a team player.

That’s not a contradiction!

There are lots of ways we can help others better because we’re forging ahead in a self-driven way. Here are two examples.

The first is a common piece of advice among developers. Find some part of the codebase that needs TLC or better understanding. Work on it, and become an expert in it. Eventually you’re the go-to person in that area, even for more senior engineers.

Another example: I document my learning in a way that’s meant to be helpful to other learners.

For a few years now, I’ve been maintaining a road map of resources to learn Ruby and related web development skills.

github.com/fpsvogel/learn-ruby

I still use the list as a guide while I deepen my own skills, but at the same time I try to make the top sections as helpful to beginners as I can.

Right now I’m building a site based on that list, to make it even more approachable.

What about you? What are some ways you’ve made yourself more helpful to colleagues or to the community?

4. I’m a learner

When I taught myself coding a few years ago, boot camp wasn’t an option. I had to keep working to pay the bills.

So in the evenings and on weekends, I studied. I practiced. I eventually built up a portfolio of projects.

Do I wish that I’d had the chance to attend a boot camp?

Not really.

Not only do I enjoy pushing myself to learn, but I’m also good at learning systematically.

In fact, I ended up building my own curriculum of sorts. That’s the “Learn Ruby” list that I shared last week.

You may have noticed that the list is made up mostly of unchecked (not yet done) items. That’s because I’m always adding to the list.

… including additions that should probably be in their own separate lists, such as JavaScript, computer science, and (recently) Haskell.

So I doubt whether I’ll ever completely, 100% “Learn Ruby” 😂

But that thought actually makes me happy.

The learning never ends!

5. I work hard

I know, I know. “Work smarter, not harder.” Laziness is one of the great virtues of a programmer.

And so on.

But I’ll go ahead and say it: I’m a hard worker.

(Cue meme of Michael Scott talking about his weaknesses in an interview: “I work too hard. I care too much. And sometimes I can be too invested in my job.”)

But seriously. I used to be a teacher.

Getting to work before sunrise, grading papers into the wee hours of the morning, managing a classroom of teenagers all day, every day.

When you do that for a while, you get used to hard work.

So it felt like business as usual when I later taught myself coding while working full time. (That was at my next, not-teaching job that was actually 40 hours per week. What, are you crazy? Teachers don’t have time to learn!)

In fact, for the first time in a long time, I was able to get enough sleep, and even found time to read for fun. Imagine that!

I’m never going back now that I’ve tasted the sweetness of not being chronically burnt out and sleep-deprived. But at the same time…

I know how to grit my teeth and work hard.

By the way, remember to show appreciation to the teachers in your life! They have a difficult, underappreciated job.

6. I deliver results

To take a break from my sappy life stories, here’s a measurable achievement from my last job.

I automated the insurance renewal process, reducing by more than half the time it takes the ops team to renew a batch of companies each month.

Previously, renewals were managed by hand across multiple spreadsheets, and multiple forms needed to be filled out in our internal tools.

It was needlessly time-consuming and error-prone.

So in collaboration with a PM and a designer, I built a set of full-stack tools to replace the spreadsheets and forms. What used to be a laborious process can now be done with the press of a single button.

The average time it takes ops to renew one company went from 90 minutes, to less than 45 minutes.

Now the ops team is free to do what humans do best: make high-level decisions. And the business can scale more smoothly, handling more customers without extra burden on the team.

7. I focus on shipping features

“What programming languages should I learn first?”

This classic beginner’s question was on my mind a few years ago at the beginning of my career change.

Full-stack JavaScript would’ve been the default path, but I made a different choice on the back end.

I went with Ruby.

Here’s one reason why:

I wanted to spend as much time as possible building high-quality features, as opposed to worrying about low-level technical decisions at every turn.

The Ruby ecosystem is strong on conventions, which means fewer choices, less decision fatigue, and more time spent shipping features.

Don’t get me wrong. Sometimes it’s worth sweating the technical details, or breaking away from convention to suit the particular needs of a project.

But I think it was partly thanks to this choice that I was so productive even in my first few months as an entry-level developer, not long after learning Rails. I was shipping major features that had clear and measurable business impact.

In the coming years we’ll certainly see an evolution in what it means to be a productive developer, and I aim to stay ahead of that curve.

But right now, Ruby is in that sweet spot for me.

8. I finish what I start

I’m a big believer in hands-on learning.

So back when I was learning the basics of Ruby, I set out to build something as soon as I could.

I built a Ruby gem called Reading. It’s a parser for my plain-text reading list.

Yeah, I knew a niche project like this wouldn’t get any attention. After three years, it has earned all of 4 stars on GitHub 😂

Still, I built it with gusto. In fact, I’ve kept working on it, until finally this summer it was feature-complete.

You can see what it does on my site’s Reading List page.

Also, on my site’s Reading Stats page.

And here’s the GitHub repo.

But why put effort into such an obscure project?

Lots of reasons. I enjoyed it, for one.

But also, I finish what I start.

I try hard not to leave projects half-done, even personal projects.

Why? Because I know that the biggest payoff comes from consistent work on a project.

For example, I learn the most when I commit to a project over time, when I can iteratively improve it.

Of course, in a business context, any number of contingencies can interrupt or kill a project, leaving it unfinished. And yes, low-hanging fruit should be the priority. There’s a lot of truth to the saying “The perfect is the enemy of the good”.

But as far as it’s in my power, and wherever I see the payoff, I’m a completionist.

9. I thoroughly test code

Early in my journey with Ruby, I learned the value of automated tests. It really slowed me down when I had to manually test changes.

Plus, I often forgot exactly how my code behaved, and I had to read through the code again in order to remind myself. Another slowdown.

So it wasn’t long before I embraced testing, and to this day I avoid making any change in code without making sure it’s tested.

Here’s an example of testing in a personal project of mine. That’s in my Reading gem, which parses my plain-text (CSV) reading list. For any non-trivial CSV column, I’ve written out dozens of possible inputs, which are tested against expected parsed data.

Here’s a more conventional set of tests, in the same project.

In my “Learn Ruby” resource list, the biggest sub-section under “Rails basics” is about testing because I think it’s best to learn it early, and learn it thoroughly.

It’s hard to spend too much time on testing.

(Not that it’s impossible to over-test, but we’re more likely to have the opposite problem.)

10. I don’t reinvent the wheel

Recently in a coding exercise for an interview process, I was asked to build a full-stack search feature with auto-suggest or autocomplete. (The requirements were unclear.)

I was given the option of writing a Vue component for the search bar.

I didn’t take up the challenge.

Instead, I used a simple <datalist> HTML tag. It does auto-suggest just fine, while being orders of magnitude simpler than building a custom component.

In a real-life scenario, I would’ve first asked stakeholders for clarification on the requirements. But even if they wanted true autocomplete (something <datalist> doesn’t do), I might have asked if they’d be open to more basic functionality in v1, so that we could ship other (possibly more important) search-related features sooner, and then circle back to fancier autocomplete in v2.

For context, this search feature was rudimentary—it was a coding exercise, after all. Autocomplete would have been the most sophisticated part of it by far. So even some “nice to have” features would probably contribute more to UX, such as highlighting of search terms that are visible in search results. I would tactfully mention these to stakeholders and/or designers for them to consider prioritizing first.

Did part of me want to build a cool Vue component to impress my interviewers?

Sure.

But I ignored that little voice. Instead I thought about what would be the wisest use of time, and what stakeholders might want to consider for the feature to be as useful as possible in its first iteration.

If you’ll allow me to mix metaphors: by using ready-made building blocks where it makes sense, rather than reinventing the wheel every time, we can free up time and creative energy to ship higher-quality features.

11. I invest in fundamental skills

I’ve mentioned my “Learn Ruby” list before.

Confession: about half of it is actually not Ruby.

I just wanted to keep the title short.

I mean, how awkward does this sound? “Learn Ruby, HTML, CSS, JavaScript, SQL, Git, accessibility, how the Internet works, the Unix command line, automated testing, and more!

The “and more!” includes more specific (and even less title-worthy) skills like web components, PostgreSQL performance optimization, and architecture for large Rails apps.

My point is this: I invest in the broad range of fundamentals, so that I have well-rounded technical skills.

Being a second-career developer is no excuse to leave gaps in my abilities.

I could tell myself “I probably won’t need to know much about accessibility” and then move on, but I would be doing a disservice to the users of the products I build, and to myself as a developer.

12. I’m always expanding my horizons

Last time I pointed out how much my “Learn Ruby” list covers besides Ruby.

Some of you may be wondering, “Why not name it ‘Learn Web Development with Ruby’?”

The thing is, the list also ranges beyond the Web—to games and computer science, for example.

It also goes beyond Ruby to other back-end languages.

I can hear you groaning. “Now this is getting out of hand…”

Maybe so. After all, I know the value of focus. Back when I learned Ruby I did nothing else for many months, building stuff in plain Ruby and immersing myself in every nook and cranny of the language. It gave me a fluency that helped immensely when I went on to build Rails apps in my day-to-day.

But by nature, I’m a person who wants to explore new territory and see things from a new angle.

I don’t think that’s a hindrance to productivity, as long as it’s done in moderation.

In fact, I’ve seen plenty of instances where out-of-the-box thinking, which was grounded in diverse technical experiences, led a team to come up with an elegant solution to a thorny problem that could easily have bogged them down for much longer.

Equally important, it’s fun and energizing to expand my horizons. It’s one of the ways that I make sure I take up my work with gusto every day.

On that note, I’m going to take next week off from posting. Happy holidays!

13. I hit the ground running

Happy new year! Speaking of starting well…

In my first month at my previous job, I got a lot done despite it being my first full-time developer job.

I led a discussion on improving our code linting.
I implemented our decisions from that discussion in our Rubocop linting rules and in our developer docs.
I suggested an improvement to the self-serve signup flow, and then implemented the back-end part of the improvements (better data modeling of SIC codes).
Along the way, I extensively cleaned up our SIC code data, fixing incorrect naming and adding missing records.

I did all this before I was assigned my first project.

Onboarding is a great time for pain points to be identified. A new engineer has fresh eyes and hasn’t gotten so used to problems as to stop noticing them.

I was fortunate that my new colleagues agreed and encouraged me to make those improvements!

14. I go for the prize

Six months into my previous job, the engineering department held a Bug Blitz—not in the usual sense of finding bugs, but simply squashing and preventing them. It was a month of focused effort in reducing known tech debt.

To make it more fun, each task was assigned a point value. At the end of the month, points would be tallied and a winner would be declared.

Much was still unfamiliar to me at that point. So I started out with the mindset that if I could learn a new area of the codebase, that would be a win for me.

However, after a couple weeks I noticed I’d racked up quite a few points by tackling a part of the codebase where there was a series of related tasks. (I was improving various background jobs that send medical claims data to our partner organizations, specifically by optimizing their performance and making them automatically retryable.)

Stirred by ambition for the prize (a pair of yellow sneakers), I redoubled my efforts.

But I didn’t lose sight of my real goal of helping out. Now that I had a little expertise in this area of the codebase, I helped colleagues get started working alongside me on the same sort of task.

In the end, I managed to get highest number of points and won my sneakers, which I wore proudly all through the fall and winter.

Shoutout to Nikola Vojvodic, who got me up to speed and reviewed all my PRs that month!

Me wearing yellow prize sneakers

15. I finish the job

After the Bug Blitz was over at my previous job, we engineers switched from the concerted effort to reduce tech debt across the codebase, back to business as usual in our own corners of the codebase.

But things would never be the same for me.

(Fade in orchestral music, rising in a slow crescendo.)

I now had a fledgling expertise in another part of the codebase. I didn’t want it to go to waste.

Plus, not all of the tech debt had been dealt with over there.

So as soon as I found a breather between projects, I went back to tie up loose ends. Then I collaborated with the engineers who work in that area of the codebase to design a generalized solution, reducing code duplication so that we wouldn’t keep having to rewrite largely similar implementations.

The job was done, but it was just the beginning of collaboration outside my team. More on that next time.

16. I avoid silos by collaborating across team boundaries

At my last job, officially I was on the underwriting team, building tools to support the company’s underwriting ops team as we scaled up our business year by year.

However, I was soon collaborating with other teams, to the point that on my self-evaluation in my second six-month review, I had to label my list of achievements by team in order for it to make any sense.

How did I get into working across team boundaries? Here are a few ways:

When my day-to-day work brought me in contact with code in a different part of our app that needed some TLC, and it was simple enough that it didn’t need to be passed off to the team that owned the code, I went ahead and made the change, tagging the appropriate engineers to review the PR. A common example was removing dead code that wasn’t used anymore.
Sometimes a project in my team required coordination with another team, such as collaborating with the infra team to move some of our background jobs to dedicated infrastructure.
Once, the entire engineering team held put projects on hold for a month-long “Bug Blitz”, focusing everyone’s efforts on reducing tech debt across the codebase. This is where I first started diving into code outside of my team’s domain.

Breaking out of my team’s silo gave me a broader knowledge of the codebase, and this was valuable in more than an abstract sense: as my team built more complex dashboards that brought together data from different domains of the app, I was ready thanks to the cross-domain work I’d already done.

17. I foster a culture of learning

Last time I talked about avoiding team-bounded silos. Another way I avoid silos is by nudging engineers to learn together.

At my last job, I created an TIL (Today I Learned) Slack channel for engineers, and I made sure to stay active on it. Other engineers followed suit. I ended up copying a lot of posts from that channel into my personal notes, because they were pure gold.

I also suggested to my manager that we start an engineering book club, which we then did. We read Practical Object-Oriented Design by Sandi Metz, and then we moved on to Refactoring by Martin Fowler.

Wherever I land a job next, you can bet I’ll start an engineering book club if there isn’t one already. (I’m itching to re-read Layered Design for Ruby on Rails Applications with other engineers.)

Learning together with other engineers is not only fun, but it helps everyone level up. Even if you’re a senior engineer and you already know everything in the book under discussion, you might learn something more deeply by explaining it to someone else, or you might learn something new about the codebase that someone brings up in the discussion.

A traditional book club might not work for every team, though. That’s why I want to explore different approaches, like a coding dojo and Samman technical coaching, starting with Emily Bache’s resources on these.

18. I reflect on my learning

Learning is a lot more than ingesting information. Reflecting on it, and sharing it with others, is a big part of learning for me.

That’s why at my last job I started a book club and a TIL (Today I Learned) Slack channel for engineers. I talked about those last time.

My blog is another way I that I share and reflect on my learning: fpsvogel.com/posts.

I’ve been blogging ever since 2020, when I started my career switch into tech. Of course, I didn’t have much expertise back then, but that didn’t matter because the point is to write about what I’m learning, in order to learn it better.

When you can explain something, that’s when you know that you really know it.

In the course of writing a blog post, I often find holes in my knowledge, or I realize there are some things I haven’t yet experimented with that might help me out.

Also, having a blog gives me motivation to keep learning new things. If a couple months pass by and I haven’t written a new blog post, that could be a sign that I’m stuck in a rut and need to learn something new.

(It could also mean that I’m brimming with ideas for a blog post but my seven-month-old baby requires a lot of attention 😂)

“Job networking for engineers” series

1. Cold applications not working out?

I’ve filled out dozens of applications in my current job hunt, and I’ll be honest: it’s been a complete failure. The single positive response I got was from a company where I had a referral from someone I know. I didn’t get the job.

But I’ve made a ton of progress.

How? I’ve seen firsthand that cold applications are ineffective in 2023, at least for non-seniors, and I’ve learned a few other approaches I can take instead.

In the coming weeks, I’ll be sharing those lessons for any of you other lost souls out there who need a “Job Networking 101” as much as I did.

And I still have much to learn, so I look forward to getting feedback from you networking pros, even if it’s something like “Actually, [insert the day’s bit of advice from Felipe] is super obnoxious and I’d immediately block you on LinkedIn if you did that.” 🙈

2. Welcome to hell a job hunt in 2023

Don’t assume that what worked in your last job search will work this time.

Two years ago I had a pretty easy time finding my first software developer job, despite the fact that it was a career switch for me.

Here’s a shocking-in-retrospect quote from my blog describing that job search:

Over two months, I applied to seven companies, most of them startups. I got a first-step interview or recruiter screening at six of those companies, and in five of them I moved forward to next steps.

And those were all cold applications! 😳

Either I was miraculously lucky back then, or the job market is very different now in 2023.

This time around, after weeks of hearing nothing but crickets after submitting applications, it finally dawned on me that I’d need to change my approach. More on that next time.

What about you? Have you run up against a more difficult job market? How have you adjusted course?

3. Set aside your objections to greasing the wheels

Recently, it finally dawned on me that cold applications are often being ignored these days in favor of personal connections.

I was upset at first.

I felt that as a talented and hard-working developer, I shouldn’t have to spend my days smooth-talking strangers on LinkedIn, or asking a friend to ask their friend to ask their cousin for a referral for me.

I felt my merit should stand on its own.

But you know what?

I realized that complaining about it (a) is a waste of time, and (b) showed a lack of empathy on my part.

I mean, what would you do if you were faced with a stack of hundreds of applications, many of them from very talented candidates who just happened to be casualties of this year of layoffs?

The fact is, my application is almost guaranteed to be overlooked among hundreds of others.

However…

When I talk to someone personally, when they hear my name from a colleague, when they see my name in their LinkedIn feed—then, suddenly, I’m top of mind.

I could either ignore this fact, or embrace it.

4. Improve your resume and LinkedIn profile

So, now that I’ve been converted from job networking denial, what advice I would give myself if I could go back in time to the beginning of my job search?

Let’s start with the basics: improving your resume and LinkedIn profile.

I’ve found Taylor Desseyn’s advice to be helpful, e.g. on improving your resume and your LinkedIn profile.

Ask for critiques of your resume, especially from engineering managers that you know, and in any of your communities where you’ve seen helpful resume critiques. For me, that’s been the Ruby on Rails Link community.

If you want to have your resume written for you, I’ve heard Top Resume and Indeed recommended, but I haven’t tried them myself. Teal is another tool I’ve seen mentioned, but have yet to try.

Thoughts? What’s your favorite advice or resource for resume/LinkedIn improvement?

5. Verify your LinkedIn profile

This is another basic first step, just like improving your resume and LinkedIn profile.

I know, it may feel tedious or silly to verify your LinkedIn profile, especially if you’re busy following actual job leads.

But the algorithm likes it.

And the more you appease the algorithm, the more likely it is that you’ll be seen on the platform.

LinkedIn help docs are unfortunately short on details when it comes to explaining the actual effects of verification. But if LinkedIn is anything like other social media platforms, your profile being verified means you’ll appear higher up in search results, and your posts will appear more often in feeds.

A word of warning to those of you who use the Firefox mobile app: you may need to use Chrome for the verification process to work.

6. Keep a programming blog

Blogging is one of my favorite practices as a developer.

It’s a great way to show off your zest for learning, as well as your written communication skills.

At the beginning of a recent interview, the interviewer brought up two of my blog posts that they found interesting, and we talked about them for a bit. That confidence boost was the perfect way to start the interview.

For me, blogging doesn’t feel like a chore at all, because I gain so much from it as a way to reflect on what I’m learning or building.

It’s a nice bonus that other people also benefit from my blog, and occasionally they reach out to let me know.

To start your own blog, you don’t need a complicated setup. You can start by posting on DEV, then build your own site later on if you want to.

The important thing is to start!

Here’s my blog: fpsvogel.com.

I started it back when I started learning to code. That first version of the blog is still up, in all its quirkiness.

7. Do projects

I actually cringed a little bit as I wrote “do projects”.

Usually, this is understood along the lines of “have a bunch of side projects, including one that you’ve turned into a successful startup.”

What I mean is a little different.

Sure, a solo project can be a good way to learn and show off technical skills.

But collaborative projects are important too, because they show that you have more than technical skills.

Some ideas:

Contribute to open source. First Timers Only lists lots of resources for getting started.
If you’re into Ruby, Ruby for Good is a convenient collection of open-source apps to contribute to.
Become a coding mentor at Exercism.

8. Join communities

The more you’re plugged into communities related to your field, the more likely you are to hear about job opportunities, find referrals, etc.

At the very least, you’ll have other job seekers around you that can commiserate with you 😂

If you’re into Ruby, definitely join the Ruby on Rails Link community on Slack.

Find local developer groups on Meetup. Bonus points if there’s a Ruby meetup in your area—and if there’s not, then even more bonus points if you start one!

9. Visit online meetups

In-person meetups are ideal, but these days there are lots that meet online. And there are lots of reasons why you might want to visit them.

In my case, I’m dropping into online Ruby meetups to get ideas for starting a local meetup this year.

And if I get wind of any job opportunities while I’m at it, all the better!

For you Ruby developers who are curious, here are active U.S. Ruby meetups that meet online:

10. Post regularly on LinkedIn

I never would’ve thought I’d post every day on LinkedIn. Then this job search happened.

I feared I might have made a grave mistake when, in my first post, I more or less committed myself to posting every day for three months 😬

But you know what? I haven’t regretted it one bit! Right away it started paying off.

For one thing, I started getting messages from people in my network about job opportunities. My posts are essentially reminders to everyone that I’m looking for work.

Also, writing them out helps me reflect on my strengths and accomplishments, as well as what gaps I need to fill in.

And last but not least, I get a little morale boost from every reaction, and a few times my former co-workers have made my day by commenting with an enthusiastic recommendation of me.

Have I convinced you to start posting regularly?

If so, one thing to keep in mind is that you can schedule posts for later. I write posts for a week or two at a time, and then schedule them.

Another tip: to format text (bold, italics, etc.) you’ll need to use a plain text formatter, such as the one at Taplio.

Happy posting!

11. Interact with other people’s LinkedIn posts

Today’s tip is something I’m terrible at.

Don’t just post on LinkedIn, but also like and comment on other people’s posts—including people you don’t know personally!

This way you can strengthen your existing network and even expand it.

Your feed is a good place to start, but another approach is to search for posts in your sub-field.

For example, here are search results for posts from the past 24 hours for “#ruby #rubyonrails” and for “ruby rails”.

Unfortunately, LinkedIn doesn’t have a “Location” filter for posts. So believe it or not, your feed might be the more worthwhile place to spend time scrolling through.

12. Leverage your existing network

As you hunt around on LinkedIn for people to connect with or to message about job postings, it’s easy to forget one important thing.

Stay in touch or reconnect with people you already know.

To some extent this will happen naturally as you post on LinkedIn, but you can also be proactive:

Message old acquaintances and schoolmates who might know of jobs.
Write former co-workers a LinkedIn recommendation.
Do whatever feels right in each particular relationship!

For the rest of this series, I’ll post about connecting with people you don’t know—not because that’s more important, but because it’s something I didn’t know how to do until recently. Plus, it takes more steps than tapping into your existing network does.

13. Contact a recruiter

Recruiters get a bad rap. I guess it’s because recruiters are among those who send us unsolicited, sometimes scammy emails and LinkedIn messages.

That’s not the kind of recruiter I’m talking about.

I’m talking about recruiters like Brian Mariani at Mirror Placement.

Recently, I googled “Ruby on Rails recruiter”, and Mirror Placement was the top result. I filled out their contact form, and within minutes I’d scheduled a conversation with Brian for the following day.

When I met with Brian, he sent me a job opportunity right off the bat. I interviewed with that company the following week.

At each stage of the interviews, Brian sent me tips about the company as well as information he’d heard from candidates who’d been interviewed there in the past.

Working with Brian was a breath of fresh air. For a job seeker, so many things are more difficult than they should be, and so many people are out to take advantage of you.

But a good recruiter really wants to help you, because your win is their win. In case you didn’t know, recruiters are paid by the companies who hire them to fill a role, once the role is filled. It doesn’t cost you anything.

So there’s no reason not to talk to a good recruiter, or even a few.

(No, Mirror Placement didn’t pay me to write this post. I’ve just really enjoyed working with Brian!)

14. Keep an eye on job postings

At the beginning of this series, I talked about how it’s almost useless to submit cold applications.

So why keep up with job postings, then?

Well, you’ll still need to pursue specific jobs or companies (more on how to do that tomorrow). Job postings are a handy way to find out about them.

Otta is by far my favorite place to keep up with tech job postings.

You should also keep an eye on job boards specific to your field. For example, Ruby developers should watch the GoRails job board and Ruby On Remote.

Over time you’ll get an idea of which companies you want to work for, but you could also take a company-first approach, looking at companies that use the tech that you’re experienced in.

Of the many ways of finding out a company’s tech stack (some more reliable than others), my favorite is a good old list specific to a particular tech. Example: Ruby On Remote’s Companies page, which is conveniently sorted by most recently hiring.

15. Make a connection

So you’ve found a job posting or company that you’re interested in. Like I’ve said before, you shouldn’t send in a cold application, because it’ll almost certainly be ignored.

Instead, start by making a connection.

This means finding someone who can refer you, or at least talking to someone who is involved in hiring.

The end result is that you’ll stand out in the crowd of applicants, and you’ll be much less likely to be overlooked.

So what exactly does it look like to make a connection like this? I’ve written out my process in detail and with examples on my blog.

That blog post also contains the previous material in this series, as well as a bonus section with interview tips that I’ve learned.

The blog post actually has the rest of the content that I was going to post here in daily doses. I’ve decided to make this the last daily post because I recently accepted a job offer 🎉 More on that soon. Thanks for following along!