If I Had To Build a Tech Team from Scratch, Here's What I Would Do, and Ask Each Engineer.

No recruiters, or special tools, or advanced techniques. Simple questions.

They say hire slow. I say hire right.

Most founders build teams like they’re decorating an office.

Plenty of titles. Too many meetings. Not enough output.

Things feel fine. Until nothing ships.
Until the team talks process, not problems.
Until burn climbs and the roadmap drifts.

If I had to do it again. If everything vanished and I had to start from scratch. I wouldn’t reach for job titles or slide decks.

I’d start with spine.

How I’d Start

I wouldn’t start with resumes. I’d start with risk.

A founder who builds in urgency but hires in fear gets two things.
Code that rots.
Trust that cracks.

I’ve seen it.

The team grows.
Then fractures.

They hire the resume.
The brand name.
The one who interviews well. But disappears when decisions get made.

Nothing ships.

Great founders ask the right questions.

What danger are we willing to face? Can we move fast, knowing we’ll fix it later? Or must we get it perfect the first time—because failure isn’t an option? Are we building to scale or just trying to survive the next storm?

The answers define everything.

I hire for spine. Not talent or pedigree. Spine. Someone who can tell me I’m wrong and not blink. Someone who can say, This won't work. Here’s why. You can train skills. You can’t install guts.

I hire for capitalistic grit. People who want to win. People who don’t just code, they think in terms of leverage. They want ownership. They ask about margins. They’d build a company if they weren’t building this one.

I hire constant learners. Engineers who read RFCs, not summaries. People who understand how HTTP works. Not just users of the web, but craftsmen of it. Give me someone who asks why, not someone who memorizes the syntax.

I want engineers who touch every part of the product. Not specialists.

I hire for outcomes, not process. Not the ones waiting for Jira to tell them what matters, or the ones who move only when told.

I hire the ones who move because the problem is in the room. They can’t sit still.

The ones who work for the fee, not the hour. They bet on themselves. They know their worth. They know they’re part of a system.

I ask them sharp questions. Not about syntax. I’m looking for the fracture—the story that hurts. The silence they won’t explain. I want to know what they broke, and what broke them.

Here’s what I ask:

"Tell me about a technical decision you regret."

I want the scar. I want the weight of it. A misread tradeoff. A lesson that hurt. If they don’t carry a mistake, they haven’t built anything real.

"What’s a hill you’d die on in software architecture?"

Not the right answer. Just a real one. Something they’ve fought for. Something they’d fight for again. That tells me everything.

"When did you overbuild something? Why?"

Overengineering is fear with a keyboard. I want the truth. Was it pride? Was it comfort? Was it hiding? Do they know the cost?

"How do you know when to delete code?"

Code is currency. Held too long, it becomes debt. Deleted at the right time, it becomes power.

Chaos Reveals Character

"What would you build if I gave you a week and no direction?"

Some freeze. Some drift. Some start moving before the question ends.

That’s the one I want.

Because startups don’t come with manuals. They come with chaos. And the right hire doesn’t need perfect specs to start solving.

When you’re interviewing, give them ambiguity on purpose. See what they do with it. Do they clarify? Do they build? Do they wait?

Then I stop talking. I listen. I let the silence do its work.

I don’t care where they went to school. I care how they think when something breaks. Whether they ship. Whether they adapt. Whether they see the edge before it hits them.

Most founders want perfect teams. I want working ones. Lean. Focused. Sharp.

Builders who care more about the outcome than the method. Who finish before the kickoff call ends. Who move because the problem is in the room.

Avoiding the Wrong Hire

What I wouldn’t do?

I don’t hire people who prop their feet up, miss the mark, then promise to do better.

Then call it a retrospective. I call it a red flag.

Retrospectives don’t fix a hire who won’t take ownership. Startups don’t have cycles to waste on lessons that should’ve been instincts.

I want people who talk with their cameras on. People with ideas. Engineers who show up inspired. Who don’t wait to be told. Who get shit done.

The ones who document by default. Who don’t let a pull request linger for a week. Who see a broken test and fix it without being asked.

I want the weekend warrior. The tinkerer. The one who takes things apart just to see what’s inside.

Who builds bots for fun. Who reads documentation on a Saturday—not to get ahead, just to understand.

If you’re hiring, ask them what they built that no one told them to. Ask what they’re learning right now, and who it’s for. Ask what problem in your company they’d solve first, and why.

You’ll learn more than any resume could tell you.

Startups can’t afford to get this wrong. One bad hire tilts the whole system. One wrong foundation means rebuilding later.

So I stay sharp. I trust slow. I hold the bar high.

Build it right, and you don’t have to build it twice.

But if I do, I’ll build it like this.