The brief euphoria of your newly opened headcount has transformed into a full panic: “how on earth will I hire a web developer for my team?” As a CTO I’ve been responsible for dozens of hires, and for a long time a new headcount struck fear and dread in my heart too. There are many challenges to overcome, but don’t worry - you can and you will successfully hire a great engineer and emerge a hero! It all starts with one little secret:
I know, your instinct is to balance hiring with other priorities, aka half-ass it. Mine too. Unfortunately, that’s a great way to drain your time and energy for a year with nothing to show for it. Instead, plan to spend a massive amount of time for eight weeks. We’re talking at least 20-35% of your week, depending how much help you can get. “Won’t that suck?” you ask. Yes, it will suck. But at the end you’ll move on with your life as the manager of a larger, more capable team! I’ll say it again because it’s the difference between success and failure:
Commit, or fail.
It’s scary to invest so much time, but below I’ll share the process that has allowed me to hire great web developers - not painlessly, but efficiently. This advice is especially relevant for small companies trying to hire mids/seniors, where an engineering leader doesn’t have the benefit of a strong employer brand or an established recruiting pipeline bringing you candidates.
This post will cover the entire funnel:
Attracting The Right Web Developers
Nailing your job description is crucial. The document itself is important, but the mental rigor behind the document underpins this entire process. Hiring web developers can be so hard that you feel you have to take anyone you can get; that’s a myth. By starting with a clear idea of your ideal team member, and realistic expectations, you’ll find the right person. So ask yourself:
What Skills Are You Truly Hiring For?
A fearless assessment of your needs will smooth every subsequent step.
Are you trying to hire web developers for a startup? Hiding your chaos might help you hire faster, but your team can’t support a developer who thrives on structure and direction. That quick hire will turn into a nightmare of a performance management problem. Your goal is not to convince someone who isn’t a fit - your goal is to find a developer who’s already aligned.
If your hire will be expected to navigate an ambiguous role with no oversight, just say so.
Why Would A Developer Join Your Company?
Luckily, being transparent with candidates about your company is a strength, not a liability. You may think “this place is a mess, we don’t even have a sprint process yet” is going to turn people away. And it will! But there are also plenty of developers searching for an opportunity to take a leadership role and help improve your development process. My career has focused on startups, and “leadership opportunity” has been part of every job I’ve ever posted.
What else makes your opportunity uniquely attractive to a web developer? Sure, you aren’t Google/Facebook/Amazon/etc and you can’t afford to compete with them on salary, but compensation isn’t the only thing a candidate considers. Plenty of developers don’t want to work at a big company - focus on what makes your role interesting and exciting! Being a key contributor on a small team, working on novel challenges, or learning a new tech stack are totally valid and compelling “unique selling propositions” for your candidates.
Alright, now that you understand who you need, let’s go find them!
How To Find Great Web Developers
Buckle up, because this is the soul-crushing part. Once you start it’s an all-out sprint to the finish line, so get your ducks in a row up front. If you’re doing it right you won’t have time to do anything but execute your plan.
VOLUME VOLUME VOLUME VOLUME VOLUME. The last search I conducted we started with over 1000 LinkedIn profiles and hired two people. A thousand sounds like a lot, but it’s manageable if you tailor your process to the volume.
Your goal in this phase is to find hundreds of profiles who have a passing shot at being a fit, as quickly as humanly possible. An actual recruiter or a LinkedIn Recruiter license, paid tools like humanpredictions and Vettery, or free tools like vanilla LinkedIn and AngelList can get you there. Use the search filters in whatever tool you’re using to cast a wide net; for example, LinkedIn Recruiter allows you to search by fields like role title or skill endorsements. Honestly these filters are often wildly imprecise, just do what you can.
Do not spend ANY time inspecting profiles, except for a few spot checks to see how you can improve your pool composition. Inspecting profiles at this stage will quickly descend into madness. The one thing that’s going to give you encouragement in this phase is - say it with me - VOLUME.
When your pool reaches at least 200 profiles you can move on to the next step. Substantial batch size will improve your efficiency and build momentum. Momentum is essential for morale during hiring, especially once you start involving more of your team in the later phases.
Did I mention this process thrives on 📣📣 VOLUME?!?!?!!?! 📣📣
I haven’t mentioned job boards because they haven’t helped me get the volume I need. Unfortunately, diversity starts at the top of the funnel and it’s much easier to find diverse job boards than diverse LinkedIn pools. I wish I had more suggestions on how to manage that tension… I’ll just repeat that volume generates outcomes, so whatever outcomes you’re looking for you need to figure out how to generate the corresponding volume.
Narrowing The Field
Now you’re going to analyze the profiles. But wait - there are hundreds! Go in with a strategy or you’ll be here forever. Decide ahead of time on a small number of simple criteria. For example, in a recent search I was looking for a web developer with at least 6 years of experience and solid ruby/rails exposure. Look ONLY for these things when reading profiles. You’ll quickly hone in on the fastest way to find the info and make a decision.
Since you’re going to be doing so many of these, make sure you have a fast and reliable way to analyze, store your decision, and repeat. The speed will make or break you. At my best this year I analyzed about 80 profiles an hour on LinkedIn Recruiter. This is one of the most soul-crushing steps, it’s so rote and monotonous and it just feels bad to be judging humans so mechanically. Psych yourself up, spend an hour or two plowing through it, and then give yourself a break. Too long and your brain will glaze over.
Many profiles will be in a gray area - don’t worry about it, in those few cases the penalty for getting it wrong is minimal. You can always source more profiles, and the rest of your process will weed out anyone that you over-included.
Expect extensive drop-off in this step, 50-80% or more depending how well your tools let you tailor your initial pool.
Once you have at least 30-60 profiles that meet your basic criteria, you can start reaching out. You only get a few sentences of attention, so make sure you’re clear about the role and your unique selling proposition. Unless you’re targeting specific people for a high level role like a Principal or VP, don’t worry about customizing this outreach. We’re still in a volume-based scenario here. Write the most interesting form letter you can, make sure you address everyone by the correct name, and just let it fly.
You probably won’t send enough of these to run a true A/B test, but tune your message if you glean any insights as you go. For example, I had been telling people we’re a Chicago company but initially hadn’t clarified that the role was remote-friendly.
The goal of this phase is to schedule a 30-minute follow-up, so make sure to close your message with a strong call to action. Something simple like “Are you interested in a quick call to learn more?” is great. A yes/no question makes the response super easy.
I like this phase, because we get to start seeing some results! 👀
We’ve found that having an engineering leader reach out rather than a recruiter materially increases our response rates.
Interviewing Web Developers
We’re finally going to start talking to people. You might modify this structure to fit your own circumstances, but as long as you hit the high points you’ll be okay.
A 30 minute call starts building a rapport with the candidate. This phase requires significant time and effort, because the previous phases are such inexact filters. But your goal is to hire, and that means balancing what works for you and what works for the candidate. A call is much more engaging than an email thread, so I usually move to a voice/video channel as fast as possible. I’ve had good luck spreading this work out so I don’t have to personally make every single call.
When someone shows interest in your initial reach-out, you can reply: “Great! The next step is a call with Alan, he’s open tomorrow 2pm-4pm, what works for you?”
You might see a small drop-off from people who expected to talk to you personally, but it’s worth it to save your calendar from utter destruction.
In this call, pitch your role/company and see if there’s mutual interest.
- Do they actually have the technical experience you need?
- Do they check one or two of your most important boxes? Any obvious red flags?
- What’s their timeline for making a move?
- Discuss comp if you want (“what would it take for you to consider making a change” or “our salary range for this position starts at 140k” are good, “what are you making now” not so good and potentially illegal)
- Answer their questions
- Discover their motivation (key for later!). If you can’t offer best-in-class salary you’re going to have to appeal to them in a different way.
One way or another you want to evaluate the candidate’s technical ability. I’m not trying to resolve the many schools of thought on technical evaluation in this post. As a starting point I’ll just say that at Ascent we currently offer either a take-home exercise plus a video chat to review it, or a live pairing exercise. The candidate can play to their strengths and needs, and we get a conversation about code either way.
Providing choices can reduce bias in the process. A single way of doing things easily and silently turns away large swaths of people (which also tanks your hire rate).
This is when I start bringing other developers into the process. They can help evaluate code samples and conduct the review, and I usually ask them to review take-home responses without including any personally identifying information to reduce bias in our process.
On-Site / Full Loop
Now it’s time for the whole team to get to know the candidate. By this point, you know a fair bit about the candidate, but your team does not. It’s natural for the team to be skeptical, which can easily come across as cold or harsh for the candidate. Give your team an outline of what you know about the candidate so far. The candidate’s motivation is especially useful here. And, gently remind the team to be warm and “sell” the candidate a bit. Whether or not you make an offer, you want every single candidate coming out of your process to be excited to work for you.
Choosing The Best Web Developer
Adopting a rubric is one of the most effective ways to improve your candidate evaluation. It should include the dimensions you want to evaluate, and examples of what constitutes strong or weak performance on those dimensions. The Medium engineering team has an excellent rubric I’ve used as a starting point. A rubric reduces bias in the hiring process by helping you evaluate candidates equally and objectively (to the extent any judgment of a human after three hours is objective).
A rubric has become my most valuable tool as a hiring manager.
With a rubric I feel like I’ve systematically evaluated a candidate, touching on each and every aspect I care about. Strengths and gaps become obvious, and the final outcome feels like a fully informed decision. Gone are the days of finger-in-the-wind vibe-based hires. Make sure your team understands the rubric and references it liberally in their feedback.
The final element of selecting the right web developer is gathering evidence-based feedback from your team. Rather than asking hypotheticals like “what are some important elements of teamwork”, ask for a concrete example: “When is a time your team worked really well together? How did you contribute?” This ensures the candidate can walk the walk as well as they can talk the talk. Think back to some of your best and worst interviews, and you’ll find that evidence-based answers made candidates seem much more grounded and capable, and when you come away thinking “they said all the right things” but still feeling wary or hollow it’s often due to a lack of evidence. Don’t just take their word for it - dig all the way to the core.
Use “STAR” questions to gather evidence. Ask about the Situation (original problem statement), Task (the candidate’s responsibility within the situation), Action (what they did), Result (how it went). You’ll quickly discover the difference between their knowledge and their experience.
Making The Offer
Finally, after 4-6 weeks and hundreds of person-hours, you found a developer you like! Amazing! Time to seal the deal. Here’s how you’re gonna make it happen:
- Make the offer “in person” (video/phone is fine)
- Ask for any remaining questions. Especially in a remote environment, the candidate will have zero opportunity for hallway/elevator/interstitial conversations where they can just get comfortable.
- Tell them why you want them! If you can’t make a very convincing pitch to the candidate about why THEY are right for YOUR team, you’ve severely missed the mark in previous steps. Everyone likes to feel special and seen; draw connections between their strengths and the needs of the business.
- Remind them why working for you will address their motivation and advance their career. This dovetails closely into the previous item.
- Present the full offer. Carefully explain non-cash aspects of their compensation: equity, benefits, etc. Most people won’t care about every benefit, but many people care deeply about one or two. Make sure your offer fits into your salary bands properly or you’re going to have big problems later.
- Don’t pressure them to commit, but get an initial indication of how they feel about the offer.
- Let them have a reasonable (but not indefinite) amount of time to think it over. A week is standard.
- Resist the urge to negotiate against yourself. If they don’t jump at the offer, it doesn’t mean they won’t accept. If they want another 5k they’ll ask for it. If they want another 500k, this was never going to work out in the first place.
Onboarding deserves a separate post; it’s an extension of the hiring process, and one of the best investments you can make in the success of your employees. But for now, breathe a giant sigh of relief and do something nice for yourself, you deserve a break! Hiring web developers is one of the most challenging, draining aspects of engineering management. If you can do this, you can do anything.