How I’d hire engineers in 2026 if I had to start the process from scratch

If I had to start hiring from a blank calendar in 2026, I would not clone the loop I inherited in 2019. That loop assumed a flood of applicants, a leetcode screen that made the company feel rigorous, and a take-home that measured who had a free weekend. The flood is gone. The rigor was mostly theater. The weekend was a tax on the people I actually wanted.

I would start with the work, not the requisition. I would keep the loop short enough that a good candidate is not still waiting on “one more stakeholder” after they have already decided. I would treat AI as a drafting tool and a cheating assumption, not as a reason to invent a new hazing ritual.

This is the process I would stand up in the first two weeks, if the company let me.

Write the job as a month of work, not a unicorn

I would not open with “10x full-stack who is also a staff mentor and on-call lead.” I would write the first ninety days as a list. Which service you will own. Which on-call you will join. Which decision you will not get to make yet. Which tool we actually use, including the ugly one.

If I cannot write that list, I am not hiring. I am collecting resumes to feel like I am staffing a fantasy. The market in 2026 punishes fantasy postings with either silence or a pile of generic applications that look like they were generated, because they were.

I would publish salary bands in the posting. Not a range that runs from junior to staff. A band I can sign. Hidden comp is how you waste three weeks and then lose the person to a company that said the number on line one.

I would say what we will not interview for. If the job is a Python API and an on-call rotation, I will not run a graph-algorithm screen. If the job is a TypeScript BFF, I will not ask you to whiteboard a red-black tree. That sentence in the posting is a filter. The people who want a puzzle contest will self-select out. Good.

Sourcing I would actually do

I would not buy a spray of InMails. I would ask the team for five names they would work with again, and I would write those people a specific note about the ninety-day list. I would look at the repos and talks that match the work, not the follower counts. I would take referrals, and I would pay for them, and I would still run the same loop so referrals are not a side door for friends who cannot do the job.

I would keep the public posting. I would not treat it as the strategy. In a thin market the posting is how you stay honest about the work. The names are how you fill the seat.

I would not outsource the first read to a model that scores keywords. I have watched those scores love the people who stuffed “distributed systems” into a CRUD resume. I will use a model to summarize a long CV into the ninety-day list and then I will read the summary against the actual repo or writing. The model does not get a veto.

The loop: four conversations, one piece of work

I would run four steps. Recruiter or hiring manager screen. A short work sample or pairing session. A team conversation that is not a trivia gauntlet. A manager conversation about the job as it is, including the ugly parts. Then a decision in days, not weeks.

The screen is thirty minutes. Can they talk about a system they owned. Can they tell me a failure without performing a TED talk. Can they hear the ninety-day list and tell me what they would change. If they only want to talk about tools they have not used, that is data. If they only want to talk about a model they prompted last week, that is also data.

The work sample is the center. I would pay for it if it takes more than ninety minutes. I would rather pair for two hours on a sanitized version of a real ticket than send a four-hour take-home into someone’s Saturday. Pairing shows how they ask questions. A take-home shows how they finish when nobody is watching. I would pick pairing for most backend and product roles. I would pick a small take-home when the job is mostly independent production work and the team cannot staff two pairing hours this week. I would not do both plus leetcode. That is a week of unpaid labor dressed as a bar.

The team conversation is for “can we stand being in a channel with this person when the page is on.” I would not call that culture fit if culture fit means “like us.” I would call it working agreement: do they treat a junior’s question as a cost, do they need to win every design argument, do they disappear when the task is boring. Those are observable. “Would I get a beer with them” is not a hiring criterion I will write down.

The manager conversation is where I tell them the truth. The on-call is real. The backlog is not a TED backlog. The last person left because of X. If I hide X, they will find it in month two and I will have paid a recruiter to buy a resignation.

What I would do about AI in the interview

I would assume the take-home was written with a model unless I watched them work. That is not cynicism. That is 2026. If I still use a take-home, I would spend thirty minutes on a call walking through the choices, the tests they did not write, and what they would change. A generated repo that they cannot defend is a no. A generated repo they can tear apart and improve is a yes I have seen before, in the form of people who used Stack Overflow well.

In pairing, I would let them use the assistant they use at work. I would watch what they accept. The job is not “can you refuse tools.” The job is “can you own the merge.” If they rubber-stamp a wrong function because the model sounded sure, that is the signal. If they treat the model like a junior who types fast, that is the other signal.

I would not add a secret anti-AI trick question. Those age in a month and they select for people who enjoy gotchas. I want people who enjoy shipping.

Scorecards, not vibes after the fact

I would write the scorecard before the first screen. Same four or five dimensions for every candidate: can they do the ninety-day work, can they debug without theater, can they communicate a trade-off, can they operate with the team’s constraints, any deal-breakers we named in advance. After each step, interviewers write before they debrief. Debrief is for disagreement, not for the first person to speak setting the weather.

I have sat in rooms where “they seemed sharp” beat “they could not explain their own pull request.” Sharp is not a dimension. If I cannot point at the work sample, I do not get to vote yes.

I would keep the panel small. Three interviewers who will work with the person, plus me. A six-person loop is how you get six lukewarm yeses and a hire nobody will onboard. It is also how you lose the candidate to a shop that decided on Thursday.

Speed is a feature of the offer

I would time-box the loop to ten calendar days from first conversation to decision for a normal role. If we cannot do that, we are not ready to hire. We are collecting. Candidates in 2026 have other tabs open. A three-week silent period is a no, even if we eventually say yes.

I would not make an exploding offer to perform urgency we did not have in the loop. If we were slow, we do not get to be sudden. If we were fast, we can be clear: here is the number, here is the start date, here is what happens in week one.

I would involve legal and comp on day one of the req, not day twelve. The number of times I have watched a “we love them” die in a band argument is enough. If the band cannot fit the person we want, we change the band or we change the person before we start dating.

Onboarding is part of hiring

I would not call the process done at the signature. I would have a named onboarder, a first ticket that is real and small, and a week-one meeting that is not a scavenger hunt through Confluence. If we cannot staff that, we should not open the req. A hire who spends month one lost is a failed hire we will blame on “culture.”

I would schedule the first real review at thirty days with the ninety-day list on the table. Hiring from scratch includes the part where we admit we were wrong. A clean exit in month one is cheaper than a quiet struggle until month eight.

What I would refuse to rebuild

I would not rebuild a homework pipeline that takes a weekend. I would not rebuild a leetcode gate for a job that does not look like leetcode. I would not rebuild a twelve-step loop that exists so every director can feel they met the person. I would not rebuild “culture fit” as similarity. I would not rebuild an unpaid trial week. A paid trial, maybe, for staff-plus when the work is hard to sample. Unpaid is how you hire people who can afford to be unpaid.

I would not rebuild a process that cannot say no quickly. A slow no is a kind of cruelty we pretend is thoroughness. If the work sample is a no, we say so in forty-eight hours. The candidate can use the week. We can use the seat.

If I had to start tomorrow, that is the scaffolding: a true job, a short paid-or-paired sample, a small panel, a scorecard written first, a ten-day clock, and an onboard that was booked when the posting went up. The rest is habit we copied from a market that no longer exists. I do not want that habit back. I want a person who can own the merge in month two, and I want them to still like us when they get there.