One of the most crucial yet challenging activities for an early software startup is hiring the founding engineering team. If you follow the standard hiring process for engineers, you’ll gauge technical competency but fail to assess the vital attributes of a founding engineer: comfort with ambiguity, strong product instincts, and a sense of ownership/agency. After some early struggles with building the Speakeasy team, we stumbled onto a solution that had been hidden in plain sight. It was the process by which I myself had come to join Speakeasy as the first engineer – a week-long trial period as a full member of the team.
The Need For a New Method
Initially, it was easy to default to our collective experience of being on both sides of the interview process at larger engineering organizations. This resulted in assessing devs for “competency” by sampling their abilities through coding/system design exercises. The problem we identified with this approach was that it often failed to produce strong signals. Surprisingly, this was true in many instances regardless of interview performance.
As an early company, the whole team would have a round table discussion for each applicant we interviewed. But even upon the debrief of a compelling candidate who had performed well on our assessments, we were often left with the feeling of, “now what?” Even if we felt certain in the candidate’s technical ability, we lacked the comprehensive signal required to determine whether or not the candidate was someone who would meaningfully move the company forward. The questions we asked were too focused on what people “can do” and relegated us to assessing “how” they did it. What we needed to know was what they “will do” as an integral part of our team. Each founding engineer uniquely shapes the product and has an outsized impact on the success of the company, but we weren’t able to glean that from our interviews.
After reflecting on how strongly we’d felt about one another when I’d joined the company, we realized it was on us to create a similar environment for the candidates that better allowed them to showcase their strengths and make a more informed opinion about what it would be like to work with us. In turn, we would be able to develop conviction, champion candidates, and cultivate a more purposeful culture around hiring.
My Journey to Speakeasy
When I first met Sagar and Simon, I was exploring EdTech entrepreneurship as a South Park Commons member. During my exploration, I came across a classic research paper in education by Benjamin Bloom – The 2 Sigma Problem. Bloom found that the efficacy of 1:1 tutoring is remarkable. The average tutored student performed above 98% of the students (2 standard deviations) in a control class of 30 students and 1 teacher. There’s no shortage of takeaways that can be drawn from this study, but I took this as evidence for the power of focused attention in driving exceptional outcomes and the impact of doing things that don’t scale wherever possible.
I decided to apply this learning to my personal career journey. The standard engineering job search typically involves lining up interviews with as many companies as possible and using competing offers as leverage to settle on the best outcome. I figured I’d be better served focusing on a single prospect at a time, diving into the subject area, and getting a more dynamic signal about the team. I wanted to build conviction deliberately. When I connected with Sagar (Speakeasy CEO), I found someone with the same philosophy; we agreed to spend a week closely collaborating together before any longer-term decisions were made.
Over the span of a week, I was involved in design sessions, user discovery calls, and even interviews with other candidates. I was given an unfiltered view of the product direction with full access to all existing Notion docs, code, and proposed GTM planning. Equipped with this knowledge, I was encouraged to define and drive my own project that would be useful to the company. I came to understand the founders as not only congenial people who were easy to share a meal with, but insightful pragmatists who led with a sense of focus and approachability. I was able to identify where I could immediately contribute and where there existed proximal zones of development for my own growth. My understanding of what working at Speakeasy entailed was two standard deviations above what it typically had been prior to making previous career decisions. And I was paid for all of it.
How it Worked in Practice
We were initially unsure whether it was realistic to ask candidates to do trial periods with us, but we found them to be very open to the process. When we explained why we thought it was important, let them know we would compensate them for their time, and committed to accommodating their normal work schedules, people were eager to give working with us a shot.
During their trial periods, candidates operate as a full member of the team. They are given a real project to work on, welcome to join all standups and design sessions, and are given full access to our team documents. This gives candidates the same opportunity I had to explore and build conviction in Speakeasy’s mission and plan of execution.
So far we’ve extended this process to every full time dev on the team and the results have been nothing short of stellar. The developers we’ve been fortunate to hire have used their collaboration periods to demonstrate ownership, thoughtfulness about the user experience, and a sincerity that is present in the quality of their work. By the time they officially joined, they had already become part of the team and made meaningful contributions.
We’ve also observed the positive impact on team culture the collaboration period has brought. While there’s value in a company having a unifying culture, people are diverse in their strengths and we believe this should be leveraged. With trial periods, we ended up taking responsibility for cultivating fit, rather than seeking it as a natural occurrence gleaned in the cumulative 4 hrs of a typical interview process.
Thoughts on Scaling
The conclusion of Bloom’s “2 Sigma Problem” isn’t that everyone should be tutored 1:1 (that’s ideal, but totally unrealistic), rather it is an invitation to explore how we can “find methods of group instruction as effective as one-to-one tutoring”. In the same vein, we know it’s not realistic to offer an extended ‘trial period’ to every compelling candidate indefinitely. There will soon come a point where we need to graduate from this process, extract the core values, and develop new processes that embody these values as the company scales.
It’s something we’re already thinking about. We believe the trial period incorporates a few values that have served us well such as radical transparency and openness. We’re in the process of formally defining these values, so we can continue to be intentional in our hiring process and build a strong foundation as a team.
In “The 2 Sigma Problem” there is another experiment where students within an entire class performed a standard deviation better than others. The result came from shifting the responsibility to the educator to employ more tailored instructional and feedback-driven strategies. For Speakeasy, this means not throwing a bog-standard ‘Cracking the Coding Interview’ question at an applicant and calling it a day. Even at scale, we’ll always have a responsibility to engage with each candidate in a way that puts them at the center of the process. In an industry where many developers feel like proficiency with a leetcode question bank is often the be-all and end-all to employability, we’re committed to being thoughtful about the overall candidate experience and giving them the opportunity to make genuine contributions during the hiring process.
Whether this involves dynamically responding to a developer’s skills as we add more structure to our process or using OSS work for collaboration that can also help build up their portfolio, we’re excited to continue making the experience a positive one for all who are involved.