Who Y Combinator Companies Want

If you’re a programmer interested in joining a YC startup, apply to Triplebyte and we’ll match you with the ones you’d be the best fit for.

Companies disagree significantly about the types of programmers they want to hire. After 6 months doing technical interviews and sending the best engineers to Y Combinator companies (and interviewing the founders and CTOs at the top 25), we’ve analyzed our data. There are broad trends, but also a lot of unpredictability. Key takeaways include:

1. The types of programmers that each company looks for often have little to do with what the company needs or does. Rather, they reflect company culture and the backgrounds of the founders. It’s nearly impossible to judge these preferences from the outside. At most companies, however, non-technical recruiters reject 50% of applicants by pattern matching against these preferences. This is a huge frustration for everyone involved.

2. Across the companies we work with there are several notable trends. First, companies are more interested in engineers who are motivated by building a great product, and less interested in engineers with pure technical interests.This is at odds with the way the majority of programmers talk about their motivations. There’s a glut of programmer interest in Machine Learning and AI. Second, companies dislike programmers with enterprise backgrounds. Our data shows that companies are less likely to hire programmers coming from Java or C# backgrounds.

3. These results show extrapolation from insufficient data on the part of many companies. Talent can be found among programmers of all backgrounds. We’re mapping the preferences across all YC Companies in more detail, and encouraging companies to consider people they would normally reject. In the meantime, programmers looking for jobs with YC companies may want focus more on product and be sure to mention experience outside of Java and C#.

The problem

My co-founders and I have been running a recruiting company (Triplebyte) for the last 6 months. We interview programmers, and help the best ones get jobs at YC companies. We do our interviews without looking at resumes (in order to find great people who look bad on paper), and then see feedback on each engineer from multiple companies. This gives us a unique perspective on who YC companies want to hire.

When we started, we imagined a linear talent scale. We thought that most companies would be competing for the same (top 5%) of applicants, and all we had to do was measure this. One of the first people to pass our process really impressed us. He was a superb, intelligent programmer. He solved hard algorithm problems like they were nothing, and understood JavaScript deeply. We introduced him to a company he was excited about, and sat back to watch him get a job. We were startled when he failed his first interview. The company told us they valued process more than raw ability, and he’d not written tests during the interview. He went on to get a bunch of offers from other companies, and one founder told us he was among the best programmers they had ever interviewed.

This lack of agreement is the rule, not the exception. Almost no one passes all their programming interviews. This is true because of randomness in many interview processes (even great people are bad at some things, and an interviewer focusing on this can yield a blocking no), and also because companies look for very different skills. The company that rejected our first candidate ranked testing in the interview above algorithmic ability and JavaScript knowledge.

Mapping these preferences, it was clear, was key to helping engineers find the right startups. If we could route programmers to companies where their skills were valued, everyone would win. To that end, we’ve spent the last two months doing detailed interviews with CTOs and lead recruiters at the top 25 Y Combinator companies. In this blog post I’m going to write about what we learned from talking to these companies and sending them engineers. It’s interesting, and I hope useful for people applying for programming jobs.

Setup

To map the preferences of the top YC companies, we wrote paragraphs describing 9 hypothetical programmers, embodying patterns we’d seen from running 1000+ interviews over the last 6 months. These range from the “Product Programmer” who is more excited about designing a product and talking to users than solving technical challenges (we internally call this the Steve Jobs programmer) to the “Trial and Error Programmer” who programs quickly and is very productive, but takes an ad hoc approach to design. In reality, these profiles are not mutually exclusive (one person can have traits of several).

We then set up meetings with the founders and lead recruiters at the top 25 YC Companies. In the meetings we asked each company to rank the 9 profiles in terms of how excited they were to talk to people with those characteristics.

Results

The grid that follows shows the results[1]. Each row shows the preferences of a single (anonymized) company. Each column is a hypothetical profile. Green squares means the company wants to interview engineers matching the profile, red means they do not. Empty squares are cases where the founders’ opinions were too nuanced to be rounded to interest or lack of interest.


The first thing that jumps out is the lack of agreement. Indeed, there’s no single company interested (or disinterested) in all 9 profiles. And no profile was liked (or disliked) by more than 80% of companies. The inter-rater reliability of this data (a measure of the agreement of a group of raters) comes out at 0.09[2]. This is fairly close to 0. Company preferences are fairly close to unpredictable.

The impact of these preferences on programmers, however, is totally predictable. They fail interviews for opaque reasons. Most companies reject a high percentage of applicants during a recruiter call (or resume screen). Across the 25 companies we interviewed, an average of 47% of applicants were rejected in this way (the rate at individual companies went as high as 80%, and as low as 0%). The recruiters doing this rejecting are non technical. All they can do is reject candidates who don’t match the profile they’ve been taught to look for. We’ve seen this again and again when we intro candidates to companies. Some companies don’t want to talk to Java programmers. Others don’t want academics. Still others only want people conversant in academic CS. We’ve seen that most engineers only have the stomach for a limited number of interviews. Investing time in the wrong companies carries a high opportunity cost.

I don’t want to be too hard on recruiters. Hiring and interviewing are hard, shortcuts must be taken to keep the team sane, and there are legitimate reasons for a company to enforce a specific engineering culture. But from the point of view of programmers applying for jobs, these company preferences are mercurial. Companies don’t advertise their preferences. People who don’t match simply apply, and are rejected (or often never hear back).

Patterns

There is some agreement among companies, however, and it’s interesting.

1. There’s more demand for product-focused programmers than there is for programmers focused on hard technical problems. The “Product Programmer” and “Technical Programmer” profiles are identical, except one is motivated by product design, and the other by solving hard programming problems. There is almost twice as much demand for the product programmer among our companies. And the “Academic Programmer” (hard-problem focused, but without the experience) has half again the demand. This is consistent with what we’ve seen introducing engineers to companies. Two large YC companies (both with machine learning teams) have told us that they consider interest in ML a negative signal. It’s noteworthy that this is almost entirely at odds with the motivations that programmers express to us. We see ten times more engineers interested in Machine Learning and AI than we see interested in user testing or UX.

2. (Almost) everyone dislikes enterprise programmers. We don’t agree with this. We’ve seen a bunch of great Java programmers. But it’s what our data shows. The Enterprise Java profile is surpassed in dislikes only by the Academic Programmer. This is in spite of the fact we explicitly say the Enterprise Programmer is smart and good at their job. In our candidate interview data, this carries over to language choice. Programmers who used Java or C# (when interviewing with us) go on to pass interviews with companies at half the rate of programmers who use Ruby or JavaScript. (The C# pass rate is actually much lower than the Java pass rate, but the C# numbers are not yet significant by themselves.) Tangential facts: programmers who use Vim with us pass interviews with companies at a higher rate than programmers who use Emacs, and programmers on Windows pass at a lower rate than programmers on OS X or Linux.

3. Experience matters massively. Notice that the Rusty Experienced Programmer beats both of the junior programmer profiles, in spite of stronger positive language in the junior profiles. It makes sense that there’s more demand for experienced programmers, but the scale of the difference surprised me. One prominent YC company just does not hire recent college grads. And those that do set a higher bar. Among our first group of applicants, experienced people passed company interviews at a rate 8 times higher than junior people. We’ve since improved that, I’ll note. But experience continues to trump most other factors. Recent college grads who have completed at least one internship pass interviews with companies at twice the rate of college grads who have not done internships (if you’re in university now, definitely do an internship). Experience at a particular set of respected companies carries the most weight. Engineers who have worked at Google, Apple, Facebook, Amazon or Microsoft pass interviews at a 30% higher rate than candidates who have not.

Advice

If you’re looking for a job as a programmer, you should pay attention to these results. Product focused programmers pass more interviews. Correlation is not causation, of course. But company recruiter decisions are driven largely by pattern matching, so there is a strong argument that making yourself look like candidates who companies want will increase your pass rate. You may want to focus more on product when talking to companies (and perhaps focus on companies where you are interested in the product). This is a way to stand out. Similarly, if you’re a C# or Java programmer applying to a startup, it may behoove you to use another language in the interview (or at least talk about other languages and platforms with your interviewer). Interestingly, we did talk to two YC companies that love enterprise programmers. Both were companies with founders who have this background themselves. Reading bios of founders and applying to companies where the CTO shares your background is probably an effective job-search strategy (or you could apply through Triplebyte).

If you run a startup and are struggling to hire, you should pay attention to these results too. Our data clearly shows startups missing strong candidates because of preconceptions about what a good programmer looks like. I think the problem is often extrapolation from limited data. One company we talked to hired two great programmers from PhD programs early on, and now loves academics. Another company had a bad PhD hire, and is now biased against that degree. In most cases, programming skill is orthogonal to everything else. Some companies have legitimate reasons to limit who they hire, but I challenge all founders and hiring managers to ask themselves if they are really in that group. And if you’re hiring, I suggest you try to hire from undervalued profiles. There are great Ph.Ds and enterprise C# programmers interested in startups. Show them some love!

Conclusion

YC Startups disagree strikingly about who’s a good engineer. Each company brings a complex mix of domain requirements, biases, and recruiter preferences. Some of these factors make a lot of sense, others less so. But all of them are frustrating for candidates, who have no way to tell what companies want. They waste everyone’s time.

I’m excited about mapping this. Since we started matching candidates based on company preferences (as well as candidate preferences), we’ve seen a significant increase in interview pass rates. And we only just completed the interviews analyzed in the post. I’m excited to see what this data does. Our planned next step is to not only interview founders and recruiters at these companies, but also have the engineers who do the bulk of the actual interviewing provide the same data.

Our goal at Triplebyte is to build a better interview process. We want to help programmers poorly served by standard hiring practices. We’d love to have you apply, even if — or especially if — you come from one of the undervalued groups of programmers mentioned in this article. We’d also love to get your thoughts on this post. Send us an email at founders@triplebyte.com.

Thanks to Jared Friedman, Emmett Shear and Daniel Gackle and Greg Brockman and Michael Seibel for reading drafts of this.


Footnotes:

1. Astute readers will notice that there are more than 25 rows in the graph. This is because we’ve recently added these questions to our onboarding flow for new companies we work with. If you run a YC Company, you can log into Triplebyte with your company email address, and add this data (we’ll use it to send you more candidates).

2. I calculated this using Fleiss’ kappa. This measures the agreement between a number or raters, with -1 being perfect disagreement, 0 being the agreement that would result from random coin tosses, and 1 being perfect agreement.

20 responses
Hi, just wanted to share some thoughts on one of paragraphs: "...The company that rejected our first candidate ranked testing in the interview above algorithmic ability and JavaScript knowledge...". For me personally this raises two questions to that company: 1) do you think that a person who deeply understands javascript and algorithms will not be able to learn principles/framework for tests? 2) does a company assumes that it will not spend any time on teaching new-joiners about test frameworks? Do they really want to openly admit that they don't want their employees to grow? What I have found it's difficult to find a company that allows you to raise your skills. If I'm a full-stack developer (C++/node.js/knockout) on Linux environment and would like to learn Erlang but don't have ANY commercial experience in this matter - should I apply?
And that's why more than 90% of those Y Combinator startups fail... they just want to build horrible ad-hoc poorly built systems using *insert trendy technology of the moment* with the main goal of borrowing some cash from the VC bubble establishment... The main goal of those "startups" is far away from building good, reliable and well designed software... you're just sadly transforming the IT environment in a "how to get a job in..." rat race movement for the ambition of a small group who has no clue about Computer Science.. no respect at all for the profession.
Agree with Sergio 100%. Most JS and Ruby gurus I know can whip up websites in 2 seconds but their back ends are atrocious and worthless. Like he said, this is why most Y combinator startups fail.
Very interesting article and only confirms the issue we are facing and gonna continue to face with continuous cash injection to "born to fail startup" with no other ambition than to be part of the "startup scene" and its fame where founders under "VC perfusion" brag around with empty pockets and zero focus on the products to be delivered. An other issue as well is the invasion of the IT field by people from a pure business or sales background (though necessary but given the wrong seat) managing the recruitment of engineers. How can you delegate such critical process to someone who is technically illiterate and do not relate to any technical environment and deciding if an engineer is good enough or not. It shows as well a lack of real involvement of the engineering department( CTO and co.) to be part of the process because at the end of the day if the recruiter hire someone not matching the speed of production or has no capacity to learn, each hour wasted because of mistakes made will delay the engineers. The great thing those startups are missing is reaching greatness with their products and seeing them failing is a lesson that should be learned, like discarding java programmers, well java is everywhere and empowering an entire ecosystem. Technical peoples are necessary and I would prefer being surrounded by people smarter than me, challenging me all the time to be better, improving my skills and discovering new things and building better products together. Do not expect any kind of progress, self-development or raise your skills nowadays with any startups, personally I stay away from them. Before applying dear engineers, do your homework, search who are the founders, their background, who gonna do the interview, who is the manager/CTO etc. and filter, if they have no tech background, discard, things can change only if the real assets building the backend/infrastructure of the startup refuse to apply or to go to BS interview.
I don't know if technical recruiters are the best to make the decision about who to select and who to dismiss, especially if they don't have a technical background. A better approach might be to cast a wider net and select more potential candidates, but then put them through a technical filter. Automated coding tests would work nicely here, for example: https://www.testdome.com/ This way their skills can be evaluated any many candidates can be tested simultaneously. It's a good filter for deciding who should pass on to the more rigorous technical interview.
I think there are two immense flaws in what and how your company does. First, you handle programmers like merchandise. Second, you treat software development companies like clockworks. I.e., in both cases you completely ignore the social factor. The distinct preferences and weight placed on various criteria by different founders or managers, or hiring departments, the fact that the same programmer can fail miserably in one interview and be brilliant in another are expressions of the same fact. If you truly want to do a good service for startups in general and Y Combinator companies in particular, you need to treat each programmer and each company individually. Placing both companies' hiring preferences and programmers in categories won't help. Try establishing a personal, informal relation with both the programmer to be hired and the people hiring them. It's the only way to correctly judge whether there's a match or not. Unlike what many people think, developing software is a highly social activity. Going by technical criteria alone isn't going to get you anywhere. Both aspects have to match, for a productive, win-win relation between the programmer and the company. Especially for small, young, highly creative companies, the only alternative to win-win is loss-loss, which is why hiring the right people is much more important for such companies than it is for corporations.
"Anonymous Coward", I think that this is actually exactly why we're able to help as much as we do! Every company wants to hire a different kind of engineer. And every engineer has specific things they want to work on / types of culture they prefer. As you say, interview results are highly inconsistent, for exactly these reason. By measuring these things (however imperfectly) and matching on them, we're able to about double interview pass rates (our candidates pass job interviews at twice the rate of normal applicants to the companies we work with). This is pretty strong empirical evidence that that the matching is working. Now, you're certainly right that it's complicated (more complicated than this post describes), and that talking to everyone involved helps.
Thank you for sharing these findings, and they confirm my own predictions on the state of our industry. The leaning towards hiring more product based developers versus those who solve hard problems helps explains why demand for developers has increased. Will the solution to fill the demand for these developers is to treat them more like a vocation? Coding bootcamps with their 2 year "intensive" programs are making big $ trying to fill this need, where they try to cover "real life" coding practices, but fail to give someone a solid cs background. To me it's silly that during interviews people are expected to answer academic cs questions (about algorithms and data structures) for a job where all they do is plumbing (get all the things connected to each other). It would benefit companies and recruiters to be honest with employees and actually say: yes we are only looking for a plumber, not a sewer scientist. But yet the interview process proves otherwise (that the plumber also needs to be able model the changes of the pH of water running through the pipes). The medical field has adapted to this similar kind of scenario with Physician Assistants (who are certified medical professionals but not Doctors). I wonder how long it's going to take in this industry to do something similar, and for recruiters and companies to adapt to this change.
Certain programmers definitely stay away from startup since startups specially in valley are people burn out machines.
11 visitors upvoted this post.