Define what they should deliver in 90 days
Write a one-page role brief before posting the job. Name the system they will own, the problem they must solve, who they will work with, and what they can decide without approval.
For example, "Own checkout reliability. In the first 90 days, investigate duplicate orders, implement and test a fix, and document how to diagnose failed payments." That gives you something concrete to discuss in interviews. Choose a goal that fits your actual system and staffing.
Separate skills needed on day one from skills someone can learn. If the job is mostly debugging an existing backend, prioritize evidence of debugging production systems. Familiarity with every library in your stack can wait.
Publish the terms before the first call
Include the compensation range, employment or contract arrangement, location restrictions, required overlap hours with a named time zone, and any on-call or travel expectations. List the interview stages and their time commitments.
Explain how your team works today. If requirements often change or the new hire will be the only backend engineer, say so. Candidates need that information to decide whether they want the job.
Ask for people who have solved a similar problem
Send the role brief to engineers you trust. Ask, "Who have you worked with who could own this?" Give them the actual problem and budget so they can make a useful introduction. Apply the same evaluation process to referrals and direct applicants.
When reviewing applications, look for relevant responsibility. Ask candidates to choose one project they can discuss in detail. Accept a sanitized explanation of private work. A public GitHub profile should be optional.
Spend one interview on a real technical decision
Ask what the candidate owned, what went wrong, what they tried, and what happened after release. If they say they made an API faster, ask how they reproduced the delay, where the time went, and how they checked the fix in production.
Keep asking until you can explain their decision yourself. Record what they investigated, which alternatives they considered, and how they verified the result. If an answer stays vague, mark that part as unverified.
Run a paid exercise with a hard time limit
Use a small example related to the job. For a backend hire, provide an endpoint that creates duplicate orders on retries. Ask them to reproduce the bug, propose or implement a fix, and describe how they would test simultaneous requests.
Set a limit such as 90 minutes, including a short written handoff. Use the same task and criteria for each candidate. Provide setup instructions in advance, answer questions, and stop at the agreed time. Use a disposable project that does not contribute free work to your backlog.
State whether documentation and AI tools are allowed. If those tools are part of the job, let the candidate use them and ask them to explain and verify the result. Judge the work they can account for.
Check whether their handoff lets someone continue
Ask the candidate to write what changed, what remains uncertain, and what the next engineer should check. A useful handoff might say, "Sequential retries now return the existing order. Concurrent requests still need a database constraint. Run the concurrency test before shipping."
Check whether you can act on the message without another call. Evaluate clarity and completeness. Do not use accent, writing polish, or replies outside agreed hours as a proxy for engineering ability.
Make the hiring decision against written criteria
Before interviews begin, agree on the evidence required for problem solving, code quality, verification, written communication, and the responsibilities in the role brief. Have interviewers record evidence independently before the debrief.
Use "demonstrated," "missing evidence," or "concern," with a specific example for each judgment. Resolve an important gap with one focused follow-up. Ask permission before contacting references, then ask how the person handled missed estimates, blockers, and feedback.
Prepare access and a first task before day one
Assign an onboarding partner. Prepare repository access, a working local setup guide, a test account, and the steps for deploying safely. Grant the access needed for the first task, with someone available to fix permission problems.
Choose a small change they can take through review and release. Name the reviewer and write down what done means. At the end of the first week, ask where they lost time and assign owners to fix those problems.
Agree on how work moves across time zones
Keep each task in one shared place with its owner, expected behavior, acceptance checks, and dependencies. Record decisions beside the task so the next person can find the context. Name someone who can answer questions during the agreed overlap.
Use a short end-of-day update when a teammate needs a handoff. Include what changed, the next step, and any blocker. A blocked update should name the decision or person needed. Agree on when to escalate and how quickly the team will respond.
Set a review expectation, such as the next working day, and arrange backup coverage when the reviewer is away. Separate urgent production incidents from routine messages. Define on-call coverage instead of expecting everyone to remain reachable all night.
Review delivery and give specific feedback
At the end of the first month, review shipped work, unresolved defects, blocked tasks, and the support the engineer needed. Compare progress with the role brief and adjust goals when the original assumptions were wrong. Lines of code and online status do not tell you whether a change works.
Give feedback when the issue happens. "This change shipped without checking retries; add that check before the next release" gives someone an action. "Be more proactive" leaves them guessing.
Schedule follow-ups at 60 and 90 days. Give the engineer ownership of a defined area as they learn the system, and ask which approvals they can take over. If delivery is slow, inspect unclear requirements, review delays, and missing access alongside their work. Fix the specific cause you find.