How to Evaluate a Startup Before Accepting an Offer
Ask founders about traction, runway, cap table, and equity benchmarks before considering salary.

Advertisement
Most engineers evaluating a startup offer start with the wrong question. They look at base salary first, when base salary is the least useful number on the page.
The regret pattern that follows is consistent. An engineer sees a strong headline number, joins the company behind it, and discovers months later that the equity is worthless, the learning environment is thin, and the resume line does little for the next job search. Three losses, not one, and all three were visible before the offer was signed. A startup offer is a system: base, equity grant, strike price, refresh policy, bonus target, and company stage, and each piece changes what the others are worth. Salary comparison alone can't capture that interaction, so the right evaluation starts with the company itself, in a fixed sequence, long before the compensation math gets touched.
Reading traction signals before the pitch deck convinces you
Founders are trained to tell a story about where the company is going. The more useful conversation asks for evidence about where the company already is.
Evidence looks different depending on stage. At pre-seed, the standard is paying customers who'd be genuinely upset if the product vanished tomorrow, signed letters of intent, a retention curve that holds up over time, or a waitlist with documented conversion from signup to use. A thousand names on a waitlist means little next to ten customers who would notice and complain if the product disappeared. Headcount on a list is not traction. Usage, payment, and retention are.
Ask founders directly who their most engaged users are and how many of them there are. A founder who can't answer that question has given the answer anyway: the traction isn't there yet, or no one has measured it closely enough to say. This exchange cuts both ways. Companies run background checks and reference calls on candidates as a matter of course, and a candidate evaluating a startup has the same standing to ask about the company's product history that the company has to ask about a candidate's work history. How a founder responds to a direct question about traction, whether with specifics or with a redirect back to the vision, previews how that founder communicates when the news is bad. That pattern tends to hold.
How to ask the runway question
Once the product looks real, the next question is whether the company survives long enough for that to matter. Runway isn't a sensitive internal number reserved for board meetings; it's a basic input any candidate needs to size the risk in an offer, and asking about it deserves the same normalization engineers already give to asking hard questions about system architecture or technical debt in an interview.
Ask it directly: how many months of runway does the company have at its current burn rate, and what milestone is that runway meant to buy? Both halves of the question matter. A number of months without a milestone attached is just a countdown with no context for what happens at the end of it. A credible answer names the current monthly burn, the number of months that burn rate supports, and the specific revenue or product milestone the company expects to hit before the money runs out. Anything short of those three pieces is a partial answer, and partial answers on a question this basic are their own signal.
The target is 12 or more months of runway after the hire date, or a clear and credible path to the next funding round. The reasoning is mechanical: equity is worth nothing if the company doesn't survive long enough for it to vest. Standard vesting runs four years with a one-year cliff, so no equity vests at all during that first year. A company with only a few months of runway at the time of hire may not make it to the cliff, in which case the equity portion of the offer never existed in any functional sense. This is arithmetic that belongs in the same conversation as salary and title.
What a cap table tells you about your equity's real value
A company surviving long enough to succeed is a necessary condition, not a sufficient one. The next question is whether success actually benefits the shares the engineer is being offered, and that depends on the cap table.
An equity percentage is a position inside a structure, and that position either pays out or gets diluted into nothing depending on the structure. Four questions decode it: What is the fully diluted share count? How large is the option pool, and was it set before or after the company's last valuation? How much equity have the founders kept for themselves? And do any investors hold liquidation preferences, and at what multiple?
That last question carries more weight than it first appears to. A smaller equity grant at a company with a clean cap table can be worth more than a larger grant at a company already stacked with 2x liquidation preferences, because those preferences get paid out before common stockholders see a dollar. Founders with nothing to hide will walk a candidate through this structure without hesitation. Founders who deflect or get vague about the cap table are signaling something about how they'll treat equity holders generally.
Dilution is a structural certainty: every future funding round reduces the percentage held by existing shareholders, and a founding engineer who assumes the company never raises again is modeling a company that, realistically, doesn't grow. The way to make this legible is to ask for the raw inputs and do the math directly: the number of shares in the actual grant, the total shares outstanding, the most recent preferred share price, and the vesting schedule attached to all of it. A grant that can be modeled with real numbers is worth more than a headline percentage that can't be checked against anything.
Equity benchmarks and the salary trade-off engineers need to price honestly
With the structure understood, the next step is comparing the actual numbers on the offer against the market. Equity benchmarks at the early stage have moved as AI talent competition has pushed grants upward, and knowing the current range is what keeps an engineer from accepting a thin grant that gets framed as competitive.
Founding engineer equity benchmarks for 2026, based on Pave data, is a fraction of a percent at the median and climbs toward low single digits at the high end. Those numbers describe founding engineers specifically. An engineer joining as employee 30 at a Series B company should expect a fraction of those figures, since hire sequence compresses grant size quickly. Earlier hires at the pre-seed stage, who are typically taking a deeper pay cut to join, can reasonably target the higher end of the founding-engineer range. Later hires joining after a seed round sit closer to the lower end.
The salary side of the trade-off deserves the same direct arithmetic rather than a vague sense that early-stage pay runs low. Founding engineer salaries typically sit well below market rate, and if that gap runs to a meaningful sum each year over a four-year vest, the engineer is effectively paying that cumulative total for the equity received in exchange. Ask whether that same amount of cash, offered as a check to invest in this specific company at its current valuation, would still seem like a good bet. Median total compensation for US software engineers splits broadly across base, equity, and bonus, and the base figure is the least informative part of that split. Funding stage, the strike price on the equity, and the company's refresh policy for future grants do far more to determine what an offer is actually worth than the salary line does on its own. Late-stage companies pay a real premium over early-stage companies for engineers at equivalent seniority, and that premium reflects the market's price on certainty, not a verdict on which path produces a better career.
The honest way to frame all of this is probabilistic: early-stage equity is worth zero in most outcomes. The sound evaluation approach is to assume the equity lands at zero and ask whether the cash and the experience justify the offer on those terms alone. If the answer is yes, the equity becomes genuine upside. The one combination to avoid entirely is a deep salary cut paired with a thin equity grant, since that captures the downside of both bets with the upside of neither.
How to diligence the founders and the team as seriously as the product
Compensation structure is only half the evaluation. The people an engineer will work with for the next two to four years shape career trajectory as much as the equity does, and most candidates spend far less time checking this than they spend checking the cap table.
Founders reveal a great deal in how they disagree with each other in a room with a candidate present. Disagreement style under low stakes, in an interview setting, tends to predict behavior under real pressure later. Ask what happened to people who've already left the company. Both the content of the answer and the way it's delivered, whether direct or evasive, carry information. Back-channel former colleagues when possible. Founders routinely run reference checks on candidates, and the reverse check is just as legitimate: founders who diligence candidates should expect to be diligenced in return.
Learning velocity depends on the specific people in the room, not on company size or funding stage in the abstract. A small startup with a strong staff engineer or CTO already on the team can be one of the fastest places to learn in a career. A small startup where the new hire is immediately the most senior technical person in the building can produce the opposite: bad habits reinforced at scale, with no one around to correct them. The right question is who, specifically, the engineer will learn from over the next stretch of time, and whether that person has actually been met face to face before the offer is signed.
One test ties this together: for any role under consideration, ask what the resume looks like in three years if the outcome is good, and ask the same question for a mediocre outcome. If the good-outcome answer is strong but the mediocre-outcome answer is illegible to a future hiring manager, the risk in the role is lopsided in the wrong direction.
Red flags in the offer process itself that signal how the company operates
The offer process is itself a sample of the company's behavior. A company that moves fairly and clearly with a strong candidate tends to run its product and its operations the same way, and a company that can't manage that during an offer often can't manage it elsewhere either.
Several specific patterns in an offer process are diagnostic rather than normal startup chaos: refusal to discuss runway when asked directly, a salary significantly below market with no equity strong enough to offset it, equity promised verbally instead of in writing, an option count given without the corresponding percentage of the fully diluted total, an undisclosed exercise price, a grant that hasn't been formally approved by the board, a title that implies authority the role doesn't actually carry, or a history of delayed payroll. Any one of these is worth a direct follow-up question before moving forward.
Vesting mechanics deserve scrutiny beyond the standard four-year schedule with a one-year cliff. The default 90-day post-departure exercise window is a common trap: it forces a departing engineer to come up with a five- or six-figure cash payment within three months of leaving or forfeit all vested options outright. Asking for an extended exercise window, five to ten years, is a reasonable request, and a growing number of founder-friendly startups accommodate it without pushback. Acceleration terms on acquisition, whether single-trigger or double-trigger, matter for founding engineers, since unvested equity is what's exposed in an early acquisition.
Flexibility around remote work, title scope, or role ownership that a company offers verbally costs nothing to put in writing if it's genuinely part of the offer. Reluctance to commit any of it to paper is itself the signal.
Running the full evaluation as a sequenced decision, not a gut check
The most common mistake in this entire process is doing the compensation math first, getting excited about a number, and only then checking whether the company clears the bar that would make that number meaningful. The sequence should run in the opposite direction.
Start with traction: does the company have real customers and real usage, evidenced by something more concrete than a waitlist count? Move to runway and milestone clarity: does the company have enough time on the clock for equity to actually vest? Then examine the cap table: if the company succeeds, the engineer's specific position in that structure either benefits from it or sits behind preferences that absorb the upside first. Fourth, diligence the founders and the team: will this specific group of people produce real learning and real career capital, independent of how the financial outcome plays out? Fifth, benchmark the compensation: does the offer reflect market rates for the stage, role, and level, and is the cash-for-equity trade-off one that holds up under honest arithmetic? Sixth, read the offer process itself: is the company's behavior during the offer consistent with how it claims to operate day to day?
The probabilistic resolution ties the whole framework together. Treat the equity as upside that may well land at zero. Evaluate the offer primarily on cash and learning. Use the cap table math to confirm that the floor of the offer, not its ceiling, is one worth accepting. An engineer who runs this sequence in full is being specific about which startup, at which stage, with which team, and that specificity turns a startup offer into a calculated bet an engineer can take with real confidence.


