Hiring a mid-level Laravel dev: the signals that actually matter
Published May 30, 2026 · by Majd Ghithan, written with the help of AI
The best hire I ever made failed my first question. I asked him to explain service containers and he stumbled, went quiet, then said "honestly I use them every day but I've never had to explain the internals, let me think." He got there slowly, out loud, correcting himself twice. I almost held it against him. Then I realized I'd just watched exactly how he'd behave when stuck on a real bug: no bluffing, thinks in the open, self-corrects. I hired him. Best call of that year.
Meanwhile the candidate who answered every definition instantly turned out to have memorized answers and couldn't write a working query. Interviews reward the wrong thing by default. Here's what I've learned to actually look for.
Depth hides behind boring questions
Anyone can recite what a queue is. The signal is in the follow-up: "what happens if the job runs twice?" A mid-level dev who's actually shipped queued work has been burned by a double-charge and lights up. One who's only read about queues gives you the definition again, louder.
So I stopped asking "what is X" and started asking "tell me about a time X broke on you." You cannot fake a war story. The specifics, the wrong turn, the 2am log line, only exist if you were actually there.
Signal vs red flag
After enough interviews you build a table in your head. Here's mine for mid-level Laravel:
| What they say | Green signal | Red flag |
|---|---|---|
| "I used queues" | Talks about retries, idempotency, failed_jobs | Thinks queue = "make it faster" |
| "I write tests" | Tests behavior, has opinions on what NOT to test | "I test getters and setters," 100% coverage as a goal |
| "I know Eloquent" | Mentions N+1, with(), when to drop to query builder | Only ever Model::all() then filters in PHP |
| "I've done migrations" | Has locked a table in prod and learned from it | Never ran one against real data volume |
| Explaining a past bug | Owns their mistake, names the root cause | Every bug was someone else's fault or "just a weird glitch" |
| Asked something they don't know | "I don't know, here's how I'd find out" | Bluffs, invents an API that doesn't exist |
That last row is the one I weight highest. I'm not hiring someone who knows everything. Nobody mid-level does. I'm hiring someone who's honest about the edge of what they know, because that's the person who won't ship a confident guess to production.
Take-home vs live coding
I've swung between both and landed here: a small take-home, then talk about it live.
A live-coding gauntlet mostly measures who performs well with someone breathing down their neck, which is not the job. Real work is quiet, with docs open and time to think. But a pure take-home has its own hole, you don't know who actually wrote it, especially now.
So the take-home stays small, an hour, tops, and the interview is me asking them to walk through their own code. "Why a job here and not inline?" "What happens if this API times out?" "What would you change with another day?" You find out fast whether the hands that wrote it are the hands in the room. Someone who wrote it defends the tradeoffs easily. Someone who didn't gets vague.
What candidates overclaim
Mid-level CVs are a genre. Everyone "architected scalable systems" and "led the migration." Some did. My job is to find the seam between the resume and the reality, gently.
I don't challenge, I zoom in. "You led the payments migration, nice, what was the hardest edge case?" Real ownership has texture, the weird refund state, the double-webhook, the thing that shipped broken and how they caught it. Borrowed ownership goes abstract immediately: "you know, just the usual complexity." The detail is the tell. People who did the work can't help remembering the scar.
The bar for mid-level
I'm not looking for a senior in disguise or someone who never gets stuck. Mid-level means: writes correct, readable Laravel without hand-holding, knows what they don't know, and gets unstuck by reading and asking rather than bluffing and hoping. Curiosity over credentials, honesty over polish.
The polished candidate who's memorized the right words is a worse bet than the one who thinks slowly out loud and says "I'm not sure, let me reason through it." One of them will bluff on your production database someday. The other will ask. Hire the one who asks.
