Side-stepping the Secretary Problem, unwittingly.

The Wayback Machine - http://web.archive.org/web/20260922024908/https://www.evalapply.org/posts/side-step-secretary-problem-hiring/index.html 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. 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 "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. 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.