
Who Y Combinator Companies Want - allenleein
http://blog.triplebyte.com/who-y-combinator-companies-want
======
jedberg
I can tell you why there is discrimination against Enterprise programmers. Two
reasons: Most people who have worked in an enterprise have had at least one
bad experience with an incompetent programmer who was just a seat filler. That
means that the enterprise isn't a good filter, and even worse, it means that
even if you are good, you're willing to suffer working with incompetence.

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.

~~~
mfb2
Interesting observations. As someone who came from an enterprise Java
background and moved into a startup shop, it is tremendously dispiriting and
disappointing to see so much disdain for people with backgrounds like mine.

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.

~~~
jedberg
> 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.

~~~
SmellTheGlove
> 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.

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

------
rezashirazian
If you want to work for a YC company apply directly to the YC company you want
to work with. Say who you are, what you know and why you like this company. I
also recommend not putting too much weight on arbitrary labels (trial and
error programmer? child prodigy?)

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?

~~~
bogomipz
>"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."

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][http://blog.triplebyte.com/](http://blog.triplebyte.com/)

------
danielvf
Stockfighter.io ran into similar issues. The candidate that finished the
competition we're far above average, but hiring companies still used the same
filters and long timing on those candidates as for sketchy unsolicited
resumes.

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.

~~~
Apocryphon
How can bad programmers be improved into hirable ones?

~~~
danielvf
I've been programing for eighteen years now. In that time, I've seen smart-
alec kids turn into great leaders. I've seen stupid teenagers turn into
responsible adults. I've seen responsible men turn into angry old guys. But
I'm still at zero on seeing a bad programmer turning into a good one.

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.

------
fecak
I've seen quite a bit of 'discrimination' against enterprise devs by startups
over the past ten years as a recruiter (and JUG president for 15 years), and
the data in this piece regarding Java/C# devs failing more interviews than
counterparts is at least a little surprising.

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.

~~~
quantumhobbit
I'm afraid I'm getting stereotyped as an enterprise dev against my will. I've
been on interviews where that was certainly the vibe I got. No matter how much
I stress that I'm interviewing while I have a job for the purpose of getting
away from that culture, I can't shake that opinion it seems. Trust me I would
gladly program in anything other than corporate Java if given a chance.

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.

~~~
jedberg
Your best bet is a side project. Do something fun in a language you enjoy, and
talk about that in the interview instead of the work you do. Make it big
enough that it warrants an entry on your resume. Or contribute to a well known
open source project.

~~~
fecak
This is really good advice, and something I've advised to countless devs over
the years. You can overcome some of that stigma by doing a side project in
another language or even something outside the realm (like an IoT thing). Many
Java devs will go with Scala, but I'd even try to go deeper and perhaps do a
couple side projects and shift to something like Python or a Lisp (which often
gets 'cred' points from startups).

------
dasmoth
Slightly surprised -- and a little diappointed -- to see "academic programmer"
as the least desirable archetype.

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).

~~~
whalesalad
Which is interesting to me because if you go through the triplebyte process
the impression you'll get is that they are looking for a very
academic/textbook CS student who can balance a binary tree on a whiteboard
while verbally explaining the operational complexity of an unladen swallow.

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).

~~~
52-6F-62
I was wondering much the same thing. It seemed inverted. Maybe it's just a
filter they use, and they don't actually discriminate against non-academic or
highly-technical types if they cannot answer those kinds of questions?

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.

~~~
muse900
I've finished CS at Uni and I can tell you that now a few years down the line,
I don't remember stuff. I only remember what I practice everyday, so if I am
to pursue changing jobs I'll need to go off and recap what I've done at Uni.
Same applies to a friend of mine that has over 15 years of experience, has a
Uni degree in CS... and he had to go read Uni stuff that he's done 15 years
ago just to go get another gig... his github repo has good projects and 1
project that has been stared for more than 4k times, he has an outstanding
stackoverflow account etc but thats not enough... he still goes to companies
and ask him to balance binary tries on the whiteboard to prove his worth...

~~~
52-6F-62
Makes me wonder if I should feel encouraged or not! Thanks for the note.

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.

------
deboboy
"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" \- These people are gold, will hire
them all day long... just did at one of our healthcare startups.

~~~
SmellTheGlove
Screw you, stop stealing my people :)

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.

------
_e
This is not just a problem for evaluating programmers but for ALL job
candidates.

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.

------
cyclonetiger
Current enterprise programmer. Former startup employee here.

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."?

~~~
LeoNatan25
Funny, as going by many of their open source projects, I'd say "move slow and
break things" could also suit them. ;)

------
blobbers
Is it just me do the categories seem a little off (as described here:
[http://blog.triplebyte.com/a-taxonomy-of-
programmers#.i1987v...](http://blog.triplebyte.com/a-taxonomy-of-
programmers#.i1987v68j) )

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!!!!

------
keyanp
Previous discussion
[https://news.ycombinator.com/item?id=10698009](https://news.ycombinator.com/item?id=10698009)

------
SmellTheGlove
A couple of things that jump out to me. Up front, I've been a little hard on
Triplebyte in some threads here, but this article is great, and I think their
heads are in the right place and motivated to solve one of the biggest
problems we have in the corporate world (and I'm telling you this as an
"enterprise" manager, so it is an issue across the board). Also that's one of
my best run-on sentences, maybe ever.

> 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.

~~~
sharemywin
>>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.

\--- Very true.

------
yanilkr
I am sorry to be the one telling this. The startup founders (not all) are in
no way position to be picky about programmers. Programming is an actual skill
that takes significant amount of effort to learn and requires constant
learning and improvement. After 5 years of good experience, programmers can
see through the fragile nature of startups where everyone else other than them
is some form of an executive in title but cannot deliver any value equivalent
to writing working code.

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.

------
koolba
So the most desirable is the child prodigy who's built actual products in a
practical way?

------
fahimulhaq
This is an old post. Can moderators put 2015 in the title?

~~~
SmellTheGlove
Yeah but there's good discussion going. Might as well allow it.

