Scrolls
6 min read
On this page

What to Look For

Your first engineering hire is not a staffing decision. It is a culture decision. The first three engineers set the tone for every engineer who comes after. Their habits become the team's habits. Their standards become the team's standards. Their attitude toward shipping, quality, and ownership becomes the company's engineering culture.

Hire wrong and you spend months managing, correcting, or eventually replacing. Hire right and your capacity multiplies. The difference between a great first hire and a mediocre one is not 2x. It is 10x.

Here is what actually matters.

Generalists Over Specialists

Your first engineer will need to do everything. Frontend, backend, database, deployment, debugging, customer support, documentation. There is no one else to hand things off to.

A specialist who is excellent at React but has never touched a database is a liability at this stage. A generalist who is good at React, decent at PostgreSQL, comfortable with infrastructure, and willing to learn whatever is needed is invaluable.

Specialist profile (wrong for early startup):
- Deep expertise in one area
- Uncomfortable outside their domain
- Wants clear role boundaries
- Expects supporting infrastructure
- Best in: large teams with defined responsibilities

Generalist profile (right for early startup):
- Competent across multiple areas
- Comfortable with ambiguity
- Willing to do whatever needs doing
- Can learn new tools quickly
- Best in: small teams where everyone does everything

The first engineer at Stripe was not a payments expert. They were a generalist who could build web applications, handle infrastructure, and figure things out. Payments expertise came later, when the team was large enough to specialize.

Skills your first hire needs:
Must have:
- Can build and ship features end-to-end
- Comfortable with your primary language and framework
- Can debug production issues
- Can set up basic infrastructure (deploy, monitoring)

Nice to have:
- Experience with your specific domain
- Strong frontend or backend specialty
- DevOps experience
- Mobile development experience

Does not matter:
- Knowledge of specific enterprise tools
- Certifications
- Formal CS education (correlated but not required)
- Experience at FAANG companies

Self-Starters Over Direction-Followers

In a startup, there is no project manager. There is no product manager. There is no tech lead assigning tasks. There is a list of problems, a vague priority order, and the expectation that engineers will figure out what to do.

Your first hire needs to be someone who sees a problem and fixes it without being told. Someone who notices the deploy process is manual and automates it over a weekend. Someone who finds a customer bug in the support queue and ships a fix the same day.

Self-starter signals:
- Built side projects without external motivation
- Contributed to open source
- Previously started a company or freelanced
- Can describe decisions they made independently
- Asks "what should I work on next?" rarely
- Instead says "I noticed X was broken, so I fixed it"

Direction-follower signals:
- Waits for detailed specifications before starting
- Asks for permission before making small decisions
- Wants a ticket for every task
- Uncomfortable without clear requirements
- Needs regular check-ins to stay productive

This does not mean self-starters are better engineers in general. Direction-followers thrive in structured environments with clear processes. But startups are not structured environments. You need someone who creates structure, not someone who requires it.

Interview technique: ask candidates about a time they identified and solved a problem nobody assigned to them. The best startup engineers have multiple stories. If they struggle to find one, that is a signal.

People Who Ship Over People Who Plan

Some engineers love planning. Architecture diagrams. Technical specifications. Evaluation matrices for every technology choice. Research spikes that take two weeks.

Planning has its place. But in a startup, the most valuable skill is the ability to ship working software to real users. Not perfect software. Working software.

Shipper profile:
- Defaults to action
- Ships a rough version, then iterates
- Comfortable with imperfection
- Measures progress by what users can see
- Makes reversible decisions quickly
- Gets energy from seeing things in production

Planner profile:
- Defaults to analysis
- Wants to get it right the first time
- Uncomfortable shipping rough work
- Measures progress by code quality
- Wants consensus before deciding
- Gets energy from elegant architecture

Both are valuable. Shippers are more valuable at your stage.

Dropbox's early engineering culture was built around shipping. Drew Houston has talked about how the first team prioritized getting features in front of users over getting them perfect. The perfectionism came later, when they had 100 million users and the cost of bugs was higher.

How to evaluate shipping ability: ask candidates to walk you through something they built recently. How long from idea to production? What shortcuts did they take? Are they comfortable with those shortcuts? Someone who shipped in a week and is pragmatic about the trade-offs is more valuable than someone who spent three months perfecting a side project.

The Culture Multiplier

Your first three hires create the engineering culture by default. Not through documents or presentations. Through their daily behavior.

Culture is set by:
- How the first engineers communicate (Slack, in-person, async)
- How they handle disagreements (debate, defer, escalate)
- What they consider "done" (shipped vs polished vs documented)
- How they respond to bugs (panic vs pragmatic)
- What they work on when not told (customer pain vs technical interest)
- When they work (sustainable hours vs crunch culture)
- How they treat non-technical colleagues (collaborative vs dismissive)

If your first hire is someone who stays until midnight and expects others to do the same, that becomes the culture. If your first hire is someone who works focused hours and ships consistently, that becomes the culture.

Be intentional about this. You are not just hiring a person. You are hiring a template.

Hire for Ability to Learn

Technology changes. Frameworks come and go. The specific tools your startup uses today might be different in two years. Hiring for current knowledge of a specific framework is short-sighted. Hiring for the ability to learn quickly is durable.

Learning ability indicators:
- Has picked up new languages or frameworks in previous roles
- Can explain concepts in unfamiliar domains
- Asks good questions during technical discussions
- Comfortable saying "I don't know, but I can figure it out"
- Has a history of adapting to new environments quickly
- Side projects in different languages or domains

Knowledge-focused indicators (less valuable early):
- Deep expertise in a single technology
- Can recite API details from memory
- Strong opinions about the "right" way to do things
- Uncomfortable with unfamiliar technology
- Resists changing tools or approaches

A great signal is what happens when you ask a candidate about something they do not know. Do they get defensive? Do they try to bluff? Or do they get curious and ask follow-up questions? The latter is what you want.

Netflix's hiring philosophy famously prioritizes curiosity and learning ability. Their early engineering hires were not experts in streaming video. They were smart generalists who learned streaming as they built it.

The Best Source: Ex-Startup Engineers

Engineers who have worked at early-stage startups before are disproportionately likely to succeed at your startup. They know what they are signing up for. They know the chaos, the ambiguity, and the context switching. They have done it before and chose to do it again.

Why ex-startup engineers are the best hires:
- Understand the startup pace and trade-offs
- Comfortable with ambiguity and changing priorities
- Have worn multiple hats before
- Self-selected for the startup environment
- Can onboard quickly (they have done it before)
- Realistic expectations about equity, salary, and role

The risk with engineers from large companies is culture shock. An engineer from Google is used to extensive documentation, clear team boundaries, established tooling, and slow release cycles. The transition to a startup where they are the documentation, the tooling, and the release cycle can be jarring.

This does not mean you should never hire from big companies. But if a candidate has only worked at large, established companies, probe deeply for their ability to operate in an unstructured environment.

Where to find ex-startup engineers:
- Your personal network (best source by far)
- YC alumni community (if applicable)
- Startup-focused job boards (Wellfound, YC Work at a Startup)
- Indie Hackers and startup communities
- Open source contributors
- Former freelancers and consultants
- Twitter and Bluesky tech communities

The Technical Evaluation

Traditional coding interviews (LeetCode, whiteboard algorithms) are poor predictors of startup performance. They test for a specific type of problem-solving that rarely appears in day-to-day startup engineering.

Better evaluation methods for startup hires:

1. Paid trial project (best signal)
   - 4-8 hours of real work on your codebase
   - Compensate at contractor rates
   - See how they approach a real problem
   - Evaluate code quality, communication, speed

2. Portfolio review
   - Look at their GitHub, side projects, writing
   - Ask them to walk you through design decisions
   - Evaluate: did they ship? Is the code reasonable?

3. Practical technical conversation
   - Discuss architecture for a real problem
   - "How would you build X feature for our product?"
   - Look for pragmatism, trade-off awareness, speed bias

4. Pair programming session
   - Work on a real problem together for 60-90 minutes
   - Evaluate: communication, problem-solving approach, speed
   - Observe: do they ask good questions? Do they get stuck?

What to avoid:
- LeetCode-style algorithm questions (irrelevant signal)
- Take-home projects over 4 hours (disrespects their time)
- Whiteboard system design for systems they will never build
- Brain teasers (no signal at all)

Reference Checks That Matter

Standard reference checks ("Would you hire them again?") are useless. Everyone says yes. Ask specific, behavioral questions.

Useful reference check questions:
- "Can you describe a time they shipped something under pressure?"
- "How did they handle ambiguity or changing priorities?"
- "What kind of work did they gravitate toward without being asked?"
- "What was their biggest weakness in a startup context?"
- "How did they react when a project they built was thrown away?"
- "Would you want them as your co-founder?"

The last question is the most revealing. If the reference hesitates,
that tells you something important.

Common Pitfalls

Hiring for pedigree. A Google engineer is not automatically a good startup engineer. The skills that make someone successful at Google (navigating large codebases, working within established systems, deep specialization) are different from startup skills.

Hiring someone just like you. Diversity of thought matters. If you are a backend engineer, your first hire should probably be stronger on frontend. If you are a planner, hire a shipper. Complementary skills multiply the team's capability.

Ignoring culture fit. Technical skill is necessary but not sufficient. Someone who is brilliant but difficult to work with will poison the culture you are trying to build. At three people, one toxic personality affects everyone.

Moving too fast. Desperation leads to bad hires. A bad hire costs 3-6 months (hiring, onboarding, realizing the mistake, managing out, hiring again). Taking an extra two weeks to find the right person is always worth it.

Over-indexing on experience. A senior engineer with 15 years of enterprise experience might be less effective at your startup than a hungry engineer with 3 years of startup experience. Match the experience to the environment.

Key Takeaways

  • Hire generalists who can do everything, not specialists who excel at one thing.
  • Self-starters who ship working software are worth more than planners who design perfect systems.
  • Your first three hires set the engineering culture. Be intentional about the template you are creating.
  • Ability to learn trumps current knowledge. Technology changes; adaptability is permanent.
  • Ex-startup engineers are the best candidates. They know what they are signing up for.
  • Evaluate with practical work, not algorithmic puzzles. Paid trial projects give the best signal.
  • Take the time to hire right. A bad first hire is one of the most expensive mistakes a startup can make.