The interview lasted four hours and twenty minutes. There was no whiteboard. There was no system design round. The CTO bought me an espresso and asked me to walk through the most recent piece of code I had been proud of, and the conversation went from there. By the end of the afternoon I had an offer in writing, on a napkin, with a base number and an equity number and a one-line job description. I had given notice to my big-tech employer six weeks later. I want to write this loop up because the reverse-path interview (big-tech engineer joining an eight-person early-stage startup) is graded on a different rubric than any standard loop, and I had to do real work to figure out the rubric in real time.

The loop was at a pre-Series-A startup in the developer-tooling space. I had been at a senior IC role at a big-tech company for four years and a mid-level role at a different big-tech company for three years before that. The startup was eight people, no product-market fit yet, runway of about 14 months when I was interviewing. I joined as the seventh engineer. The decision to leave big-tech was the harder problem; the interview was a small part of it.

What the interview was actually grading

The CTO told me, about ten minutes into the conversation, what they were grading. Their phrasing, paraphrased: "We are looking for someone who can join the company without being managed for the first year, who can pick problems out of the work that is in front of us and ship them, and who is genuinely excited about the problem space rather than the comp band. We are not testing your algorithms. Your last seven years are sufficient evidence on that. We are testing whether you can self-direct in an environment where there is no clarity."

That framing reorganized how I thought about the rest of the conversation. The big-tech rubric I had walked in carrying (clean code, defensible system design, a thoughtful behavioral story) was not the rubric. The rubric was: do you have agency, will you stay agentic when the work is ambiguous, and will you stop being agentic when the work is too ambitious to ship. None of those were things I had practiced articulating.

The four parts of the conversation

The interview, retrospectively, had four distinct parts. The CTO did not announce them. They flowed.

The four phases of an early-stage interview (retrospective)
  Part 1   Code walkthrough -- 45 min, walking through GitHub repos I had picked
  Part 2   Problem-shape conversation -- 60 min, the company's current problems
  Part 3   Self-direction probe -- 60 min, hypothetical "first 90 days" projects
  Part 4   Decision conversation -- 60 min, them selling me, me selling them

The code walkthrough was the part I had prepped for. I walked the CTO through three repos I had pushed in the last year, with a deliberate spread: a mature open-source contribution (small, but to a project most engineers would recognize), a finished side project (a domain-specific scripting tool, about 2k LOC), and a half-finished side project (a learning-driven build of a simple distributed lock service, where the README explicitly said the project was unfinished and listed the open questions). The CTO spent the most time on the half-finished project. They specifically valued that I had shipped something with the unfinished parts called out, rather than polishing a thing into a smaller version of itself. That was the first signal I read about how they thought.

A small piece of the half-finished code that anchored the conversation:

// LockManager is a deliberately-thin wrapper. The leases are tracked in
// memory only; persistence is a TODO and the failure mode (lost leases
// on restart) is documented in the README.
type LockManager struct {
    leases map[string]*Lease
    mu     sync.Mutex
    clock  Clock // injectable for tests
}

func (lm *LockManager) Acquire(name string, holder string, ttl time.Duration) (*Lease, error) {
    lm.mu.Lock()
    defer lm.mu.Unlock()
    existing, found := lm.leases[name]
    if found && !existing.Expired(lm.clock.Now()) {
        return nil, ErrLocked
    }
    lease := &Lease{Name: name, Holder: holder, ExpiresAt: lm.clock.Now().Add(ttl)}
    lm.leases[name] = lease
    return lease, nil
}

The CTO read this for a minute, then asked: "Why is the clock injectable?" I said: "Because the failure modes that come from clock skew are the ones I want to test, and you cannot test them without a controllable clock." The CTO nodded once and moved on. That exchange, ten seconds long, was specifically called out in the offer-stage debrief as the moment they were sure they wanted to hire me. The signal was not the wrapper. The signal was that I had thought about the failure modes before they were forced on me.

The problem-shape conversation

The second hour was the CTO walking me through what the company was actually working on. This was the part of the interview I had not prepared for and where I had to do real listening. They described a customer-facing product that had three different user types, where the third user type was the one with the highest revenue potential but the lowest current traction, and where the product team was in a debate about whether to invest in the third user type or to double down on the first.

The CTO asked me, halfway through: "What questions do you have?" I had three good ones. The first was about the cost of acquiring user-type-three customers (specifically: was the bottleneck in marketing, in onboarding friction, or in the product not yet doing what they needed). The second was about the team's current capacity (specifically: how much of the engineering bandwidth was being absorbed by maintenance work on the existing product, versus available for new investment). The third was a question about a specific technical decision they had mentioned (a choice to use a particular database that I knew had a tradeoff curve I wanted to ask about).

The CTO answered all three. The third question, specifically, opened up a 20-minute sub-conversation about the database choice. They said afterward that the third question had been the thing that confirmed I was technically alive enough for the role. Most candidates, in their experience, asked the first two questions (which any candidate could ask) and not the third.

The self-direction probe

The third hour was hypothetical: "Pretend you joined Monday. What does your first 90 days look like?" I had not prepped for this question, and I gave an honest answer that I had been forming in real time during the previous two hours. The honest answer was that I would spend the first 30 days reading the codebase and the customer-facing documentation, with weekly conversations with each of the existing seven team members. I would not commit to a project until day 30. From day 30 to day 90 I would pick a single project that aligned with the user-type-three direction, scoped to be shippable in those 60 days.

The CTO pushed back: "Most engineers we have talked to want to ship something in the first two weeks. Why are you waiting until day 30?" My answer, paraphrased: "Because the projects that are obvious to ship in the first two weeks are usually projects that someone on the team has already decided not to do, or has already started. If I ship those, I am pulling resources from someone else's work. If I wait until day 30, I have enough context to pick a project that is mine, that no one else was going to do, and that produces a real signal about whether I am useful."

The CTO wrote that down, which was the first time I saw them write anything down in the conversation. They said later that this answer was the thing that flipped the conversation from a hire to a strong-hire.

The offer conversation and the decision that was actually hard

The fourth hour was the CTO selling me on the company and me asking the questions I needed answers to. The numbers were specific. The base salary was approximately 60% of my big-tech total comp. The equity grant was 0.8% of the company at the current valuation, vesting over four years with a one-year cliff. The CTO walked me through the dilution math, the cap table at the current and projected next-round valuation, and what the equity would be worth at three different exit scenarios (modest acquisition, IPO at a low multiple, IPO at a high multiple). They did not sell me on the high-multiple scenario; they specifically anchored the conversation on the modest acquisition scenario, which is where most early-stage equity actually lands.

The decision to accept was harder than I had expected. The big-tech role was clean: known comp, known projects, known team. The startup role was unknown across every dimension. I took six weeks to decide. The thing that closed the decision for me was specific: in my last six months at the big-tech company, I had been counting how many days a quarter I felt deeply engaged with the work. The answer was about ten days a quarter, and the rest was sustaining. Ten engaged days a quarter, at a comp level that allowed me to consider this kind of move, was not enough.

What the reverse path graded that the forward path did not

The interview at the early-stage startup graded for things that the big-tech loops I had sat (and conducted, on the other side) had not graded for. The two specific axes:

Reverse-path axes (what the early-stage interview was grading)
  axis                      what big-tech grades on    what early-stage grades on
  technical signal          standardized rounds        proof-of-shipping artifacts
  judgment under ambiguity  hypothetical scenarios     real-time conversation about
                                                       their actual current problems
  motivation                did you do your prep       are you specifically excited
                                                       about this problem space
  scope-fit                 level-band rubric          can you self-direct without
                                                       management for 12 months

The forward-path axes (what the big-tech rounds I had sat were grading) were calibrated against a large pool of candidates and a deep org structure. The reverse-path axes were calibrated against a small team's specific bandwidth and a specific set of problems they had in front of them. Neither rubric is harder than the other. They are different rubrics, and the prep that translates between them is the prep most senior big-tech engineers do not do because they have not had a reason to.

The practical implication for someone considering the reverse path: the standard interview prep does not transfer cleanly. The artifacts that matter are real artifacts (code you have shipped, projects you have led, problems you have explored deeply enough to have opinions). The judgment that matters is judgment about the company's specific situation, which you cannot prep in the abstract; you have to read and listen during the conversation. The motivation that matters is specific motivation, which you cannot fake. If you do not actually want to work on the company's specific problem, the reverse-path interview will surface that with high reliability, because the conversation is long enough and the CTO is paying close enough attention.