The most consequential review of Nishant Hooda's early career may have happened without a manager, a scorecard, or even a meeting. He was an intern at Amazon Web Services, working on testing infrastructure. Another intern nearby, Boris Skurikhin, had been given a similar problem with similar constraints. Hooda looked at Skurikhin's solution and reached a disarming conclusion: Boris had designed it better.
There are several possible reactions to discovering that the person beside you has out-thought you. Envy is traditional. Hooda chose curiosity. The pair began talking about infrastructure tradeoffs, failed startup attempts, and whatever else surfaced on runs to Chipotle. Five years later, they were in San Francisco building Docket, a company devoted to the same species of problem that had put them near each other in the first place.
Docket tests software. This sounds like a modest occupation until a team has watched a release stall because its automated tests are behaving like a nervous antique. A label changes, a button moves, a selector points to yesterday's interface, and the suite that promised confidence delivers maintenance. Hooda and Skurikhin had felt that drag while building products across Stripe, Brex, Citadel, and Patreon. Their response was to make a test pay attention to what a person pays attention to: the screen.
The co-founder in the next chair
Hooda's route to that AWS internship ran through the University of Waterloo, where he began a computer science degree in 2017. His public work history lists a sequence of internships beginning in 2018, including GitHub, AWS, and Shopify. His GitHub account preserves an appealingly unruly drawer of earlier projects: a Swift library for fitting text into labels, paired rider and driver apps modeled on Uber, a Java word game from high school, and a PID controller meant to stabilize a quadcopter using an Arduino Uno.
The projects are small fossils of a builder learning in public. They also make the later career legible. Hooda joined Brex in 2021 and worked with procurement and growth teams, then moved to Stripe's API Services team in 2024. By April 2025, his own site listed his job simply: building Docket, AI for test automation.
The founding partnership grew from evidence rather than networking choreography. Hooda had seen how Skurikhin approached a constrained technical problem. Skurikhin had seen Hooda's appetite for companies and the lessons that came from attempts that did not work. Their relationship contained a useful prehistory before equity, titles, and a domain name arrived to complicate it.
Your Boris might be sitting beside you today - pay attention.Nishant Hooda, on meeting his co-founder as an intern
Four versions of a founder
Docket's acceptance into Y Combinator did not come with the tidiness of a single application and a cinematic phone call. Hooda has written that it took four applications and four interviews. He presented the sequence as four versions of himself as a founder, which is more revealing than treating rejection as a ceremonial obstacle placed before inevitable success.
One earlier company was Prest, software intended for investment bankers. After being told that the product did not address an important enough problem, Hooda and his co-founder widened the ambition. Prest shifted toward AI search for investment-banking deal rooms. Comparable companies were attracting attention, and the new pitch looked fundable. It also looked familiar. The next rejection identified the flaw: the team had no powerful, differentiated insight for a crowded field.
The persistence chart / one interview at a time
Hooda's retrospective is admirably unsentimental. The team had tried to resemble companies it admired instead of identifying what it knew. His compact verdict was that founders cannot copy their way to insight. They earn it by talking to users and iterating. Application four finally worked, though the idea in that application was not the product Docket ultimately pursued.
That detail rescues the story from becoming a formula. Persistence was necessary, but persistence did not mean clutching the same pitch with greater force. The applications changed. The founders changed. The eventual company returned them to a problem they knew in their hands: tests that take too long to write, break when interfaces change, and ask engineers to choose between shipping quickly and maintaining coverage.
You can't copy your way to insight. You have to earn it.Nishant Hooda, reflecting on a rejected YC application
Teaching a test to see
Traditional end-to-end tests often depend on selectors, the identifiers that scripts use to find elements on a page. This can be precise and useful. It can also be brittle. Rename the element, rework the page, or introduce an awkward canvas or iframe, and the test may lose the plot while the human user sees a perfectly obvious button.
Docket's current approach is vision-first across web, iOS, Android, and desktop. It can record the screen coordinates a person would click, adjust when an element moves, and bring in AI-driven steps for flows whose state changes. The company describes tests that can be expressed in ordinary language, run in parallel, fit into continuous integration, and stay aligned with actual user behavior.
What changes when the interface moves?
The practical wager: let the automation inhabit the interface more like its human user, while keeping runs repeatable.
The distinction is less about attaching AI to a familiar category than changing the test's object of attention. People use screens. Test scripts have traditionally used the underlying handles that engineers provide. Docket is betting that watching the same surface as the user creates a more durable route through changing software.
By 2026, the company said it had run more than one million vision-driven test actions. Its public customer material describes Docket validating acceptance criteria from Jira, running a multi-module regression suite in under thirty minutes, and navigating long branching forms without selectors. These are company-reported results, but they reveal the practical yardstick. The product is judged on maintenance avoided and feedback delivered before a release, not on whether an agent can produce an impressive isolated click.
The discipline of fewer words
A second craft runs through Hooda's founder notes: editing. For Y Combinator's Demo Day, the team had sixty seconds to explain Docket. They spent weeks tightening the script and removing anything that failed to move the story forward. Hooda came away asking the same question of a pitch, a feature, or a Slack message: can this be said with less?
Concision fits a founder who learned through repeated applications. Every unnecessary sentence creates another place for a reader to become confused. Every borrowed market phrase can conceal the missing insight underneath it. Editing is not merely a presentation skill in this account. It is a way of discovering whether the thought itself has finished cooking.
That instinct also appears in his personal writing. In October 2025, after three months spent learning about browser agents, Hooda published an essay about how agents and people might share the internet. He separated online activity into three layers. Human presence belongs in places where participation carries the value: a friend's wedding post, a live community joke, a Wikipedia digression. Authenticity matters where a specific voice and reputation are the point. Utility work, including research, paperwork, comparison shopping, and software testing, is where agents can plausibly do the browsing.
Docket lives squarely in that utility layer, but the essay is not a victory lap for automation. Hooda worries about scraping, attribution, author compensation, and whether the provenance of a human voice survives when an agent mediates the encounter. He is building a machine to remove browser labor while asking which parts of the web should remain recognizably human. The combination is healthier than uncomplicated enthusiasm.
The useful kind of repetition
Hooda's career has a loop in it. Testing infrastructure introduced him to Skurikhin. Product work at larger technology companies exposed both founders to the cost of brittle tests. Repeated startup and accelerator attempts forced them to distinguish imitation from earned knowledge. Then Docket brought those threads back together in a product built around a complaint they had made themselves.
Even the company's premise contains a loop: run the test, notice where the interface moved, and keep the test aligned instead of repeating the same maintenance mistake. Hooda has praised a similar discipline for coding agents, where corrections become written rules reviewed at the next session. The attraction is consistent. A system should learn enough from friction that tomorrow's work does not begin at yesterday's error.
There is no need to varnish the lesson. Four applications are not proof that every fifth attempt works. A better co-founder's design is not automatically the beginning of a company. Vision does not make every test simple. What Hooda's record offers is narrower and more useful: notice capable people, preserve the lessons inside rejection, and return to problems that have followed you across jobs.
Software testing will never make for a romantic object. It exists because buttons misbehave, forms wander, interfaces change, and humans are gifted at finding the one path nobody rehearsed. That drabness may be precisely why it suits Hooda's story. He and Skurikhin are not trying to make the test glamorous. They are trying to make it look in the right place, recover when the furniture moves, and quietly let everyone else keep building.