A few years ago, I started guest lecturing and volunteering at a few of the coding bootcamps here in Chicago. I had a very non-traditional job search process (more on that in a minute), so it was surprising to me that so many new grads had a tough time finding their first roles.

Since then, I’ve realized that job hunting isn’t just hard for new software developers. There are virtually endless threads on Reddit (1, 2, 3, 4) bemoaning the process and how arbitrarily good programmers are rejected without reason after putting dozens of hours into the process.

In short, it’s demoralizing, but I’ve been on both sides of the table.

In my 12+ years in tech, I’ve been a software developer, an engineering manager, a CTO, and a founder. I’ve been in the hiring seat and the job-seeker’s seat at various times, and like many of you, I think most companies’ hiring systems are deeply flawed.

That said, there are ways to navigate it or work around it entirely. As an applicant, understanding how the system works and playing to your strengths can help make it a lot easier on yourself. So, in this piece, I’ll break down the hiring process from an employer’s perspective. I’ll share some of the reasons this process is so annoying (on both sides) and offer my perspective on how both sides can navigate it.

Why Is Job-Hunting So Difficult for Software Engineers? 

There are a number of factors at play in making job-hunting as hard as it is. Here are just a few factors:

1. Oversupply of Junior-Level Developers

Finding your first role is particularly hard for entry-level programmers, since the vast majority of openings are for mid or senior-engineers with 5+ years of experience. But, employers are somewhat justified because junior developers can be a risky bet.

Hiring a new software developer can cost tens of thousands of dollars. Add to that onboarding and training costs — which are significant for someone who’s completely new to the field — and it’s easy to invest $30,000 or more before they’ve added a line of production code.

Now imagine you make a bad hire.

It takes 8.8 weeks to dismiss someone, does damage to the hiring manager’s reputation, hurts morale, and the company has to recruit for that position all over again. Bad hires mean a lot of money and time is wasted, and most employers are extremely risk-averse (read fearful).

As a result, companies tend to be biased toward experienced candidates who are familiar with the language and frameworks they use. They tend to want proven contributors who are used to working in a professional environment and know all the tools of the trade.

I’m not saying this is right, but this is the economic case that any junior applicant is fighting against.

2. Outdated Hiring Practices

A lot of the frustration also stems from the fact that many steps in the process are not relevant to the actual job. Instead of testing for skills and knowledge applicable to their day-to-day work, applicants are made to jump through arbitrary hoops that often leave non-traditional and diverse candidates struggling.

> “But honestly, as an ACTUAL senior software developer, why do I have to brush up on things that don’t come up in the day to day often?” – Anonymous

Applicant Tracking Systems

For starters, ATSs, which are meant to help facilitate the hiring process and save everyone time, can be a huge barrier. Job seekers have to upload their resume and then fill out the exact same information all over again in most ATSs.

What’s more, many recruiters use these systems blindly.

Most ATSs will parse an application for keywords to determine if a candidate is qualified. If somebody wrote into their application that they’ve used Scala before, but they didn’t explicitly write that they’ve used Java, the ATS might tell the recruiter that they don’t know Java. A real engineer would know that the are closely related enough to be interchangeable in many environments, but naive recruiters may not.

This leads candidates to use hacks like (Amit Juneja’s here) to manipulate ATSs to get more positive replies.

While employers might save time using these tools, they’re clearly missing good candidates who just don’t know (or care) enough to game the system correctly.

Whiteboarding Sessions

Termed “whiteboard algorithm hazing” by David Heinemeier Hansson, the creator of Ruby on Rails, whiteboarding is one of the most aggravating experiences for job seekers.

This interview style, which is widely used by tech companies like Google, Facebook, and Amazon, asks candidates to spontaneously regurgitate any one of hundreds of algorithms that were last useful maybe 50 years ago. They’re asked to write out these algorithms on a whiteboard with no access to an IDE or any reference material.

Spoiler alert: this is nothing like the work that real programmers do.

In the job, they’ll get to work on their own computer using reference materials and all sorts of assistive devices. I’d argue that it’s more important that developers know how to actually look things up quickly on Stack Overflow than repeat algorithms by memory, but that’s just me.

Hanssen says as much in his blog: “I’ve known fabulous programmers flame out in the quizzing cage and terrible ones excel. So unless you’re specifically hiring someone to design you the next sorting algorithm, making them do so on the white board is a poor gauge of future success.”

So why do companies default to this method of weeding out applicants?

Some of it is laziness. Many managers do whatever the policy dictates rather than improve the policy. For others, it’s likely a form of elitism or bias. Many companies want to limit their applicant pool to people with more traditional computer science backgrounds rather than those with self-taught or bootcamp experience.

In any case, whiteboarding has forced many applicants to spend months brushing up on arcane programs like maze solving algorithms or the longest possible Collatz sequence, hoping that they get tested on one of those during their interview.

It has also spawned an entire industry of Online Judges — platforms where applicants can solve problems and spend time on coding exercises. LeetCode, HackerRank, and CodeForces are some of the most popular ones out there. It’s a lot like SAT prep for a job, except that you have to go through it again every time you want to change your job.

3. Job-Skills Mismatches

Finally, I see many developers struggling in the job market because they don’t have the right skills. This problem affects new and experienced developers.

For example, if you’re a senior developer who’s built a career working in PHP, but all the best companies are looking for Python or Golang developers, you’re going to have a hard time getting offers.

This goes back to point 1, but companies don’t want to spend money and time cross-training new hires. It’s expensive and risky, so they favor candidates who already have the skills they think their job needs.

The problem is that for many developers with a full-time job, family, and other commitments, it’s very hard to spend time learning a new programming language on the side. Keeping up with all the new technologies in this industry is one of the most common challenges of working in this industry.

So How Do I Get Hired? 

While there are movements being made against some of these arbitrary recruitment practices, many big companies have stuck with them. So in the meantime, how do you get hired and not get discouraged throughout the job hunt?

Here are a few pointers from my experience as a job seeker as well as conversations with fellow engineering managers:

1. Network, Network, Network

If you want to avoid the black hole of online applications, you need to build a network and reach out to people. I spend between four to eight hours every week building and maintaining my network.

Networking got me my first job right out of college and every subsequent job I’ve had since then. 

I started attending conferences and meetups very early in my career. As I began making connections, people started inviting me to speak at meetups and bootcamps, even though I was relatively early in my career.

I even kept track of all the people I met and got in the habit of reaching out to reconnect with them periodically. These efforts helped me avoid much of the chaos of traditional recruitment throughout my career. 

In a recent podcast on this topic I recorded with Taylor Dorsett, Software Engineer at Home Chef, he recommended treating each meeting as a learning process, especially when you’re young. “Can I learn something from this interview? Even if I fail at the coding problem, can I connect with this individual and learn something? [Through this] I actually had really good conversations with people and interacted a lot more afterwards.”

This mirrors my own experience. Even if the people I met weren’t looking to hire at the time, I stayed in touch. When they were hiring, I was the first person they thought of.

Whether you’re an entry-level programmer trying to get a foot in the door or an experienced one trying to find the right role, networking will make it a lot easier on you.

2. Contribute to Open-Source Projects

Another way you can distinguish yourself as a candidate is to get involved in a larger, existing project. There are plenty of open-source projects you can contribute to, and you don’t have to make major updates to help. Even bug fixes and documentation updates are valuable contributions!

As an employer, this practice shows me that you can learn an existing codebase, interact with others remotely, and think critically enough to make updates. Greenfield projects are rare in the real world, so showing that you can play well with an existing codebase is a huge asset.

3. Practice Intentionally

If you want to get hired, you have two options:

One: you can limit your search to companies which don’t have annoyingly arbitrary interview practices. Four Square, for instance, has ditched whiteboard interviews in favor of assignments you can take home. Pivotal Labs offers an engaging paired-programming interview style. Networking can help you connect with managers at a number of these companies, but believe me, there are plenty of them out there.

Two: you can spend a couple of hours every week practicing coding interviews. Doing LeetCode exercises is a grind, but you will get better at them over time. Platforms like AlgoMonster and Educative can also help you learn in a more structured way by understanding the patterns rather than memorizing the answers.

You can also practice with mock interviews. I haven’t used it, but Interviewing.io is a well-respected resource where you can anonymously practice interviews with Facebook and Google engineers.

4. Share What You Know

Finally, if you’re looking to stand out from other candidates and have more opportunities come to you, educating others is a great option.

Writing tutorials, recording YouTube videos, or creating an online course is a great way to build your personal brand and prove that you’re worth hiring. I wrote regularly my whole career as an engineer, and many of the blog posts I wrote led to job offers, consulting work, or new connections. Honestly, it’s why I still write pieces like this one, and it led me to create my current company, Draft.dev.

Sharing your knowledge is a great way to help others while showcasing your skills and building an online presence.

Conclusion

The software development field is still growing exponentially and there’s a significant shortage of qualified talent in the space. 

While job hunting can be a huge pain, this is still a good field to be in. But if you’re picky, you may just have to fight a little longer to find that perfect role. Meeting new people and building a body of work you can showcase is a tried-and-tested hack to stand out as a candidate. 

If you found this article helpful or have thoughts of your own, I’d love to hear them. Leave a comment or find me on Twitter to continue the conversation.