How to hire the right Laravel developer for your business

• Define your needs
  • Scope of work
  • Project duration
  • Budget
• Get the word out
• Create your job ad
• Get the job ad out there
  • The direct approach
  • Job boards
  • Recruiters
• Review profiles
• Schedule interviews
• Bringing it home
  • Make an offer
  • Onboarding

tl;dr: Get organized!

Hiring a developer is not easy, and when you add specifics, like 'must have Laravel experience', the task can get a lot more intense and time-consuming. Trust me, I’ve been there!

One of the biggest challenges—and risks—when deciding which technology to use to build your business, is knowing if there are going to be enough qualified people who understand the technologies you're going to use. And then for there to still be some of them on the market when you need them.

Not every company can afford to pay the last few COBOL developers to help keep their mission-critical systems online.

Technologies come and go. Developers want to stay relevant so they can keep earning. So they keep learning new technologies and some will switch their go-to tools a number of times during their career.

These factors (among many others) cause tools, languages, frameworks and platforms to rise and fall.

If you're planning to run a profitable business for a reasonable length of time (5+ years), you're totally right to question what tech to build on; you don't want to be re-platforming every couple of years just because you can't find the right developers!

PHP and Laravel are on a trend-bucking curve. PHP's death has supposedly been coming for many years, but every year we see hundreds of thousands more sites and apps being built on this solid foundation.

And far from being just a tool for solo developers, Laravel has matured into a strong, enterprise-ready framework, used by some of the world's largest and most successful corporations, backed and managed by a profitable and growing business run by a BDFL (Benevolent Dictator For Life), one of the best ways to manage large-scale open source projects.

But even so, the talent risk is still a very real possibility. If some shiny new tech and a few well-funded startups come along, they can quickly vacuum up all the talent.

This is one of the main reasons Laradir exists, to show that there are thousands and thousands of qualified Laravel engineers globally who have built careers on Laravel and love working with it. So a supposed lack of talent is no reason not to use it.

Go ahead, build that new thing in Laravel!

That said, when the time comes to actually hire Laravel developers, it might be a new challenge for you or your org. And while there are many Laravel developers keeping their ear to the ground and looking for new roles, the ideal ones for your company/product may be quite happy in their current roles (as you'd expect them to be, using the best web application framework available!).

So how do you find them, get their attention and seal the deal?

In this post, I want to give you a few steps you can follow to hire the right Laravel developer for your company, while showing you how to use Laradir to your advantage to cut through the busy work.

¶Define your needs

Goal: Be clear about your requirements and expectations: for yourself, your team and your candidates.

Whether you're looking to hire a freelancer or a permanent employee, getting these steps clear first is going to help immensely.

Knowing what you need will help you to more easily spot folks who fit the bill; being uncertain about this can lead to many wasted hours on application review and interviews. Or worse: a bad hire.

¶Scope of work

Clearly define what your project entails and what specific skills (besides Laravel, of course) are needed.

Perhaps you are integrating with some new API and need someone who can come in and build it out quickly. Can you find someone who has experience with that specific API/vendor already? While they may be able to command a better rate/salary because of their experience, the extra investment will likely be worth it for the quality of the output and the speed at which they're able to build it.

Or perhaps you need a developer with leadership experience, who doesn't mind getting their hands dirty with some code every now and then. If so, be clear that this is one of your requirements, as not everyone wants to take up leadership responsibilities; some will prefer interfacing with code more than interfacing with other people.

¶Project duration

Determine whether this is a short-term project or needs to be a longer-term engagement.

It's not always easy to see at the outset whether a particular piece of work is going to be big or small. If you don't already have a good working relationship with some trusted developers, you may need some guidance on just that first part (I can help you there!).

If you have an existing team, ask them whether they feel bringing more people in to the team is the right answer and listen to them - they may have a better feel than anyone for how much work there is and how easy or hard it's going to be to bring new people into the mix.

If it's a longer engagement, consider a permanent hire as it may be a more cost-effective option in the long run.

Short-term projects usually require more experienced folks who can come in and get up to speed quickly and under there own steam without too much hand-holding, so you may want to limit your search for folks who are considered more senior.

¶Budget

Make sure you have a clear budget for the work, considering the complexity of the project and the market rates for Laravel developers. If you want to attract the best talent, you've got to be prepared to pay top-of-market rates to attract them.

If you're planning to make a permanent hire, make sure you've factored in extra costs, such as equipment, typical expenses, holiday and sick pay, taxes and other state-specific contributions and compliance.

Remember that contractors will typically charge more as they need to cover all of these costs plus insurances, taxes, accounting fees and more, by themselves. So, while it reduces some of the papwerwork burden on your side, it will come with a more appreciable, direct impact on your bottom line.

Once you've got all of this clear, create a job description/specification ('job spec').

This should be a brief document that lists the requirements of the role and expectations/responsibilities of successful applicants.

This will form the basis of your job ad, but it doesn't need to be fully fleshed-out yet - it's just for your internal use to start with.

¶Get the word out

Goal: Start priming your immediate network that you're hiring.

Your job spec will undoubtedly need some refinement, especially if this is the first time you're hiring for a role like this. A good first step is to let folks know that you're looking to fill the role.

This isn't about advertising the job spec just yet, it's about letting people know that you're keen to hire a developer and that a full job spec is forthcoming.

The first people to tell are your existing team. Perhaps they can provide some input on details that you haven't thought of yet. Or maybe they have some connections in their own networks who may be interested in such a role.

If you're struggling with the thought of making it public knowledge (or at least 'public' internally to your organization) you have another problem to solve first.

Maybe you're trying to avoid it 'doing some damage'. You need to address this first.

If you're treading eggshells to avoid upsetting someone, it will likely make for a very difficult hiring process.

Can you 'tease' the role on your company's social media accounts? Could you attend a local Laravel/PHP/Symfony meetup and mention it to folks there?

You may get some early feedback and insights that help you refine your expectations further. You may even be introduced to some potential candidates without having to spend any significant money on advertising!

¶Create your job ad

Goal: Encourage the right candidates to apply, not get lots of applicants.

Even if you already manage to get a few potential candidates together, you should still create a finalised 'job ad'. You may not need to publish this if you already have a strong pool of potential hires, but it's great to have it and be able to give it to each candidate so everyone has a shared understanding.

Don't rush it. Put some serious thought into the details of the ad and get it right before you start working to promote it.

Make sure it includes a brief intro to your company and why working with you is a good thing.

Remember, it doesn't need to include every little detail about the position as this will likely change over time anyway, but it should be detailed enough that someone has at least some clue as to the kind of work they will be doing.

You should be absolutely clear on things like:

• Expected experience
• Required skills and/or qualifications
• Contract type (permanent/temporary)
• Work location
• Salary range/budget
• Entitlement to holidays and other standard benefits/policies you have in place (if this is a permanent role)

Be straightforward and specific; don't be vague in the hopes to catch more candidates.

¶Get the job ad out there

Goal: Get your job ad in the right places to widen the net of potential applicants.

Like any kind of advertising, promoting a job ad can be a bit of an art.

The first and most important place the job ad should go is somewhere close to your company website, ideally on a company domain. This makes an immediate association between your company and the ad.

This signals that it's a legitimate opportunity, that you're serious about it and that, as an organization, you know what you're doing.

This may be a Careers page provided by your company's ATS. Most provide this feature as part of the service.

Some ATS platforms also have free and paid options for pushing your job ad out more widely.

If you don't have a 'real' ATS, don't worry, here's a Trello board template that you can use for free, which is a good, low-cost, low-effort starting point.

Don't use Excel or some other spreadsheet tool for applicant tracking! That's a terrible way to manage applicants that is almost guaranteed to result in missed opportunities and a lot of frustration for you and your candidates.

If you find that your ad isn't atttracting candidates, don't rush to make huge changes to it, and don't just wait a couple of weeks and re-publish the exact same ad. Try getting some feedback directly from developers and consider making some changes before re-publishing.

¶The direct approach

As you did before, share internally with staff - maybe you have an all-hands email address you can use or some internal 'notices board' (Slack, a wiki, Google Site, or Notion).

Post about it on company social networks.

If staff are open to sharing it on their personal social network accounts (especially if they're adjacent to engineering e.g. web designers, data scientists, other developers), explore this option, but never force people to share company updates on their personal social accounts.

Look out for places where developers 'hang out' - some are on social networks like Twitter and different Mastodon instances. Others can be found through LinkedIn searches. But many don't use social media at all, so even a Google search may help.

Don't forget going to technology-specific events too. A Laravel meetup in your area/region/country may be free to attend and only take a little of your time once a month or less often to cultivate some productive relationships with switched-on developers.

Don't forget niche communities like Larabelles too, who are trying to help underrepresented groups to find their next great role.

Set up a Teams account on Laradir where you can exclusively search among highly-qualifed Laravel developers. Each candidate has been pre-approved by me, an experienced hiring manager who is also a Laravel developer (and a big fan of the framework).

All developers are required to complete a Laravel-focused profile so you can find the right person to join your team. And to make it easier for you, Laradir’s unique system will let you filter your search by role, availability, country, etc.

¶Job boards

We're very lucky in the Laravel community to have a solid job board and platform for getting the message out about roles.

I've used job boards a few times. With Larajobs, for example, you will definitely get a lot of applications, and they will mostly be experienced Laravel developers.

My only frustration with this route is that a lot of applicants coming to you this way will simply send you a standard cover letter and résumé that they use for every single application. Most of them won't have even looked through your job ad thoroughly. They don't know if they're a good fit and they're offloading that work onto you.

So, if you do choose to go down this route, make sure you've got a simple way to filter out all of the noise.

A quick and easy solution is to present a basic challenge in the application, like putting something unusual in the ad (say a picture of a dog about to eat a watermelon) and then asking applicants to answer an obscure question like "What treat was the dog about to eat?"

This is surprisingly effective.

¶Recruiters

This should really be your last resort. It's an expensive option and recruitment agencies are very rarely niche towards a specific framework, so the candidate profiles they present are most likely to be loose matches to your criteria.

But they do tend to have access to a large pool of candidates who are actively looking and they are massively incentivized into helping you fill the role.

¶Review profiles

Goal: Sift through to find the true gems.

A Laradir Team’s account gives you full access to review developer profiles, check skills and experience and visit their social media pages, portfolios, and GitHub accounts.

Profiles are only allowed on the site if there is concrete evidence that they are a Laravel developer, either by linking to personal projects on GitHub, on their personal website, or blog articles written about the subject.

I take this very seriously and I am quite strict about approving profiles. The current approval rate is around 53%.

But no matter how hard I work to help you out, there will always be some work you need to do. Only you know your business, your industry and your needs.

Pay special attention to developers who have already had some experience in your industry or have completed projects similar to yours.

You should aim to have a pipeline of candidates

¶Schedule interviews

Goal: Get to know the person behind the résumé.

Interviews are the date. It's where you dress up, pick a good venue and spend some time getting to know each other. Once you have found a few profiles that meet your needs, it’s time to chat!

If you're using Laradir, you can contact devs directly using the built-in messaging system. If you're already using an ATS, let me know which one you work with and I'll create an integration so you can easily import candidates directly into your system.

I just launched our Workable integration today too!

If you've got a good feeling about an application, don't over-think it. Schedule a brief introductory phone call for 15-20 minutes. This is an opportunity to find out if they are who they claim to be and that you can communicate with them. It can involve some light skill assessment, but keep it simple to start with.

For any who pass that first stage, make sure you conduct at least one other interview to assess their skills, experience, and work & communication style.

This doesn’t need to be too aggressive or technical. Try to do it via video conference if not in-person, so you can pick up on body language and other social cues.

Many companies will do one or two more interview stages, giving both your team and the candidate more opportunities to get know each other.

Depending on seniority of the role, the complexity of the system or the delineation of your teams, you may want to do some more deep-dive technical interviews.

A note on whiteboard challenges and take-home tasks:

I'm not a fan of either of these. Many teams use them without understanding what the goal is; they do it just because they see others doing it.

The goal is usually to find out how the other person thinks, not to assess their recall ability or the correctness of their solution.

Test conditions and take-home challenges may not reflect the collaborative and supportive environment of your day-to-day work, so why do that at the interview stage?

¶Bringing it home

Goal: Bring the right candidates aboard safely.

Bringing new people into any organization of any size can be disruptive. You want any new hires to want to be there, motivated and keen. You also want their onboarding to be smooth so they can be productive.

If you've hired before, try to follow your standard process so your team know what to expect.

If this is the first time you're doing this, I highly recommend you seek some guidance. At the very least, try to speak with a friend or acquaintance who has done it before and is willing to offer some advice.

¶Make an offer

My most important takeaway here is: Make sure you get things down in writing. Formal, signed contracts are obviously preferred, but even emails can be used in case there are disagreements down the line. A verbal contract is often not enough. I'm not a lawyer, tho, so please seek appropriate advice for your region.

Any agreements should cover:

• The nature of the work and the role they'll be assigned to
• The rate of pay or project fee
• The payment schedule
• Any other fees, expenses or other benefits (options, healthcare etc)
• Start date
• Place of work
• Any equipment that will be assigned, along with how that's to be handled and used
• The assignment of rights, trademarks and intellectual property
• Any other rights and obligations agreed during your negotiations

Make sure agreements are in place before any work begins.

¶Onboarding

It's a good idea to have some kind of review period where you can work together without making a long-term commitment first.

This might be a small initial project (for freelancers) or a probationary period (for employees). This should be no more than 3-6 months, as this is plenty of time to find out if someone is going to be a good fit. If you choose to do this, make this a part of your written agreement too.

In either case, don't make folks work for free.

Make sure you are assessing their progress during this period without being overly invasive, and be clear about what you expect from them and the possible outcomes whether they succeed or fail.

Prepare for some of the kind of things your new hire is going to face on Day 1, Week 1; don't leave everything to the last minute.

Onboarding is a culture-defining moment. It says a lot to new hires when they're not having to chase for things to do or fighting to get time with people to help them get set up.

Most people want to come in, get on and be productive, so make it as easy for them to do that as you can by being prepared.

---

All of this should feel like common-sense practice, especially if you've hired people before. It is definitely hard work, but I can say with certainty that, if you do it well, you will be rewarded by finding some genuinely great developers and human beings, who you will enjoy working with.