Who Y Combinator Companies Want
blog.triplebyte.com
blog.triplebyte.com
The other factor is that enterprise programmers tend to prefer places with a lot of process in place. They want to see a well defined pipeline with tests and approvals and gates and so on. Pushing untested code to production isn't even in their mental space, but sometimes you just gotta do it at a startup when you got a press hit and your traffic just doubled. Basically, they tend to slow things down by demanding doing things right.
Now, for the first problem, that's just wrong -- just because you were in an enterprise doesn't mean you are bad or you are willing to deal with bad people. It's just a cognitive bias.
For the second problem, those people are right, there should be good process and it will be better in the long term. But in the short term it feels like they are slowing things down, because startups generally don't have the luxury of investing more time now for a bigger payoff later, or at least they don't think they do.
I see it in my current employer vs my previous employer. While not a small startup by any means, I notice a clear attempt by many ranks to encourage working late and working from home, be it "we'll order pizzas for people that stay here until 20:00" to "we have crazy deadlines that we must!!!! finish now!!!!" nonsense to "we encourage open source but we don't give enough time to developers to handle community issues, and we implicitly expect them to do that on their own time at night or during the weekend". To me, this is very toxic for junior developers who cannot, or do not even know they should, resist it. None of that was there on my previous, enterprise job. Come to work at some hour, do what you do, go home. I try to push this "work from home during after hours" mentality as much as possible, but it's very entrenched.
Regarding sear fillers, while true to some respect for enterprise, I'd say from many conversations I've had with people in the start up world, there exist many fillers there as well, often including founders and other "C"-level executives who only had the talent and know-how to give themselves a fancy title.
Finally, this was posted here in another discussion, but I think it's interesting here as well: https://danluu.com/startup-tradeoffs/
I wouldn't trade my enterprise experience for anything. It gave me a deep appreciation for the craft of software development, and an amazing introduction to complex, well-designed systems (not to mention some terrible ones as well). Without that opportunity to learn process and best practices, I would never have been successful elsewhere in my career.
Of course, you'll always find seat-fillers at big companies, but I think that'd be true no matter where you go. Bad hiring decisions are real, but should not discount or destroy the many great people who grow up in enterprise environments and can make meaningful contributions.
With all due respect to the "move fast, break things" evident in many startups, it leaves behind a big technical mess for the people who help transition the company out of startup phases. I'd bet most would do well to incorporate a few more stodgy enterprise devs earlier in the process to help steer the software toward a sustainable path.
I agree to a point, and tried to address it above. It's a tradeoff -- do it right now for a big payoff later. However, you have to survive to the payoff. So maybe you spend a bunch of time doing it right, and then die when you haven't actually sold anything yet.
I'd rather have a company that made it to the "we have to clean up our technical debt" phase then building something beautiful that never sees the light of day.
There's a balance to be had, though. I've said it downthread but I'll only mention it again here because it's relevant - I'm a manager in the "enterprise" (or more accurately, I'm a bit more senior than that, but whatever). My perspective doesn't really fall to either extreme:
Coming out of the gate and addressing the unknown (to keep it reasonably similar to startups), I want to move fast, iterate, fail fast and other cliches. Eventually, though, if we're as smart as we think we are, the unknown shrinks within the scope of the problem we're trying to solve and we move to a more manageable pace - with process, standards and all of that. I don't see burn and churn as a long term strategy for my products or my people.
Say what you will about enterprise, but we can't be total idiots. There is complexity in what we do - many are managing projects or programs that would essentially be a startup's entire product. For every unicorn, there are likely thousands of startups that will not grow as large as a single enterprise product. (talking generally here)
I'm not saying we're better or anything, but I'd hope that an enterprise dev's resume doesn't go into the shredder just because they spent years at a large company. Consider that they're probably getting paid pretty well, probably get stock (or at least the discount on purchase of stock) that is already publicly traded and liquid, weeks of paid time off, all sorts of benefits and little concern about job loss due to insolvency. If an enterprise dev is telling a startup they want to work there, it's very likely that they believe in the product or simply want to work at the faster pace, and they'll have as much to teach you as you have to teach them.
/soapbox :D
As an example, a dev with say 4 years of experience overall that happens to be working at a bank who might have had some solid internship and side projects upon graduation won't be 'locked out' to the same degree as someone with 15 years at that same bank. Someone with 25 years at that bank who worked on very similar projects may be seen as unemployable by most startups.
That junior dev might not have any kind of preference or necessity for process, but just wound up at the bank after graduation. It's these devs that probably suffer.
The person who stayed 25 years (ageism aside) probably did so for a reason, and some will assume that the reason was process and predictability in their work. Someone that stayed for that long and didn't get bored is probably going to be passed over by most startups.
Then again, you hit it with the other point. I'm much more likely to found my own startup than work at someone else's, but a sufficiently disruptive fintech/insurtech/analytics play would totally have my attention. I think the bigger issue is that the right role for me would be something a founder would likely fill, so I'm probably more likely to talk about co-founding something than being an early employee.
Well shit, I'm old!
I've been a happy engineer with a YC company for close to three years now. I have led various teams and contributed to many aspect of the overall product during my tenure. I have also interviewed more than twenty people and I can assure you, there is no one size fit all when it comes to finding candidates that succeed.
I also tried TripleByte a year ago, I figured it would be fun to see how they do things.
I got to the interview section after doing well on the online quizz however failed to go beyond that.
From my experience I can assure you that TripleByte has its own set of standards and values that may not match with you or the company you want to work with. They are overly interested in putting labels and pigeon holing candidates into specific categories that overlooks the fact that every individual is different.
YC is a big family with varied products, teams, and problems. There are no one size fit all formula or set of labels for ideal candidates or ideal company.
Your best route for success is to do the work yourself, find the company that interests you, directly connect with them and see how it goes.
Also if someone can explain to me what is trial and error programmer, or a child prodigy I would be grateful? Can a child prodigy be also an enterprise programmer? Is there any overlap between product programmers, pragmatic programmers?
That's refreshing to hear, thanks. Your observations is in stark contrast to their proclamation that:
"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."[1]
(1) Companies are unlikely to reply if you contact them directly because your resume isn't impressive. Our entire screening process is background blind and we've built up enough credibility with companies for them to interview you if you do well on our process, when they otherwise would have rejected you based on your background.
(2) Finding new company options that are are doing interesting work but you haven't heard about. We spend a lot of time finding and partnering with early stage startups that haven't become well known yet.
(3) Saving time in your job search by identifying which companies are looking for your specific set of skills. We have a lot of data about what the companies we work with are looking for and can reduce the number of interviews you do where it becomes clear early on that you're just not the type of engineer they're looking for (e.g. they ask you complex algorithm questions on a whiteboard when your strengths are building and scaling web applications).
We're focused on doing these things well and our process certainly isn't perfect. There will be times where we match you with a company and you weren't a fit or when we don't match you with a company and you might have been a fit. Achieving 100% accuracy in something as complicated as hiring is likely impossible but we believe our approach is still a lot better than the status quo of recruiters reading resumes and making gut calls on who gets through to an interview.
I think the core issue is that hiring a bad programmer is so costly, and there are so many bad programmers in the hiring pool that companies tune their filters to avoid the worst, while thinking they are aiming for the best.
It certainly feels intuitive that it should happen, but that's not what I've seen.
If you are wanting to improve your own skills, I'd just write programs to solve problems you are interested in. Read the Pragmatic Programer and Code Complete.
A great programmer in the wrong niche can destroy a project.
I generally attributed the discrimination to be more about dev culture than tech skills, whereas the enterprise dev maybe with a few years at a bank/insurance/pharma company might be too set in the traditionally slow pace in regulated industries or bureaucracies to adapt to the stereotype of a fast-paced startup. I never felt that startup leaders might actually think of them as lesser-skilled, and it wasn't discussed - the feedback on enterprise candidates would often be simply 'not a good fit' before an interview would even occur. I was always a bit uncomfortable with that reaction, as clearly there are many good enterprise devs of high quality regardless of what tools they use.
I think I've got the worst of both worlds too, because before this I was in academia, where I was also bored with the slow pace of things.
You need a side gig or to get involved with an open-source project. Get exposure outside of work then get yourself a more exciting job.
I might be reading that wrong, but I took that as "Java/C# devs failed company interviews 2x Ruby/JS devs".
No?
Also, not sure these archetypes do a great job of capturing the process-oriented/results-oriented divide that shows up in the opening anecdote (and which I agree is quite real).
From my perspective, there is an impedance mismatch between the triplebyte process (heads-down algorithm nerd) and the findings that they are presenting here (product-focused, culturally well rounded hacker, been around the block a few times and has experience in other startups).
This doesn't describe academic programmers. In my experience, academic programmers tend to be glorified essay writers who can just barely produce parseable syntax if left alone for a few hours.
Having not got into programming by pursuing CS in university and instead kind of taking the old "hacker" route, that kind of thing always hangs around my neck when job hunting.
I'm on a team with somebody who studied CS at the same university where I studied English for a time, and just the same we tend to have a reciprocal knowledge share occuring just the same.
It's getting that initial in where the degree seems to cover a great divide.
A cursory glance of glassdoor suggests this as well - balance a binary tree, huffman encoding, bloom filters etc.
https://www.glassdoor.com/Interview/Triplebyte-Interview-Que...
We've helped many engineers who didn't perform well in the algorithm/data structure section still find jobs at great companies because we work with many companyies who don't care about those skills (as evidenced by not evaluating it during their interview). This is one of the main ways we can help engineers have a better job search process, if textbook CS knowledge is not your strength we won't match you with companies who evaluate that during their interview.
Pretty sure that's what Triplebyte's academic archetype is getting at. Also pointing in broadly the same direction:
http://yosefk.com/blog/why-bad-scientific-code-beats-code-fo...
Seriously, though, the people that can endure the corporate marathon are uniquely skilled. Imagine that it's not the long hours and breakneck pace that kill you, but the exact opposite. The ones that can see their work through to the end are amazing in their own right.
My father-in-law made a wise suggestion, as a company, to always be in hiring mode. You don't want to hire someone because you need them at that very moment but always be hiring so you have redundancy.
I agree that it is quite different at startups. The startup environment felt basically a glorified college environment compared to the large company culture. With that said, I would image eventually all startups have to grow up and embrace enterprise-style processes. Facebook is the example that comes to mind. When they first started, the followed the "Move fast and break things" mantra, but as they aged and took on more and more users, they had to change and become a company that valued reliability over new features. I believe their current mantra is "Move Fast With Stable Infra."?
Do you have an anonymous data set of resumes, interviews, and offers that someone could run some clustering against?
While parts of it have self-description bias, it seems like the analysis would be a little more interesting than what you've provided. Possibly you may even uncover what companies really want, rather than what they say they want. Kaggle contest!!!!
> 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).
This is your opportunity, and it's a tough challenge. Tell them what they need and make them believe it. Of course, be right, as well. Never said it'd be easy, but a huge opportunity.
Preferences are mercurial because nobody knows what they actually need, only what they think they want, and truthfully there's a lot of latitude in the factors that lead to success. There's a real opportunity if you can figure this out and get companies on board with your judgment. I'm not suggesting one size fits all, but I am suggesting most companies don't know what size actually fits them, if I'm sticking with the cliche.
> There’s more demand for product-focused programmers than there is for programmers focused on hard technical problems. [...] And the “Academic Programmer” (hard-problem focused, but without the experience) has half again the demand.
This is another disconnect presenting an opportunity - minimize the whiteboard interview! That's essentially screening for the academic profile, isn't it? Again, enterprise guy here, so I'm guessing none of these companies would want to hire me based on the data presented, but I don't do whiteboard interviews at all, and I'd probably put my focus on the "product programmer" profile. Actually, I love your profile data, I've learned a lot about my own preferences just by reading this.
> (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.
This is really interesting. Again, enterprise bias here, but an enterprise programmer who's managed to get shit done in a big corporate environment should be highly valued. Not only can they program, they can also put up with all of the bullshit that it takes to get things through to production. There is something to be said about a programmer who can essentially handle the politics as well. But if you don't want 'em, I'll take 'em!
Anyhow, great writeup here by the Triplebyte folks. I hope that companies in particular read and make good use of what you've put together. I plan to share this with my management team.
--- Very true.
It's often the other programmers at startups judging the other programmers. Based on my personal experience, the best kind of programmer is the one that gets along well with others.