How I hired developers

My fellow entrepreneurs regularly ask me how I found the developers I worked with. So, it might be time to write this down.

If you are in a hurry, here is a summary of my advice.

Cast a wide net and give small tasks to great communicators that have side projects.

My ideal developer

First, I feel the need to describe the type of developer I enjoyed working with the most. You and your situation might be different.

I often felt that we didn’t have enough developers to work on our backlog and feature ideas. But later, I realized that, in many cases, more developers would have actually hindered our workflow.

Even the rudimentary development workflow needs some kind of project manager who keeps it all together, defines project scopes, and maybe does some testing. This could be one person or multiple people, and the more developers you have, the more project management and meta tasks are needed.

The challenge is to find a good balance between developer resources and adjacent tasks.

Another realization of mine, which may be because of my personality, or the nature of my rather small companies with up to a dozen colleagues, is that I needed developers who can do and want to do as many tasks independently as possible. E.g., defining the elements of a task, testing, presenting the results, coming up with dependency problems., etc.

In essence, I needed people who were curious about the tasks and logical thinkers. Such a mindset normally comes naturally and cannot be trained. The development skill level itself was only a secondary requirement. If they were curious and motivated, they would learn what was needed.

Hire great writers

I don’t know who could be quoted for this, but I read this sentence early in my hiring career, and it has proven multiple times – for me.

The developers I enjoyed working with were great communicators. They could explain things logically, work with less technical team members, and are proactive about communication in general. Maybe I am biased here since I think about myself falling into this category. My bachelor’s degree in communication science might have helped with this.

Advice: Find motivated communicators!

Learning what to expect from a future colleague takes some time and self-reflection. Part of that is also to learn where you can and want to make compromises and where you can’t.

In my case, I have always been flexible about work time as long as there is some overlapping time for personal communication, and it is transparent to the team when someone is generally available.

I once had to part with a great team member regarding communication and skills because he couldn’t be available regularly due to other commitments. It was the time were we were all hands on deck in support.

Sometimes, my flexibility helped us hire someone great despite them having better (paid) opportunities somewhere else.

Advice: Put all expectations on the table, and don’t compromise where you shouldn’t!

Learning about the other person’s motivations helps a lot, too. While our office was located in a smaller town, there was no larger pool of talent, but there also weren’t many opportunities. So people tended to sacrifice career and payment opportunities elsewhere for a chance to stay locally, with flexible work time to care for their loved ones, and peers to work with.

Great developers are busy

Another learning of mine was that great developers are usually busy.

I still received applications through our job openings and found great developers through them. But this was the exception, and so rare that it wouldn’t scale in times when I needed to find new developers.

I found that the type of developer I was looking for, especially those with years of experience with individual clients and agencies, have similar requirements to a future employer. They are looking for great communicators and people who proactively work with them and “get them”.

Their risk of starting a relationship with a new client or employer is perceived as big as your risk of hiring a new developer.

So, testing the waters with some small tasks ended up being my (no longer) secret when starting with new developers.

These tasks were sometimes from our backlog, something that showed that they understood the task at hand and its potential implications. It also needed to be something they could work on without reading hours in our code, or having to install many dependencies.

Still, the task needed to have some open questions either in the briefing or in alternative solutions since I wanted to see how they handled those. I don’t have a template for this, but usually find out after a few calls or emails if someone has the motivation and communication style I want to work with.

I didn’t continue working with many highly skilled developers because they lacked the needed communication style. This is hard to do in times when you are in need of a developer. But I regretted every time I ignored this rule and hired someone despite my gut feeling.

Advice: Start with small tasks!

When hiring full-time

You can also apply my advice of starting with a small task when you hire full-time. If the candidate is not motivated to spend a few hours learning about your tasks and doing a test job, they might not be motivated to work for you at all.

If someone does want to get hired for a full-time position, but not invest into it, there is usually something wrong.

I was always open to giving freelancers a small paid test project to test them, rather than doing countless interviews since the first seemed quicker and resulted in more realistic decisions.

When hiring someone as an employee, I took more precautions, since the investment on both ends was bigger. In addition to interviews, I was looking into anything they did on the side, where they showed dedication and motivation to learn and build something new without someone asking them. This could be a (web) app they’ve built or some commercial project they were running on the side.

This actually was a bonus in all my hires. I even encouraged people to keep their side business.

Advice: Hire someone with side projects!

Where I found developers

I was, often unintentionally, casting a wide net that helped me find great colleagues over time.

Long-term: build relations

I hired some people after knowing them for years through conferences or my social network. While that was not the ultimate goal of building networks, it definitely helped.

In the WordPress space, it helps to go to local meetups or WordCamps. If you are like me and socializing doesn’t come naturally, then do one of the following to increase your chances of learning to know people:

  • apply as volunteer
  • apply as speaker
  • go to the Contributor Day
  • go to the social events surrounding the camps

Eventually, you might know how to build a network that you can use when you need a developer.

Mid-term: make job offers public

As mentioned earlier, I kept job offers visible online all the time. Occasionally, we found great colleagues through that, when they were looking for new jobs and gigs. Even great employed developers have moments when they browse for new opportunities.

I usually kept the job offers in multiple places, especially:

  • our own homepage
  • the local employment agency
  • popular job platforms
  • professional online networks like LinkedIn
  • local craigslist

I made it a regular task to review and update these listings. Some of them would look outdated and no one would apply if they became too old.

I found employees through all these platforms, though the majority of my developers came through proactive outreach through my network and short-term job postings on outsourcing platforms.

For local non-developers, our German craigslist-alternative proved to be the best platform, with few, but highly qualified applicants.

Short-term: outsourcing platforms

Outsourcing platforms like Upwork have helped me refine my hiring strategy. Over the years, I hired dozens of freelancers for small projects with the ultimate goal of finding the few gems I wanted to work with for longer.

The two freelancers who have been with me through almost the whole time I ran Advanced Ads came through Upwork. I have seen them grow their skills and help us build powerful features over the years.

Since we started working together early in their careers and built a great relationship, their rates were significantly lower than for potential new hires, too.

My strategy of finding talent by focusing on great and motivated communicators and allowing them to test the waters with smaller tasks, helped a lot here.

This is my basic template for finding talent on outsourcing platforms:

  1. Define a task that would take 1-2 hours to complete. Something you know the result of, but also something creative.
  2. Post the job on a platform.
  3. Set a realistic price.
  4. Increase the number of applicants with direct invites.
  5. Don’t bother with applicants that send a cover letter. I personally also exclude agencies.
  6. Hire up to three candidates (and pay them if they fulfill the task).
  7. Make a decision.

If I had bigger tasks, I offered a paid test job. I never expected unpaid tests. The truth was, though, that I never paid three candidates, since there was always at least one of them who eventually bailed or didn’t deliver anything.

I think hiring multiple candidates eventually helped me the most since it is easier to compare their results and styles. Very often, I even ended up not hiring anyone for more work.

I often ran this strategy even when I did not need to find talent since I knew I might not find it if needed. But there were always enough tasks to onboard someone when I did.

Advice: Make it a habit to find new talent!

Talking about short-term strategies, I also reached out to potential candidates on professional online networks in our region directly. As mentioned earlier, people who stay in our region normally have a personal reason for it. I found that they appreciated the personal outreach from a local company, though I eventually never hired someone through that method.