How to find a founding engineer for the work you need next

To find a founding engineer, begin with the product work an early engineering hire would actually own. Explain what exists, what must change and which decisions the person can make. Then look for relevant hands-on experience and investigate the contribution behind it. Give candidates a realistic picture of the work and support before asking them to commit to an early role.

For this guide, founding engineer means an early hands-on engineering hire at a young company. It does not automatically mean cofounder, executive or sole owner of every technical decision. The name can start a conversation, but the assignment must carry it. A person should not discover after joining that the attractive title concealed several different jobs and no agreed priorities.

Describe a product problem someone can investigate

Write down the next useful product change from the user’s perspective. Perhaps people can complete a task in a demonstration but struggle with ordinary exceptions. Perhaps the product works for one customer while changes for another require repeated manual intervention. These are hypothetical situations, not diagnoses of every early company. Explain the actual evidence in your business before listing preferred technologies.

Show what is already built and who understands it. Identify the parts that are dependable, experimental or waiting for a decision. A candidate needs to know whether the assignment concerns creating a first working version, improving an existing product or taking over work from another team. Each starting point calls for a different conversation about responsibility and support.

Include the work surrounding a new feature. Who clarifies the customer need, reviews the implementation and responds when something breaks? Do not describe the role only through visible launches. The person may need to understand existing behavior and help maintain it while building something new. State what you expect and invite questions about what the proposed scope leaves out.

Choose the relationship before relying on the title

A cofounder conversation concerns a broader shared commitment to building the company. An engineering hire concerns an agreed role within it. A specialist assignment can address a defined technical problem without becoming either relationship. Our technical cofounder guide covers the first of those decisions. Use it if you are seeking a founding partner rather than presenting a job under several names.

Describe who sets product priorities and who can resolve a disagreement about the approach. A hands-on engineer can contribute valuable judgment without being expected to absorb every leadership responsibility. If the company also needs technical direction beyond your experience, identify how that support will be provided. A title does not supply a review process or a person to consult.

Explain the proposed working arrangement and the conditions still being decided. Do not substitute enthusiasm, possible future ownership or an ambitious title for an actual offer. The relevant people should review and agree the terms before work begins. This article does not prescribe compensation, ownership, employment classification or contract language.

Find people through work that relates to your problem

Start with former collaborators, trusted builders and professional communities where relevant engineering work is visible. Ask for a specific recommendation: the kind of product, the current stage and the responsibility you need someone to own. A generic request for a brilliant developer gives a connector little basis for judging relevance or interest.

Public projects and technical explanations can also provide discovery leads. Ask what the person contributed and which decisions they made. A useful project may have several authors, borrowed components or constraints that are not obvious from a demonstration. Read it as the beginning of an assessment, not proof that the person can perform every engineering task your company might eventually need.

As checked in October 2026, Y Combinator’s software engineering jobs page lists roles at its startups. It is one example of a startup-specific discovery route and a way to examine how opportunities are described. This guide does not verify every listing, suggest every role is a founding position or imply that every company can recruit through that service.

Ask for an account of decisions, not a stack of labels

Invite the engineer to explain a relevant piece of work from the original problem through its operation. What did they personally build? Which tradeoffs mattered? What changed after real use? Ask what they would approach differently now. An honest explanation of a limitation can be more useful than an impressive result with the surrounding conditions removed.

Discuss maintenance and handoffs. How did another person understand the work? How were problems investigated? What remained difficult to change? You are looking for evidence about the job your company needs, including the less visible work after a feature appears. Avoid treating a confident explanation of fashionable tools as a substitute for that account.

Respect confidentiality. A redacted example, public project or hypothetical discussion can reveal reasoning without exposing a previous employer’s code or customer information. Ask what can legitimately be shared. If your own technical knowledge cannot support a critical assessment, involve a qualified reviewer and define the question they should evaluate. Do not turn unfamiliarity into a guess about competence.

Make the working discussion resemble the real assignment

Choose a bounded situation connected to the role. For an invented scheduling product, the discussion might concern what happens when a customer changes an appointment after another person has already acted on it. Ask which information the engineer would need and how they would investigate the current behavior before proposing a solution.

Listen to the questions as well as the answer. Does the person identify an assumption? Can they explain a tradeoff to a nontechnical colleague? Do they distinguish an immediate correction from a wider redesign? The purpose is to understand the working approach, not reward someone for guessing the architecture you privately prefer.

Keep any exercise proportionate and agreed. A conversation about public material can reveal judgment without requiring a usable product for free. If real project work is proposed, agree the scope and terms first. Avoid a sequence of increasingly useful unpaid tasks presented as an informal way to get acquainted.

Show the conditions the engineer would inherit

Explain who can provide user context, product decisions and technical help. Describe how priorities change and how urgent problems are handled. If the founder is the only source of information, say so and discuss how access will work. Responsibility without a dependable route to an answer can leave an early hire waiting while appearing to have broad autonomy.

Be open about dependencies. Another supplier may maintain part of the product. A customer commitment may constrain the next change. A planned capability may not exist yet. A candidate needs enough accurate context to assess the work, while private information should remain protected until it is appropriate to share it through the agreed process.

Separate building the product from running all surrounding business work. Our operator guide addresses ongoing coordination and ownership. If the immediate need is a defined AI investigation, the AI collaborator guide covers that narrower assignment. Clarifying adjacent roles makes the engineering opportunity easier to understand.

Agree what the first assignment should clarify

Write a short account of the initial product problem, the engineer’s responsibility, available support and the decision expected after the first piece of work. Ask the candidate to correct your understanding. A useful discussion may reveal that you need a different level of experience or a smaller assignment before making the role workable.

AME learns what people are building, what they bring and what they need, then makes purposeful introductions one at a time. Builders are among its intended audience. If a relevant builder is the next person you need to meet, apply for AME 1000. The introduction begins the assessment; the responsibility, evidence and working arrangement still deserve a careful conversation.