Side-stepping the Secretary Problem, unwittingly

Recorded: Sept. 22, 2026, 6 p.m.

Original

Summarized

Side-stepping the Secretary Problem, unwittingly.

λ blog

lob

⇒ feed

code

⏿ talks

☙ cv

[in]

✉ mail

≈ me

» now

WIP public β » Project

"Writing for nerds".

Side-stepping the Secretary Problem, unwittingly.

[ ↓ toc ]
Published: 2026-03-20
Updated: 2026-03-22
By: Aditya Athalye

Having played both parts in the kabuki play that is employee-employer matchmaking, I feel the way we play it is a zero-sum game. I wish it were not so. When this post started life in 2024, as a wall of text chat message, it was brutal out there, on both sides of the software industry interview table. The ZIRP had ended. As of 2026, post-ZIRP reality has properly set in and remains bad ("AI" is a Fig Leaf (Enterprise Edition) for structural damage they self-inflicted, and if you look at Hyperscaler GPU depreciation schedules, they are making it order-of-magnitude worse). Set to that backdrop, here is a hopefully hopeful hiring anecdote where I think we avoided the so-called "Secretary Problem", framed within Optimal Stopping Theory. It can be done. Non-zero-sum hiring ought to be default-mode for any industry, AI or no AI.

✉ email me comments
» share →
[bsky]
[in]
[HN]
[lobste.rs]
[reddit]

Email:

|| Get RSS feed.

Tags:
#riff#organisation_design#hiring#clojure#culture#whyto#meta

Contents

The Secretary Problem
Story of bypassing the Secretary Problem
Immediate and five-year outcomes
Direct outcomes
Indirect outcomes
The One, actually Several, Weird Tricks
Getting Lucky
Refusing to copy the Zero-sum FAANG Hiring Loop Playbook
Running a tight, humane hiring loop: Max 24 hour SLA. Always Be Kind.
Footnotes

Author's non-apology-cum-warning: Various versions of this screed have befallen various people...
… since—gulp, where did time go?—about 2015. This current version befalling your XML/RSS feed is 2024 vintage, and has also befallen others via acts of copy-pasta into gist/slack/zulip/discord. Since nobody has boo'd it yet, and I'm not sorry (yet), it hereby gingerly enjoins the public discourse.
Memory fades fast. So, take what is useful, discard the rest.
And yes, I love em dashes. Deal.

The Secretary Problem

"How many applicants do you need before you find the right one? One? Five? The entire community, every time? :laughcry:"
— A fellow slacker in the Clojurians Slack.

The asker isn't joking. Any proposal to use unfamiliar technology, especially programming languages like Clojure inevitably triggers managerial hand-wringing about the hiring pool.
And what could cause more Managerial Hand Wringing than than trying to hire in a niche of a niche… You see if you can go back to 2014 and find QA people, in Pune/India, willing to learn to read and write Clojure code, to help backend engineers test a rather large SaaS, written in Clojure?
I got to know of the so-called "Secretary Problem" 1 in the ensuing discussion. The problem statement is used to study Optimal Stopping Theory. It sets up a recruiting scenario, and explores how to maximize the odds of selecting the best applicant. It has been a fun rabbit hole to explore.
Story of bypassing the Secretary Problem
A key constraint of the secretary problem is Once rejected, an applicant cannot be recalled.
Once upon a time, my colleague, Mayank, and I violated this unknown-to-us constraint, in our otherwise-conventional tech hiring loop by:

Not only explicitly keeping the door open for re-applications, after a cooling-off period.
But also offering to help people learn stuff we were interested in hiring for, on an opt-in basis. We would send people curriculum and make ourselves available for office hours on a fixed weekly schedule, to those who showed interest in learning.

Over about late 2013 through 2014, him and I were hiring for programmers for our QA team (which was him and I :) at helpshift.com, a Clojure-happy startup. We wanted curiosity-driven people with enough technical proficiency that we could teach and train, because we were writing test tools and suites in Clojure. Not to mention all sorts of impractical to automate manual testing of our systems, which demanded some baseline capacity to wade through reams of technical manuals and documentation, and the desire and ability to learn and use our cli tools, scripts, and configurations, if not craft them.
We knew the tester-programmer combo is a tough ask in the first place, especially in India, where the hiring pool is almost entirely filled with manual-only testers 2. So we had braced ourselves for a noisy pipeline.
In this context, I figured it would be crazy to lose anyone with potential. In my previous career, as a business manager, I had seen companies lose candidates with exactly the right life experiences, but the wrong degree or pedigree or test score. So I spitballed the idea to offer reapplication + opt-in support. My colleague loved the idea, and so it was.
Luckily, the company culture was already about "nontraditional" hiring, looking for diamonds in the rough, so to speak 3. And since we didn't have an HR function, the two of us were left to our own devices.
In hindsight, having to go through HR, however supportive, would have been horrible because we would have had to compromise by saying something like "Oh so sorry this time, but you are part of our candidate pool and we will be in touch, pinky promise. Later. You can also try to reapply after six months".
Having known such rejection emails, and the following perpetual silences as well as black holes of re-application, I read those types of rejection emails as garden-variety weasel-wordy ass-coverage. Benign self-deceptions, at best. Be real… nobody from your org is ever going to follow up on that. And if I have no signal about why someone would listen to me again after a mere six months, I, the hopeful candidate, will not waste time re-applying. So don't set up those expectations.
Immediate and five-year outcomes
Direct outcomes
Over the year or so that we ran our interview loop;

We landed five hires out of about 300 inbound.
Each person became productive quickly (about a month) in our corner of the little open plan office. Three lapped up Clojure, two moved to mobile SDKs (installed base of 2 Billion devices as of 2017).
Each of them further grew way beyond our expectations and moved to other roles like back-end development and product management, when a company-wide re-org did away with a discrete QA function.
A pretty good retention rate, for VC-funded high-growth startups… All of our people became tenured staff (four to ten years each).

Indirect outcomes
Every single such hire further converted their input into fast-growth startup careers in-house, and elsewhere, as well as startups of their own.
Most of the credit for career growth and retention goes to the engineering culture built and nurtured by all of m'colleagues.
Hiring people with potential is critical, but it's only the beginning. All the work they did, actively helped these early hires acquire professional skills that helped them step out and do what they are doing.
We also indirectly hired at least one kickass engineer (who also became tenured), because of the good word-of-mouth our approach earned (which we did not anticipate, but it happened). He was blown away by the learning support we offered his wife, whom we had screened, who opted into our office hours, and whom we didn't end up hiring.
The One, actually Several, Weird Tricks
Getting Lucky
With 20/20 hindsight, I wonder if our approach would run into some HR or legal quagmire (Like, would it creat an implied commitment to hire if <criteria> are met, and if we don't then would we run afoul of some arcane labour law?). Anyway, we just did it because we could, and I'm glad we took our chance. I wish this was the default way to hire.
Refusing to copy the Zero-sum FAANG Hiring Loop Playbook
Common experience is that typical recruiting funnels yield one final offer/acceptance for every 10 applicants (in that ballpark). This suggests that in a global market, if everyone uses typical recruiting methods—"We have 5 rounds because <insert FAANG> has 5 rounds; which is proof that it is best practice."—the small fry will always lose to the big fish because you simply cannot allocate enough resources to absorb the damage of such an abysmally noisy pipeline.
Said another way, the main problem of normal hiring practice seems to be that, we play it like a zero sum game even though it is an adverserial game.

We have no objective standard to determine observed quality.
We don't usually know the n a-prioiri… how many applicants should we assume constitute our applicant pool for a given role?
The applicants do not reach us with uniform probability, and we cannot interview them all with the benefit of hindsight.

Running a tight, humane hiring loop: Max 24 hour SLA. Always Be Kind.
This one choice, I will take credit for being firm about at the outset, having hired people before, and having been fully convinced of speed as a core value of hiring, by Kayak's erstwhile CEO, Paul English 4. His "SLA" is seven calendar days (not seven business days) from getting to know about the existence of a candidate, to making a firm offer.
We got accustomed to receiving "Thank You" emails in response to "Regret" emails we sent out after people had passed through three of our four to five step filter pipeline (nb. a "step" in this filter pipeline does not equal "one to several hours long interview stage"). I attribute this mainly to our turn-around times, and clear communication. Any recruiter reading this, please meditate on this fact of life.
Here is an assorted recollection of the collection of rules we cooked up and/or evolved over the year we ran our loop:

Set clear communication expectations with candidate: We promised a max 24 hours turn-around time to candidates. We explicitly asked them to ping us if they did not hear within 24 hours. 5
Never ghost anybody. We both hate being ghosted in any sort of communication, not just hiring. Hearing a quick "no" is much, much better than hearing a "yes, but" after three months of being strung along multiple interview stages.
Ruthlessly protect our own brain-cycles:

Context is King. Route all communication through the ATS. Immediately create a note of the "why" of our vote/decision at each stage for each candidate. Just like good commit message hygiene. If by-chance either one of us spoke with some candidate out-of-band, we would immediately drop a note in the ATS. A dedicated browser tab was always open on both our laptops.
Synchronous calls and/or on-site interviews cost us heavily, by interrupting our own ongoing QA work. Ensure we always do these last, and always individually. This forced us to figure out early on precisely what to communicate, what our stage-by-stage checklist should be, what signals to look for, how to set up our templates and stages in the ATS, how to register votes etc.
Run all individual phone calls by a playbook for that call. Terminate the call early if it is going badly. Have a practiced, clear, and kind way to end it. Having the "open door" policy helps. So does having a structured Q&A + decision-rubric for each question.
Keep tuning our workflow for maximally async communication and decision-making criteria. Our mutual, written-down, check-listed clarity helped us independently decide and act within seconds and minutes–vote / reject / move forward—of noticing some change in the ATS.
Be diligent about our 24 hour communication SLA. Slow turn around times create piles of "candidate inventory" that force us to stop what we are doing and attend to the queue. In a fast-paced startup this never happens because everything is always on fire, and so candidates languish in ghosting-hell.

Protect their time:

Much of this benefit to candidates falls out of protecting one's own brain cycles.
Additionally, waiting for replies sucks for candidates. Therefore, never give out coding assignments that take candidates hours to do, because it is a burden on their time, and it also means we need hours of careful reading to review the code. Large coding assignments are horrible signal-to-noise ratio tools. Any coding assignment should be a fifteen-ish minute job for the career level of the candidate. Because as soon as they send it in, a reviewer will know in one look whether to issue a reject, or what to ask them next. By default, our immediate request would be to refactor the solution using a totally different design.
Some copying was assumed. Being transparent and up-front about said copying was demanded. A clearly-stated deal-breaker and firing criterion, to the candidate—if we ever learned at any point that they copied stuff and didn't disclose it (yes, even after they were hired and working full-time).
In practice, code review turn around time of minutes often let us make go/no-go decisions fully async within the same day. This is just concurrent programming 101.
As you will see this also feeds back into "ruthlessly protecting our brain cycles". It's great when these two mechanisms feed-back positively into each other.

Prize written communication and reading comprehension:

All primary screening over email, including the coding assignment, Q&A about the coding assignment, and refactoring of the solution.
All emails would require the person to think about something relevant to that stage and provide us a short written answer.
Our very first email would enumerate potential deal-breakers the candidate should consider for themselves. Such as, mandatory requirement to learn Clojure programming, potentially arriving a rung or two lower in a reporting hierarchy ("programmer" instead of "manager"), ballpark compensation budget, growth and promotion prospects, on-call expectations, strictness of per-commit code review culture etc… Little aspects of live culture that add up and have people say "no". (nb. We were not allowed to disclose salary band and compensation up-front, but I firmly believe disclosing this would be best practice. Promising candidates drop out at salary negotiation, which is an incredibly expensive place to lose them.)

Filter for initiative and curiosity:

Dig for legitimate self-driven study and project work, of any shape or form. Github portfolios and personal websites are not automatically-good signals. They are entry points to the digging.
Try to understand the "why" of the candidate. What animates them? Craft interview questions appropriately.
Offer "office hours" support to all maybe-yes candidates that we said "no" to.

Async decision-making protocol:

Only two "Yes" votes progresses to the next stage.
One Yes, one No = Reject (Two nos = Obviously Reject).
Both votes must be registered in the ATS within 24 hours.
Immediately send +2's to the next stage. Whichever of us registered a second +1 immediately chose an email template we had crafted for the purpose, in the ATS. We also fixed templates on the fly and/or created alternate versions for subtly different responses needed at the given stage. No mutual permission necessary.

Err on the side of false negatives:

After our rounds, we would chat for a few minutes and pass on only those we felt "hell-yes" about, to the "CXO interview and offer stage".
Our open-door policy let us say no safely, and quickly, to "oooh, almost… aaalmost there" candidates, because our approach respectfully held the door open to them to surprise us (and themselves) at any time thence.
We would often use the first-contact phone call to coach away people. Make them really think about why they are changing roles. Not infrequently it is because they had not even considered trying to change their situation at the current job. Prompting people to exercise initiative is a good thing. We wanted people who would not be the silent suffering type, because that way lies stagnation and decay. We wanted to have a professionally satisfying workplace. That means deliberately overcoming friction, and discomfort. If they really tried, and it didn't work out, then they knew our door was always open to talk again. (This feeds back into protecting their time + brain cycles and ours.)

This is all for now. I hope it helps someone out there. I'd love to discuss this, over email.
_\\// Live Long, and Prosper.
Footnotes

To quote the wiki page for the Secretary Problem:

The secretary problem demonstrates a scenario involving optimal stopping theory that is studied extensively in the fields of applied probability, statistics, and decision theory. It is also known as the marriage problem, the sultan's dowry problem, the fussy suitor problem, the googol game, and the best choice problem. Its solution is also known as the 37% rule. … The question is about the optimal strategy (stopping rule) to maximize the probability of selecting the best applicant.

↩︎
As far as I can tell, most of the talent pool works at IT services companies, where they tend to gravitate toward managerial roles because that is the main way to succeed in IT services. This trend spills over into product-based companies too, because that is the de-facto industry norm. Sadly, testing jobs are low status here (which blows my mind; rant for later). "Technical" people run away from the "QA" or "Tester" label, and testers tend to actively avoid "technical" roles—it is legitimately too much work for too little payoff. Consequently, entry-level testers don't have career incentive to master programming, and experienced ones would rather be managers than hands on practitioners. This is not to ding anyone—one has to put food on the table, and a job is a job—it's just how things were, and probably still are.↩︎
We had no choice, really. Pune city is full of IT service companies, but almost no software product culture. So, its hard to find people crazy enough to take large pay cuts, eighty hour weeks, and no prospects of managerial growth, in exchange for borderline-vapourware stock options. No, this is not a city of such believers.
It was not in the 2010s, and not today. Bangalore (now, Bengaluru) was the place even back then. Now, more so; the kind of atmosphere that sustains regular monthly Rust meetups, despite the ongoing peak AI meetup frenzy. IYKYK.
'ooru, the kind of coffee culture where not a few months ago, in 2025, a junior barista at a pretty normal Starbucks breezed past my bar-stool perch, did a double-take and asked me if I was a DevOps person. My terminal screen was open, with some stacktrace. Under-caffeinated, I fumbled my answer and asked "Oh, are you a DevOps person too?". Too quickly, and with a bright smile, he answered "Oh no Sir, Data Science." The raw speed of his reply awoke me to my place in the pecking order.
BLR, the playground of SaaS (now AI) dreamers, where eavesdropping in popular coffee shop chains, surfaces hiring pitches, VC pitches, LP pitches, stand-ups, retrospectives, product sales pitches; doing so in the selfsame brand-name coffee shop chains in Pune routinely yields college homework discussions (it's a student town), middle-aged friends and family gossip, snoozefest dates, the occasional arranged marriage family meet and greet, and plenty of Multi-level Marketing pitches. Three-people-to-a-little-round-table configurations. Hapless victim being "Introduced" to an "entrepreneurship opportunity" that will save them from their dead-end service jobber life (yes, this sort of thing is actually the opening pitch). The Introducer a.k.a. leech-in-progress. Introducer's "boss" / uber-leech / authority figure.
Although, not to dunk on my otherwise-cromulent home city too much… Since the ZIRP era came into its own, it has been really hard to tell the two species of snake-oil sales people apart. Almost everyone in both groups seems to be playing the rug-pull game… Who will be the poor sod left holding the bag at the end of the game? And, on more than one occasion the Pune-local eavesdropping paid off somewhat. I did end up referring a few smart, self-driven, ambitious undergrad programmers to m'colleagues at Pune-local startups, for internships. Of course, being smart, self-driven, and ambitious, they self-moved to Bangalore for full-time jobs afterwards. GenZ knows where the money at.↩︎
Episode 101: Masters of Scale Always be recruiting: Kayak’s Paul English https://mastersofscale.com/paul-english-always-be-recruiting/

Paul English, co-founder of travel search platform Kayak, guides us through five critical lessons for the hiring journey. As you’ll hear, English is passionate and relentless about the subject of recruiting – and the scale of the stakes.

↩︎
This never happened. We were both diligent about upholding our SLA—at every step of our pipeline for every single candidate. Most received same-day responses. Everybody received at-most next-day responses. Meanwhile, our pace at work did not stop or let up and we were not putting in extra hours on account of our additional hiring responsibilities. We were both busy working through some pretty hairy QA problems, given how sophisticated, and fast-changing the Helpshift SaaS application was (tons of big-enterprise business requirements). Two examples:

Testing business logic using DSLs in Clojure (youtube.com) - by Mayank Jain

Testing business logic quickly becomes tricky, as applications grow and scale. Example based unit and integration tests, and exploratory tests become poor choices to check and verify a large state space. Also such methods are not well-suited to clearly describe the state space / transitions we want to test.
Since we use Clojure to write test suites and tools at Helpshift, we tried experimenting with DSLs to express some of our testing problems. We've found that mini DSLs can indeed become useful to describe and test fairly complicated business logic.
In this talk I will cover some of the mini-DSL approaches we've tried, demonstrate one of them by example, and discuss the benefits and drawbacks based on current experience.

Designing an Object-Functional system with Clojure (youtube.com) - Aditya Athalye (PDF Slide deck.)

↩︎

↑ toc
↑ title
↑ menu

✉ email me comments
» share →
[bsky]
[in]
[HN]
[lobste.rs]
[reddit]

Email:

|| Get RSS feed.

Built with
shite,
GNU Emacs,
org-mode, and 🖤.

My
newsletter
is powered by
Buttondown.

Want to become a better programmer?
Join the Recurse Center!

The author explores how to move beyond the traditional, zero-sum nature of hiring by applying concepts from Optimal Stopping Theory, specifically referencing the Secretary Problem, to create a more humane and successful candidate selection process. This approach is presented as a way to foster non-zero-sum hiring, suggesting that hiring should be fundamentally different across all industries.

The foundation of the author's experience stems from a specific hiring cycle involving programmers for a QA team at a Clojure-focused startup. The standard constraint of the secretary problem—that rejected applicants cannot be recalled—was deliberately violated to foster a more open environment. The authors achieved this by explicitly keeping the door open for re-applications and offering opt-in support, including providing curriculum and office hours for candidates interested in learning the required skills. This process was undertaken with the understanding that perceived rejections often lead to silence, leading the authors to advocate for candid communication rather than setting expectations that might later prove misleading.

The direct outcomes of this non-traditional approach were substantial. Over the course of the interview loop, the group successfully landed five hires from approximately three hundred inbound applicants, with each hire demonstrating rapid productivity. Furthermore, these employees grew beyond initial expectations, transitioning into roles such as back-end development and product management following organizational realignments. The overall success underscored the indirect benefits: the nurturing of an engineering culture and the development of professional skills among the hires contributed significantly to their subsequent career growth and retention. The method also fostered a positive indirect outcome, leading to the unintentional hiring of another highly capable engineer due to the strong word-of-mouth generated by the supportive hiring methodology.

The author critiques the common industry practice, specifically the FAANG hiring loop, arguing that typical recruiting funnels yield low conversion rates, suggesting that the standard process often plays like a zero-sum game despite being adversarial. The central problem identified is the lack of objective standards for quality measurement, unknown applicant pool sizes, and non-uniform probability of applicant responses.

To counteract this, the author proposes a methodology centered on a tight, humane hiring loop emphasizing speed, kindness, and meticulous process design. A key element of this loop involves setting clear communication expectations, such as a maximum twenty-four hour service level agreement for responses, and establishing an absolute commitment to never ghost candidates. The process necessitates the rigorous protection of the hiring team's cognitive resources by prioritizing asynchronous communication and clear decision-making criteria. This involves utilizing Applicant Tracking Systems to document the rationale for each decision at every stage, ensuring context is maintained.

The process design advocates for specific interactions with candidates. Coding assignments should be brief, focusing on immediate, demonstrable knowledge, often requiring candidates to refactor solutions rather than extensive, time-consuming tasks, thereby enabling rapid, asynchronous code review. Screening communications must focus on eliciting relevant written responses, asking candidates to consider cultural aspects, compensation expectations, and career trajectories upfront. The process also emphasizes filtering for initiative and curiosity by seeking out legitimate self-driven projects and offering targeted support, such as office hours, to candidates who may be borderline fits.

The decision-making protocol is strictly asynchronous: only two positive votes must progress to the next stage, and both votes must be registered promptly. This structured protocol, combined with a willingness to err on the side of false negatives, allows the team to safely reject candidates while maintaining an open-door policy, enabling candidates to explore other opportunities if not selected. The philosophy ultimately seeks to move away from purely transactional hiring toward a dynamic environment that values candidate potential and sustained engagement.