How I Hire, Onboard, and Develop Great Engineers
Building a high-performing team is less about finding 10x engineers and more about creating an environment where talented people can consistently do their best work. Over the years I have learned that great engineering organizations are built one hiring decision, one onboarding experience, and one coaching conversation at a time.
In this guide I share the system I actually use: how I define the role before I post it, how I run a structured interview loop, how I onboard for momentum in week one, and how I develop engineers long after they are productive.
Hiring is a systems problem, not a gut-feel exercise
Every bad hire I have made shares one root cause: I skipped a step in the system because someone was likable, fast-talking, or came with an impressive résumé line. Every good hire followed the process end to end. I do not hire for the smartest person in the room. I hire for slope, not y-intercept. The y-intercept is what someone knows today. The slope is how fast they learn, how well they collaborate, and how much they raise the bar for everyone else.
I optimize for three things in every person: craft, ownership, and multiplicative impact. A wrong hire costs a team six months of velocity and morale. A missed good hire costs a few weeks of pipeline. That asymmetry shapes every rule below.
I write the scorecard before the job ad
Most hiring failures happen before the first interview. If I cannot describe what great looks like in the first 90 days, I will evaluate candidates on confidence, and confidence is a poor predictor. Before I open a requisition I write a one-page scorecard with the team.
If we cannot agree on the scorecard, we do not hire. I define the role around responsibilities and outcomes, not keywords. The technologies are tools for achieving those outcomes.
Real work, structured scoring, evidence before opinions
Unstructured interviews feel insightful and predict almost nothing. My loop is short, no more than four conversations, but every conversation has a single owner and a single job. I do not ask trivia or puzzles. Engineers have documentation, search engines, and colleagues. What matters is whether they can reason.
Three practices I hold to strictly. Same questions for every candidate at the same stage. Every interviewer scores independently against the scorecard before any group discussion, because the first vocal opinion anchors everyone else. And debriefs start with evidence, not impressions. A specific quote or behavior is data. A vibe is not.
My favorite question is simple: tell me about something you actually built, changed, or fixed. Then I keep going deeper. What was the problem. What options did you consider. What went wrong. What would you change today. I am looking for ownership signals, words like I identified, I proposed, and I owned the postmortem for, plus the ability to describe a time they were wrong. Everyone has one. The absence of an answer is the answer.
When in doubt I pass, and when I say yes I move fast
Great candidates have options, and the best ones disappear in days, not weeks. My rules are feedback on each round within 24 hours and a decision within one week of the final round. One question ends every debrief: will this person make the team better than we are today. If the answer is no, it is a no, even if they are brilliant.
The first 90 days are a design problem
A bad onboarding can set someone back six months. A great one creates momentum in week one. My heuristic is blunt: if a new engineer cannot open their first pull request within five working days, the problem is almost never the engineer. It is the process.
Every new hire gets a buddy who is not their manager, because people ask buddies the questions they are embarrassed to ask their boss. I tell the buddy explicitly that answering questions is the job that week, and I value it. I hold a weekly onboarding 1:1 for the first six weeks with one agenda: what is confusing, what is slower than it should be, and what did you learn this week.
At day 90 we retro the onboarding itself. The signal I look for is whether the person starts asking better questions. That is when they have internalized the system. And a new engineer’s confusion is a free architecture review. I schedule time to harvest it before it evaporates, because every question they ask becomes a documentation fix.
Growth is the retention strategy
Hiring is the easy part. Retention and growth is where management actually happens. Development is not an annual review exercise. It is the weekly work, and 1:1s are its operating system. Status belongs in async updates. The 1:1 is for the person: energy, blockers, and the one skill we are deliberately practicing this month.
I keep career conversations separate from performance conversations. Mixing them teaches people to hide their ambitions. And if an engineer’s growth path points outside my team, I support it. Engineers who see me invest in their future become my best ambassadors.
I measure my own hiring decisions too
If someone I hired struggles, I do not start with the conclusion that the person was simply not good enough. I ask whether I defined the role correctly, evaluated the right skills, gave enough context, and provided support and a path to succeed. Sometimes the hiring decision was wrong. Sometimes the onboarding was wrong. Sometimes I was wrong.
Every one of these was a process failure, not a people failure. That is the whole point of building a system: it catches me when I am too busy to catch myself. For the team-level version of the same discipline, my article on how I measure team performance covers scorecards, trends, and rollout.
Popular questions about hiring, onboarding, and growth
Q1How long should a hiring loop take end to end?
Aim for two to three weeks from first interview to offer. Longer loops lose strong candidates to faster-moving offers. Much shorter loops usually mean a skipped stage I needed.
Q2Should I use AI tools in hiring or onboarding?
Selectively. AI is useful for drafting job descriptions, structuring onboarding docs, and summarizing debrief notes. The interview judgment itself stays human, especially where hiring decisions may be subject to audit.
Q3What is the highest-leverage change a new manager can make?
Write the scorecard before the job post goes live. It is the cheapest fix with the biggest downstream effect on hire quality, onboarding speed, and debrief honesty.
Q4How do I onboard very senior versus very junior hires?
For a principal engineer I cut scaffolding and invest in context: architecture history, stakeholder maps, and past failed initiatives. For a junior hire I invert the ratio: more pairing, explicit expectations, and frequent check-ins so a broken environment never becomes a confidence spiral.
Q5What if I need to hire fast?
I would rather leave a role open for four extra months than make a bad hire. A mediocre hire consumes review time, lowers standards, and occupies a seat a great hire could fill. When I see strong signal, though, I move in days, not weeks.
Q6How do I reduce bias in interviews?
Structure the what, not the how. Same questions and same rubric for everyone, independent written scores before discussion, interviewers with different perspectives in every loop, and a designated skeptic empowered to make the case against hiring.
Q7How do I know onboarding actually worked?
At 30 days they are unblocked and understand the why behind the architecture. At 60 days they contribute independently on medium-complexity work. At 90 days they could onboard the next hire. If the 90-day answer is no, I address it immediately instead of letting it compound.
Q8How do I develop engineers who do not want to manage?
Through the technical track: architecture ownership, incident leadership, mentoring, and cross-team projects with real scope. Leadership starts long before a promotion, and a visible ladder lets people self-direct instead of waiting to be picked.
Hire for trajectory. Onboard for momentum. Develop relentlessly.
Hiring, onboarding, and development are one loop, not three processes. Clear scorecards make onboarding faster because expectations were never a mystery. Good onboarding makes development cheaper because trust and context already exist.
My output is not the team’s output. It is the capability of the team, compounding. And visible development of my people is the strongest hiring signal I can send, because word gets around.