For more than two decades, the vast majority of our new clients have come to us with horror stories about development projects gone awry. Even after a painstaking selection process, they’ve inadvertently hired developers who overpromised and underdelivered, who couldn’t hit deadlines or schedule meetings, and even some who completely disappeared on the day of the big launch.
In this article, we’re sharing the process that we’ve used to build a team of high-end software engineers. We want you to avoid the pitfalls that almost everyone struggles with when they hire developers, so you can skip the sleepless nights and jump right to building a successful web development team.
Hire Before You’re In A Rush
How many web projects will you sign this year? If the answer is more than one, your best move is to start the process of hiring and vetting web developers today, even if you don’t yet have a specific project on the horizon.
The process of hiring a developer is a challenge even in the best of circumstances. It’s much more difficult if you are trying to get it all done with just a few days’ notice after you suddenly receive an exciting request for a proposal from a client. Instead of trying to rapidly source a developer every time a project comes along, start building those relationships today, and it will pay off when your next big opportunity knocks.
Many developers – even those with great technical skills – are not going to be able to keep up with the pace of a typical creative agency right off the bat. They need time to build mutual trust and to get a sense of your needs and goals in terms of turn-around time. You usually can’t drop them right into the thick of things with a tight deadline and expect them to meet fast-paced agency standards.
This is especially true when you’re reaching out as an unknown new client. Remember, from their perspective, it’s unclear how good of a client you are and whether it’s worth it for them to drop everything else and turn around a quote quickly. Particularly if they’re individual contractors, they’re probably juggling sales and business work with deep-focus coding work, which means it’s difficult to quickly switch gears.
If you’re reaching out to a new developer a week before you need to deliver your proposal to your client, you’re setting everyone up for failure. If you get out ahead of your hiring instead, you accomplish two big things:
- You avoid the headache of late estimates; and,
- You show your developer that you are conscientious and on top of your game, which means you’ll be able to attract better developers (including those that are busy!)
At this point in the process of hiring a web developer, you’re the one who’s auditioning for the role of client. You want to demonstrate that you’re going to be an awesome client and that it’s worth putting aside other projects to work with you. Remember that there are a lot of crappy clients out there, and many developers who field a lot of new leads are already on guard and trying to mentally categorize you from the moment of first contact.
If you often find yourself in a position where you have to say, “We need this yesterday,” you’re broadcasting to in-demand developers that you might be a less-than-ideal client. Show them you’re an extraordinary client by giving them plenty of time to get on board before you really need them.
Find the Right Pipeline
Your hiring pipeline is the foundation of your business. For that reason, it’s important to spend a lot of time on this and cultivate a range of different hiring sources that fit your goals.
Once you get good at this, you’ll have a constant flow of new developers to consider working with – and you’ll have enough experience with each different hiring pipeline that the process of posting a project description, choosing a candidate, and onboarding them to your team will become clockwork.
And because your pipeline is the foundation of everything you’re about to build, it’s also where we’ll start talking about hiring for diversity in tech.
You’ve probably read a lot about the dearth of diversity in technology – it’s true for Silicon Valley behemoths and for the vast majority of smaller creative and technology companies, too.
This is a complex problem, so we want to focus on what you can do today to help the tech workplace better reflect the population at large. The first step is expanding your pipeline to include a broader range of candidates.
Many of us – like our first clients – start out by hiring friends of friends. But word-of-mouth has major drawbacks, and a really great connection via a referral should be treated as a pleasant surprise, not your primary method of building your team. (The same is true when finding clients – as anyone whose word-of-mouth leads have dried up overnight knows all too well.)
Word-of-mouth also has the negative side-effect of creating a team where everyone comes from a very similar background or is in a very similar social space, which often detracts from diversity.
Let’s look at three different types of sources you can use to build your pipeline. By combining these, you’ll be able to build a constant flow of talented new candidates and take big steps toward diversifying your team.
The Traditional Source
This includes job-board sites like LinkedIn, AngelList, and Indeed, freelancing sites like Upwork, and newer marketplace-mixed-with-recruiting platforms like Toptal.
The Diversity-in-Tech Source
These organizations specifically advocate for diversity in technology and often have robust job boards or other platforms where you can meet candidates. Examples are Underrepresented in Tech, Women In Technology, She Freelances, Black Tech Pipeline, Resilient Coders, People of Color In Tech, Incluzion, and Apprenti.
The Local-Community Source
These groups often spring up around a meetup or other social events in a particular city, and then grow into places where developers hang out, trade war stories, and learn about new opportunities. Examples in the Denver area are DenverDevs.org and Better Together. You can find these in your local community – or any city, especially if you’re hiring for a remote role.
Write Your Project Description
Let’s dive into a real job description. This is the exact listing we’ve used to hire on all the pipelines we mentioned earlier, including the traditional, diversity-in-tech, and local-community avenues. Let’s break it into a few sections and show you our thought process, and how you can adapt this to your own needs and goals.
Experienced WordPress + Custom PHP Developer for a Steady Stream of Projects
We’re a web development firm seeking a freelance WordPress developer who’s experienced in custom theme and plugin development. You’ll have the opportunity to work on full-build projects as well as custom plugin and theme development for existing sites we manage.
We’re leading with the word Experienced, which indicates that the developer needs to be beyond entry-level. (There’s room for hiring entry-level developers and training them once you grow a bit more, but for your first hires you should aim for someone with more demonstrable hands-on experience.)
Next, we’re calling out our two platform specialties – in this case, WordPress and Custom PHP. This immediately qualifies some people and disqualifies others, like those who specialize in .NET, even though those people may be great developers too.
Finally, the big selling point: a steady stream of projects. Being able to include this in your description (and actually being able to deliver on it) sets you apart from 95 percent of the other potential clients out there, who are often using hiring pipelines for one-off projects and then never talking to the developer again. From a developer’s standpoint, those projects require a ton of sales work and a ton of uncertainty, with a pretty low ceiling on the payoff of a successful project. Being able to honestly say that you could become a paying client for the long-term makes a huge difference in the quality of candidates you’ll attract.
Many of our projects include…
– StudioPress Themes / Genesis Framework
– Custom theme development based on HTML/CSS/JS templates using the Bootstrap framework and jQuery
– Custom plugin development (typically hooking into Genesis, WooCommerce, and other existing plugins/frameworks)
– Custom PHP work with MVC frameworks, including CodeIgniter and Laravel. We’re also doing more work with Vue.js, so experience in that is a plus
Now we dive deeper into the specifics of our typical technology. However, the twist here is that this list is not about us disqualifying people who don’t know these technologies – it’s about us showing the developer that we know our stuff.
The list is also simple and broad enough to show that we have flexibility and opportunities to work with a pretty wide range of different software (even though we’re niched down to a couple of specific platforms).
In other words, we’re intentionally not setting a super-high bar here. We don’t want the project description to disqualify too many people, because we want a lot of good candidates to make it through to the next stage.
You may also notice that something else is intentionally missing – a formal education requirement. Some of our team members have advanced degrees in computer science, and some of them have no formal computer science education at all. In fact, one of the big reasons for our company’s success as a partner to creative agencies is that many of our team members come from a background in journalism, publishing, or education and most of our tech skills are self-taught over many years and started as hobbies that evolved into careers.
Looking for degrees is an unnecessary constraint that’s going to eliminate promising candidates with no real benefit to you. Hiring is hard enough, why artificially shrink your pipeline? You’ll also find that people who are self-taught (and spend less time enduring the tedium of academic computer science) are often better qualified to work with you on fast-paced, challenging projects.
Eliminating these unnecessary barriers is also a huge competitive advantage for you – because many employers (including the big tech companies) still act like they’re in an ivory tower, which means they’re leaving great candidates unhired.
This role will include direct interaction with clients based in the United States. While your work hours are flexible and we have no geographic restrictions, we will need you to be available for occasional phone calls with clients and other team members and to be responsive via e-mail, during U.S. business hours.
We’ve been doing remote work since long before remote work was the new normal. Just like the lack of a degree requirement, a strong focus on location independence and time flexibility makes you incredibly attractive to a much wider range of candidates, including those who need to work hours outside of 9-5 because of family-care responsibilities.
The one caveat you’ll see in the job description above is the desire for someone who can be available during North American business hours. Although we do look for this in some candidates, it’s not always a prerequisite, particularly as your team grows beyond a single developer. Several of our team members work evenings or weekends, even though they’re all located in the U.S. and Canada, and they’re a valuable part of the team even though they’re not the ones fielding daytime meetings.
Our goal is to develop a long-term relationship that provides you with a reliable stream of work and fits your schedule and your business goals. This is a freelance/contract role.
If this sounds like the right fit, please DM me here or e-mail [email protected].
The final section keeps the focus on the candidate while driving home all our competitive advantages. This job is about a great experience for you, not simply about what you will do for the company. These few sentences are more powerful than pages of mission statements and poetic waxings about how great it is to work for you.
The Interview
You’ve scoured the earth to find a promising web development candidate – and now it’s time for the interview. Your candidate seems smart, has a decent portfolio, and says they can do it all. But how do you know if they’ll really get the job done?
Successfully vetting a developer is a huge challenge – especially if you’re not a full-stack developer yourself. Here’s how to make sure your developer is really an all-star – even if you don’t have the experience to review and judge every line of their code.
Say no to code reviews
Many web developers will maintain a public Github account or offer to show you examples of their code. This is cool, but it’s not a particularly helpful way for you to measure how the candidate will operate in the real world, which is where you need them to help your business succeed.
The problem with code reviews is that they lack crucial context. For starters, looking at a Github repository if you’re not a full-stack developer feels a lot like staring into the Matrix. Even if you can successfully dissect the code, you have no idea if this project took them a few hours or a few years. And you have no idea how much of their code is pulled directly out of the copious open-source examples and libraries, which means you really don’t get a great sense of what they’re thinking and what they can do on their own when there’s a deadline approaching.
At the same time, you’re missing critical information about the goals of the client for whom the portfolio project was created. It’s not uncommon, for example, for a dozen team members at a client company to contribute to a project – often asking the developer to do things in a way that pleases the client but doesn’t really conform to best practices. When you’re looking at a finished product, it’s very difficult to know exactly how much of it came directly from your candidate, and how much was influenced (in good or bad ways) by their client or other members of the project team. You may even disagree with a client’s decision – or focus intently on something the actual client didn’t consider important – and end up giving your candidate demerits for something that wasn’t their decision or their fault.
Interview for communication and enthusiasm
So without putting a ton of weight on a code review, how do you know if your candidate is right for your company? Start with a brief, one-on-one interview. The goal of this interview is not to ask questions with right-or-wrong answers, but to chat and get a sense of the person’s ability to do three things:
- Schedule an appointment and communicate effectively via e-mail
- Speak comfortably and professionally in a business setting
- Tell you a story about a project they really enjoyed, with lots of specifics about their favorite parts and their challenges
It’s your job to simply ask questions and let the candidate regale you with tales of development projects past. Ask questions like:
- What are your favorite types of projects to work on?
- What’s the coolest thing you’ve built recently?
- What was your most challenging project in the past year?
- What was your most rewarding experience in the past year?
Notice that these are all broad questions with the goal of getting them talking. You’re not quizzing them or putting them on the spot to prove anything to you right now.
If you want to get more specific, you can ask about things you know you have in the pipeline. Here are two of ours:
- Have you ever built a custom WordPress plugin? Tell me about it.
- Have you connected WordPress to an outside API? Tell me all the details about what you built.
By the way, those two are our sweet-spot qualifier questions, and you should experiment with creating your own. If a developer has done both of those things, they’re generally going to be what we consider a Software Engineer – which is akin to a Level II web developer from a hiring and compensation standpoint. In other words, they’re beyond entry-level, and thus they’re likely well-qualified to work with us.
If your developer candidate can tell you some cool stories about things they’ve built in the past if they seem really excited about it, and especially if they can show you that they have experience on your “sweet spot” tasks, you’re ready to rock. Wrap it up with some small talk and get to know them personally a bit, then offer them a test project.
The Test Project
This is where the rubber hits the road. You’re about to offer a paid, one- to two-week project where your developer can show you how they work in the real world.
You’ll frame this by saying, “This will be an opportunity for both of us to test out working together. If for any reason either of us finds it’s not a good fit, we can part ways with no worries whatsoever.”
Your test project should require about 20 hours of work and come in one of these two forms:
- Ideally, a small project on a relatively loose timeline, allowing them to take a little longer (or mess up completely) without affecting your relationship with your client.
- If you don’t have a small project ready, have them re-do a project you completed in the past year.
The benefit of having them do a real project is that you actually get something done and you get paid for it, but you do run the risk of them failing and pushing your schedule back a couple of weeks. Paying them to re-do a previous project is a cost out of your pocket, but you get the benefit of taking a safer approach to your test.
During the test project, you’ll want to give very clear instructions, but also find places to ask your developer to “use your best judgment.” In fact, seeing how they act when they use their best judgment is the whole point. You can hire lots of developers for $5 an hour who can work their way down a meticulously defined checklist – but you need someone who has the initiative and experience to take basic instruction from you and extrapolate it into something that’s pretty close to what you would have done yourself.
That way, you’re actually saving time and getting huge value from your developer (because they can make reasonable decisions without you), as opposed to painstakingly micro-managing every pixel and line of code.
That’s the beauty of the test project. You keep it low-stakes and force your new developer to show you how they behave in a real-world environment, and only once you know they’re up to the task do you assign them mission-critical work.
If they succeed, you’re ready to roll. If not, it’s a small cost, and you can part ways amicably and move on to your next candidate, without doing any damage to your business in the process.
Work Together Forever
There’s a paradox you’ll discover as you’re building your team: even though hiring great people benefits everyone, nobody really enjoys the process. Agency owners struggle to write job descriptions, conduct interviews, and make judgment calls about the best candidates. Candidates hate the process of searching for opportunities, crafting resumés, updating portfolios, and feeling like they have to sell themselves to one company after another.
So, the next step is to make sure your great new web developer sticks around so you don’t have to go through all this again for no good reason. Unless you’re actively working to forge a long-term relationship with your developer, chances are someone else is working much harder to lure them away.
It’s most painful for the agency owner when a developer parts ways with a company and leaves key projects hanging – which, even in the best circumstances, is hard to avoid for an agency that always has many projects at various stages of completion. (Even if someone gives a month’s notice, they can’t realistically wrap everything up before they leave, and it might not be enough time to hire someone to fill their role.)
The magic of location independence and flexible hours
First, you’ll want to focus on remote work, because web developers tend to highly value their location independence and time flexibility. They’re also great at working remotely, and significantly more efficient than a typical in-house employee since they’ve been honing their work-from-home skills for years. Nobody in this group accidentally gets distracted by Netflix or Facebook after lunchtime (ok, maybe Wordle in the morning).
And because they can take advantage of their location-independence to live wherever they want, they can earn extraordinary incomes while charging cost-of-living-adjusted rates that seem reasonable compared to the out-of-control costs of tech hubs like the San Francisco Bay Area and Seattle.
If you’re set on your team working in-house, you’ll need to be ready to compete with big tech companies – that means a high-end office space, a well-manicured reputation, and an acceptance that, despite your best efforts, most of your best hires will move on when a more prestigious opportunity knocks. This approach works for some companies, particularly if you (as the owner) want to aspire to build a Silicon Valley-style workplace downtown in a major city.
If you prefer longevity, consistency, and working with a highly-skilled, widely experienced technology artisan, then being cool with granting more flexibility and independence in exchange for those benefits is your secret weapon.
A roadmap for career growth
One of the challenges of running a relatively small business is that your most valuable and ambitious team members often look up the ladder and see only you – which means limited growth potential since they’re not likely to take over your role as owner any time soon.
This is one of the areas where a big tech company can really appeal to a young developer – by showing a clear path to a career that’s bigger and better in many quantifiable ways.
To compete with that, you’ll need to get creative about how your company is structured and how you compensate your team as you grow. If you’ve been working with a developer for years, it’s likely they’re thinking about how they can someday become more than “just a developer” – that could mean managing other developers, shifting to sales or account management, or some combination of the two. We encourage you to nurture those instincts when you see them in your team because it means they’re aiming for growth that will be mutually beneficial – they’ll advance their careers and grow their incomes while helping you build a more valuable business.
For a long time, it was difficult for us to embrace growth. We’d get to a place where we felt like we were “sold out,” and then we’d slow down marketing and sales and focus on delivery. That was fun, but also set us up for stagnation and sometimes put too many of our eggs in too few baskets, exposing us to risk if a large client were to end their contract.
And even though we were making plenty of money with that strategy, it had the nasty side effect of stunting our team’s career growth – and more importantly, constraining their imagination about what the future might hold. If our five-person company is still going to be a five-person company in 10 years, then our team’s only real option for a career leap is to move to another company or start their own.
But if we grow to a team of 25, every one of those first five hires can see a clear path to a management role if that’s what they want to pursue. And as the company’s revenue grows, it gives us the fuel we need to provide bonuses, profit-sharing, or equity opportunities to managers who want to move to the next level. In other words, an ambitious young developer could map out an entire, successful, prestigious career path without ever working for anyone else.
Don’t grow for growth’s sake. Don’t even grow for your sake. Grow for your team, so you can give them the opportunity they deserve to build an admirable and enviable career.
