How to Hire a Laravel Developer: What I Actually Look For

I get this question in my LinkedIn DMs at least twice a month: "We need a Laravel developer, can you look at this person's code?" Sometimes I can help. Sometimes I look at the code and it's obvious why they're asking.

After nine years of writing Laravel code professionally, reviewing dozens of junior developers, and yes — making some bad hiring decisions myself — I've got a pretty solid sense of what separates someone who can actually ship from someone who just knows the framework's name.

The First Thing I Check: Their GitHub

Before reading any CV, I go straight to GitHub. I'm not looking for star counts. I want to see how they write code when they think no one's watching.

Specifically I look for:

• Test coverage — If their last five projects have zero tests, that tells me everything. Production bugs are expensive. Developers without tests create them constantly.
• Commit messages — "fix", "update", "changes" is a red flag. "Fix null pointer in user billing when subscription is expired" is a green flag. It shows how they communicate with future maintainers (which might be you).
• Whether controllers are thin or bloated — Open any controller. If I see 200-line methods with validation, business logic, emails, and API calls all in one place, the person has been writing PHP but not really thinking about architecture.

PHP 8+ Features Tell You Their Vintage

Laravel 11 requires PHP 8.2 minimum. PHP 8.4 came out end of 2024. If their codebase is still full of PHP 7-style code — no typed properties, no constructor promotion, no readonly, no match expressions — they've either been stuck on legacy projects or they're not keeping up.

Neither is disqualifying on its own. But you need to know which one it is.

// This tells me they're paying attention to modern PHP
class UserService
{
    public function __construct(
        private readonly UserRepository $users,
        private readonly MailService $mail
    ) {}

    public function deactivate(User $user): void
    {
        $user->update(['is_active' => false]);
        event(new UserDeactivated($user));
    }
}

// This tells me they last looked at PHP in 2019
class UserService
{
    private $users;
    private $mail;

    public function __construct(UserRepository $users, MailService $mail)
    {
        $this->users = $users;
        $this->mail = $mail;
    }
}

The N+1 Question

I ask every candidate this: "What is an N+1 query and how do you find them in production?" It's not a trick question. It's a genuine dividing line between junior and mid-level Laravel developers.

A good answer covers eager loading, mentions Model::preventLazyLoading() in development, and brings up either Debugbar, Telescope, or slow query logging. A poor answer is "I use with() everywhere" — technically correct but shows they don't know how to diagnose it when it slips through.

Red Flags in Real Conversations

Beyond code review, some things in conversation immediately raise my concern:

• "We don't do testing on this project because we don't have time" — This always costs more time than it saves, usually at the worst possible moment.
• "I put the API key directly in the code for now" — For now meaning forever. This is how credentials get leaked.
• Can't explain the difference between a Policy and a Gate in Laravel — It's a basic question. If they've been using Laravel for three years and haven't touched authorization, they've been working on unusually small projects or ignoring security.

A Question I Always Ask

"Tell me about a time a feature you shipped caused a production issue and what you did." The specific incident doesn't matter. I want to see if they own it, what they learned, and whether they put something in place to prevent it again. Developers who've never caused a production issue have either been very lucky or haven't shipped much.

The Laravel Certification: Worth Checking

The official Laravel Certification is a legitimately hard exam. It covers routing, Eloquent, queues, broadcasting, security, and testing. A certified developer has at least proven baseline mastery of the framework. It's not a guarantee of seniority, but it's a meaningful filter — especially when hiring remotely without the ability to do a paid trial project first.

Bottom Line

The best Laravel developers I've worked with are obsessive about code quality, write tests as a habit (not a chore), and can explain their architectural decisions. They're not necessarily the ones with the flashiest portfolio or the highest UpWork rating.

If you're looking for someone with that kind of background for your next project, I'm available.