Hacker News new | comments | show | ask | jobs | submit login
[dupe] Who Y Combinator Companies Want (triplebyte.com)
74 points by allenleein 211 days ago | hide | past | web | favorite | 54 comments



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.


One more reason: enterprise engineers see through the "change the world" and "disrupt" bullshit that startups often attempt to sell to juniors in order to overwork them until their souls are empty, and then expect them to go home and continue working. None of that in most enterprises. "Nine to five", while should not be taken literally, means following an order where there is work and there is life, and those should overlap only very rarely and only when absolutely necessary (no, an app crash or visual glitch is not it).

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/


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.


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


> 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


The enterprise filter in my experience gets stronger as the enterprise dev stays in that space.

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.


It's interesting how many of these 15-25 year enterprise veterans actually want to entangle their career paths with young and "hip" startups? I'm sure some do, but I'd guess a low percentage. Obviously, it would be different if some of these veterans are the ones founding the startup. I'd also guess that in some niche fields, such as security, poaching of enterprise veterans is happening much more than the more "sexy" fields.


A 15 year veteran would surprise you on that? Assuming college in the US, that person is probably 37 years old. I'm not ripping you or anything, that just surprises me a little because it's my age bracket.

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!


In my experience it's not a high percentage, but enough numbers overall to see some enterprise veteran discrimination. It's often diagnosed as ageism, though I don't think that's the case as I do see several 40-50 somethings with more diverse backgrounds landing in startups without issue.


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?


>"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/


We're certainly not the only way to join a YC company, or any company, and nor would we claim to be. The specific reasons why you'd consider using Triplebyte are:

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


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.


Or companies would rather stick to the old methods even if they don't work. After all they can't blame you if you are just following HR's process.


How can bad programmers be improved into hirable ones?


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.


Put them into a niche where they can be successful. Skill is secondary. What is really needed is a readiness to learn, an openness to new ideas (and old ones).

A great programmer in the wrong niche can destroy a project.


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.


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.


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.


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


> Trust me I would gladly program in anything other than corporate Java if given a chance.

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 wonder how much of it is won't work extremely long hours for low pay.


they said enterprise devs are failing more interviews because of cultural filtering by the hiring company, not that they are failing the technical assessments more than other devs.


The piece also says "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."

I might be reading that wrong, but I took that as "Java/C# devs failed company interviews 2x Ruby/JS devs".

No?


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


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


Agreed.

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


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.


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


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.


Hopefully Triplebyte will take this data to heart and change their interview process (or even customize it per archetype). If you want a very product focused engineer asking algorithmic questions is almost pointless. Heck, most of the time even knowing what big-O is doesn't matter. What matters more is how fast and effectively you can execute and if people can understand the code you write.


You must remember that the candidate is not Triplebyte's customer. The hiring organization is their customer. They need to balance their credibility with hiring orgs against their desire to redesign the whole process. They're a newer company, so they naturally will start with what is credible with their clients - whiteboarding being part of that. Over time, I agree, I'd like to see a shift, but that will require buy-in from their clients. If Triplebyte does a good enough job, eventually clients will simply not worry about the mechanics of Triplebyte's screening process and just trust that candidates they pass through are of high quality. At that point, Triplebyte can do whatever the hell it wants in screening provided that quality doesn't dip, and I'm sure that's exactly where they want to go. There is an unbelievable amount of corporate inertia, from startup to fortune 500, in fundamentally changing the hiring process. I wish them the best, and honestly hope they get there.


The goal of our process is to identify which areas of strengths and weakness an engineer has. We do have a section where we ask algorithm and data structure questions to test academic/textbook CS knowledge but we also have sections testing very different skills e.g. practical web programming, debugging and low level systems.

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.


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

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.


Just what exactly are they working on in academia?


I've done hundreds of interviews, and for me I can usually tell that a candidate with a PhD and no real work experience will be amongst the worst pure coders I come across, so I think it's a fitting stereotype. I'm sure there are exceptions but it's pretty clearly a signal for me. But I never look at candidate's resumes before I interview them to avoid any biases, since the companies where I have interview ed for, for better or worse, they care more about the whiteboarding or architecture answers rather than work experience.


I think the important part of their "academic programmer" was the "without experience" part. People coming out of academic settings tend to have very significant gaps in skill and experience that need to be addressed before they can be really productive. Sometimes this isn't a smooth process at all.


Can only assume it's primarily the commercial experience aspect, rather than any particular connotation.


From my experience that is generally because academic = not hacker. By not hacker I mean that they find it hard to slam something together quick and dirty.


My experience has been, if anything, more-or-less the opposite. The good academic programmers I've known have been very focussed on solving the problem at hand, perhaps without a particularly "engineered" feel to the code (relatively large functions, not necessarily a lot of exposed abstraction, etc.). It's a style I've got a fair bit of respect for, and absolutely would count as "hacker" (in a positive sense)

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


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


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.


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.


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


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


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

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



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.


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


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.


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


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


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




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: