Accidentally Avoiding the Secretary Problem

Published: 2026-03-20 | Updated: 2026-03-22 | Author: Aditya Athalye

Having occupied both sides of the hiring table, I've come to view the "matchmaking" process between employers and employees as a choreographed kabuki play—and usually, a zero-sum game.

When this piece began as a dense chat message back in 2024, the software industry was in a brutal state. By 2026, the "post-ZIRP" (Zero Interest Rate Policy) reality has fully crystallized. Current trends suggest that "AI" is often just an Enterprise Edition fig leaf used to mask self-inflicted structural damage; if you analyze the depreciation schedules of Hyperscaler GPUs, the situation is likely an order of magnitude worse.

Against this bleak backdrop, I want to share a hopeful anecdote about hiring. It's a story of how we inadvertently bypassed the "Secretary Problem" by applying a different lens to Optimal Stopping Theory. I believe non-zero-sum hiring should be the standard for every industry, regardless of the AI hype.

---

⚠️ A Note of Caution

Various iterations of this rant have already circulated via copy-pasted Gists, Slack threads, Zulip, and Discord. Since no one has booed me off the stage yet, and I remain unapologetic, I am now officially releasing it into the public discourse.

---

Understanding the "Secretary Problem"

Whenever a team proposes using a niche technology—specifically functional languages like Clojure—management typically panics about the "hiring pool."

The Ultimate Managerial Nightmare:

Imagine trying to find QA engineers in Pune, India, circa 2014, who were not only willing to learn Clojure but could actually write it to help backend engineers test a massive SaaS platform.

This challenge led me to the Secretary Problem, a classic exercise in Optimal Stopping Theory. The goal is to maximize the probability of picking the single best candidate from a pool.

Mathematically, the optimal strategy suggests rejecting the first $n/e$ candidates to establish a baseline, then picking the first person who exceeds that baseline.

$\text{Optimal Stopping Point} \approx \frac{1}{e} \approx 37\%$

---

How We Broke the Rules

The Secretary Problem relies on one rigid constraint: Once a candidate is rejected, they cannot be recalled.

My colleague, Mayank, and I accidentally violated this rule during our hiring loop at helpshift.com (a Clojure-centric startup). Instead of a hard "no," we implemented a more fluid system:

• Open-Door Policy: We explicitly told candidates they could re-apply after a designated cooling-off period.
• Opt-in Education: We offered to help candidates learn the skills we were looking for.
• Structured Support: We provided a specific curriculum and held weekly "office hours" for those interested in leveling up.

The Context: The "Tester-Programmer" Unicorn

Between 2013 and 2014, Mayank and I were the entire QA team. We needed people driven by curiosity who possessed enough technical aptitude to be trained in Clojure. We weren't just looking for automation; we needed people who could:

1. Navigate dense technical documentation.
2. Use (and eventually build) CLI tools and scripts.
3. Handle the "impractical" nature of manual testing in a complex system.

In the Indian market at the time, the pool was dominated by manual-only testers. Finding a "tester-programmer" was a tall order. I realized that discarding anyone with raw potential was a mistake. I had seen too many business managers reject perfect candidates because they lacked a specific degree or a prestigious pedigree.

Avoiding the "HR Black Hole"

Fortunately, our company embraced "nontraditional" hiring. Because we lacked a formal HR department, we avoided the standard corporate scripts. If we had gone through HR, the rejection would have looked like this:

"We appreciate your interest, but we've decided to move forward with other candidates. However, you are now part of our talent pool and we will be in touch soon! Pinky promise!"

To a candidate, those are just weasel-words for "you'll never hear from us again." Without a clear signal on why they should return in six months, a hopeful applicant won't waste their time re-applying.

---

The Results: A Non-Zero-Sum Outcome

Direct Impact

We processed roughly 300 inbound applications and made five hires.

Indirect Impact

The long-term ripple effects were even more significant:

• Career Trajectories: These hires transitioned into backend development, product management, and eventually launched their own startups.
• Culture of Growth: While the engineering culture provided the nurturing environment, the initial act of hiring for potential was the catalyst.
• The Magnet Effect: Our reputation for providing learning support attracted other top-tier talent. We hired one exceptional engineer who joined specifically because he was impressed by our commitment to candidate growth.

Final Thought: Hiring for potential is only the first step; the real work is building a culture that allows that potential to flourish.