Hiring your first engineers: a lightweight process that works

Step 1: decide what the role actually needs

Before writing anything public, write three short lists for yourself:

• What this person will have done in their first three months. Concrete outcomes, not responsibilities. "Shipped the booking flow end to end." "Moved the app off the prototype database." "Owned the on-call rota for the payment service."
• Must-haves. Three to five things the person must already have done, each one something a candidate has either done or not done. "Has shipped a React Native app to the App Store" is a must-have. "Passionate" is not.
• Nice-to-haves. Two or three things that would help but would not stop you hiring someone.

If you have a co-founder, agree on these lists before posting. Most hiring arguments later are really arguments about what the role needs, and they are cheaper to have now.

Only list must-haves you will actually check. A must-have nobody verifies is decoration, and it quietly filters out honest candidates who do not match the wording.

Step 2: write a posting a good engineer will finish reading

Good engineers read job postings looking for reasons to stop. Give them fewer:

• Say what the company does and why this role exists, in two short paragraphs. What stage are you at? What gap does this person fill?
• Describe the first months, using your outcomes list.
• List the must-haves and nice-to-haves as written above. Short lists get more good applicants than long ones.
• State the pay. A real range. If you cannot, leave pay out entirely rather than writing "competitive." In some places a stated range is also a legal requirement, so check where you are hiring.
• Describe how the person will work: engagement type, location or time-zone overlap, who they report to.
• Explain the process and how long it takes. Candidates with options choose the process they can see the end of.

Leave out anything you cannot say truthfully: team size you do not have, funding you have not raised, perks that do not exist. Every line in the posting is something you will be asked about in an interview.

There is a free job description template with these sections and guidance for each one.

Step 3: ask screening questions about the work

Replace the cover letter with three to five short questions on the application form. Good questions are about the work, and answerable in a few sentences by someone who has done it:

• "Tell us about a time you had to choose between shipping quickly and doing it properly. What did you choose and why?"
• "What is the most complex thing you have built with [your stack]? What would you do differently?"
• "Our booking flow has to handle two people trying to reserve the same slot. How would you approach that?"

Tell applicants the expected length ("two or three sentences is plenty"). Mark a question optional when a good candidate might reasonably have nothing to say.

Some questions do not belong on any form: age, nationality, family, health, and salary history among them. They are not about the work, and in many places asking them is unlawful.

Step 4: read applications against the must-haves

When applications arrive, read each one against your must-haves list, one requirement at a time. For each must-have, note whether the applicant says anything about it, and what they said. This does two things. It makes you consistent across candidates, and it makes it obvious when you are being swayed by something that is not on the list.

Resist the temptation to have software score or rank candidates for you. A "78% match" is a made-up number that feels objective. Automated screening of job applicants is also regulated in several places: New York City's Local Law 144 requires a bias audit and candidate notice before an automated employment decision tool is used, and the EU AI Act treats AI systems used for recruitment as high-risk. Tools that help you read are fine. Tools that decide for you carry real obligations.

Aim to reply to every applicant within a week, including a short no.

Step 5: one conversation, one paid sample, one decision

For the candidates who meet the must-haves:

1. A 30- to 45-minute conversation. Talk about the work they described in their answers. Ask what they would do differently. Explain the role honestly, including the parts that are hard. Let them interview you. A booking link saves a round of email here.
2. A small, paid work sample. A few hours, on something close to real work, paid at a fair rate. It tells you more than any puzzle, and paying for it shows you respect their time. If you cannot pay, a technical conversation walking through their own past code is the next best option.
3. A decision within a few days, written down with the reasons, against the must-haves.

For a first engineering hire, it is worth one reference call with someone who worked with them directly.

If the whole thing runs from posting to offer in about two weeks, you will keep candidates who have other options, and you will have spent a few focused hours a week rather than a month of distraction.

Doing it in Atrix AI

Hiring in Atrix AI follows this process, and it is built to stay out of your decisions.

• The posting is written from what you are building. Give the role a title and engagement type, add the pay if you have it, and attach the product it is for. The agent reads that project's PRD and architecture document and drafts the whole advert: a one-line summary, the posting, must-haves, nice-to-haves and screening questions about the actual work. It is instructed never to invent pay, perks or team size, and never to ask about age, nationality, family, health or salary history. You edit the draft and publish it yourself.
• Applications come in on a public form and land on the role in your workspace.
• Reading, not scoring. For each of your must-haves, Atrix can quote what the applicant wrote about it in their answers, in their own words, and say plainly when they wrote nothing. It does not score, rank or recommend candidates. You read and decide.
• Interviews in context. With scheduling, meetings you schedule from an application, or link to it, show up on that application, so the conversation, the notes and the candidate stay together.

The short version

Decide what the role needs before you post. Write a posting that states the work, the must-haves and the pay. Ask questions about the work, read answers against the must-haves, and finish with one conversation and one paid sample. Start with the job description template, and keep the whole process under two weeks.