> "Second, companies dislike programmers with enterprise backgrounds. Our data shows that companies are less likely to hire programmers coming from Java or C# backgrounds." This I totally understand. Enterprise software is systematically horrible in almost every way: terrible UI/UX, insane degrees of over engineering, high footprint, high cost, and usually at least two to three generations behind on every technologic…
So you would not hire someone of a Microsoft or Google background?
Who Y Combinator Companies Want
201–210 of 552 posts
Re: Who Y Combinator Companies Want
#202> "Second, companies dislike programmers with enterprise backgrounds. Our data shows that companies are less likely to hire programmers coming from Java or C# backgrounds." This I totally understand. Enterprise software is systematically horrible in almost every way: terrible UI/UX, insane degrees of over engineering, high footprint, high cost, and usually at least two to three generations behind on every technologic…
> usually at least two to three generations behind on every technological trend It's easy to refactor (or completely rewrite) for whatever the hot new fad is when you're dealing with small codebases ( It has nothing to do with "pointy haired bosses" - believe it or not a lot of us [enterprise developers] care more about actually getting stuff done then bragging to our friends how we're playing with whatever is hip th…
I also didn't mean to imply that there are no good developers in "enterprise." But I do believe that "enterprise" is to good developers what, say, a corrupt economy is to good entrepreneurs. You can operate there but it's painful and everything about it gets in the way of doing the right thing.
Also also (heh) I didn't mean to imply that all enterprises are "enterprise." That's why I put it in quotes. Some large organizations manage to avoid these pathologies. I've even seen really excellent systems emerge from government labs if the people running them are clueful. "Enterprise" in quotes refers to the pathologies that afflict big over-priced over-engineered slow clunky UX abominations. Everyone's seen them and everyone's been forced to use them... forced because nobody would ever voluntarily do so.
Re: Who Y Combinator Companies Want
#203> "Second, companies dislike programmers with enterprise backgrounds. Our data shows that companies are less likely to hire programmers coming from Java or C# backgrounds." This I totally understand. Enterprise software is systematically horrible in almost every way: terrible UI/UX, insane degrees of over engineering, high footprint, high cost, and usually at least two to three generations behind on every technologic…
> It's so bad that I've actually heard people advise startups to pass on some enterprise revenue if they can afford it (pass on REVENUE!) if it might lead them down an "enterprisey" path, since doing so would in the end result in a systematically inferior product. Yes, because it's much better to have an architecturally pure product nobody uses than something generating millions in recurring revenue.
This is why Apple shuns "enterprise." They value user experience. Exposing UX to enterprise development priorities and methodologies is like exposing a kitten to mustard gas. Even a little bit does tremendous harm and it's definitely cruel.
Last I checked Apple was among the most valuable companies in the world. Their stuff is also heavily used in enterprise in spite of their dismissal of it. Sometimes a good product can make inroads into enterprise if it's good enough to overcome certain biases and entrenched pathologies. Some organizations have departments running their own "guerrilla IT" to support things that aren't awful vs. the awful stuff shoved down their throats by corporate IT.
The root problem with enterprise is that products are often built to artificial specifications that someone made up, not to actual specifications learned through real use and feedback or that are shaped by underlying reality. This results in a lot of superfluous complexity that does not reflect the actual complexity of the problem domain. Another major problem is that purchasing tends to be based on feature check boxes instead of actual evaluation of the product by people who will actually be using it. You'd be surprised how often a large org will make a major purchase without even consulting with those who will actually be using the product. I've also seen cases where people go so far as to pretend to use the "boat anchor" product while actually doing things using a different system purchased or built with off-normal-channels funds.
Re: Who Y Combinator Companies Want
#204Earlier quoted context omitted.
>> have 10 days a year vacation (pretty standard) Wait, what? Is it really this bad in the States?
I don't know about Silicon Valley, but in Colorado it's almost never that bad for software jobs. In 12 years I don't recall any jobs with fewer than 15 days. My current job is "unlimited", and I took nearly 25 days one year.
Re: Who Y Combinator Companies Want
#205Earlier quoted context omitted.
In my experience in the Bay Area, jobs fall into one of three categories: 1) No paid vacation at all 2) 15-25 days of vacation a year 3) "Unlimited vacation," which is usually a hip facade for 1 or 2.
2) 15-25 days of vacation a year Really? 25 days is 5 weeks; I feel like the standard for PTO is 10-15 days, and often it's 10 days, but you get bumped up to 15 after you work at a place for a year or two. 3) "Unlimited vacation," which is usually a hip facade for 1 or 2. Is that really true? I have very limited first-hand experience; only two of my employers have offered unlimited vacation. For one of them, it was a…
"Can I take three weeks off in July?"
"Absolutely! But we might penalize you on your performance review."
Re: Who Y Combinator Companies Want
#206Earlier quoted context omitted.
The cost of a real work test is much higher, both to the company, and to the applicant. Some companies take that approach (weebly for one), but it means that some of the best programmer will not apply, and it only makes worse the problem of having to aggressively pre-filter (based on credentials, or something else). You are 100% correct that most research into interviewing has show it to be far less predictive than c…
The best programmers do apply. Whatever you think a work-hire test is, that wasn't it. A work-hire test attracts the best programmers. It doesn't repel them. It's a chance to demonstrate their skill. It's also far better: anything is better than the fake contests they're currently forced to endure. Which would you prefer? Spend a couple hours remotely fixing some bugs and adding a feature on a fake iOS app, or spend…
If only it were that easy. I am not at all opposed to work-trial tests. They are almost certainly more accurate. But a high percentage of programmer will never apply to a company that requires one. Read any HN comment thread about the topic. It's very controversial. Lots of programmers are against it. Work-trials require MORE time upfront from the candidate, and of course still often lead to rejections (by design a hiring filter rejects most people). A failed work trial burns an entire week of vacation. An unemployed programmer (who is being paid the work-trial) may like it, but someone working another job may not.
Re: Who Y Combinator Companies Want
#207Earlier quoted context omitted.
I've made the mistake in the past of overcommitting myself to interviewing with multiple companies at once. The time commitment wasn't the worst part, the real factor I didn't for see is that interviewing is stressful and mentally exhausting. On top of the interview itself, there's the hours of studying you have to put in. It's extremely hard to do while doing your full time job. Now I have a rule that I will intervi…
>On top of the interview itself, there's the hours of studying you have to put in. Yikes, are people really doing this, or feel like they must? If I'm interviewing, I expect to be asked about previous projects, maybe my Github portfolio, and so on. I also expect to be asked how I might approach a given problem within my area of work. I can't imagine studying that - I'm paid to do this stuff every day. So are we talki…
Re: Who Y Combinator Companies Want
#208Earlier quoted context omitted.
It's funny you say that. I can't name one factory pattern off the top of my head... Never needed to learn one. I should clarify -- I'm in my late twenties, and I've spent my entire career (10 years) writing Java code. I don't understand how that negatively hiring managers against me.
Have you worked at multiple jobs over those 10 years? As a hiring manager (working with only the limited data you've provided here) I'd be concerned that you value stability very highly, and you might be thrown by the rate of change (in requirements, tools used, business goals, desired feature set, etc) that is typical of a startup. Long tenure at a single job suggests you enjoy getting deeply specialized and develop…
Do you mean learning something new 3-4 times per year that is unrelated to large architectural changes?
In terms of 'on your own'--I don't know, maybe this person has a life outside of writing code?
Re: Who Y Combinator Companies Want
#209Earlier quoted context omitted.
I never understood why that was a prerequisite. I program for 60 hours a week. So what if I don't want to do it on the weekends too.
Unfortunately, tinkering in your off-hours is a key way for programmers to keep their skills current. The industry changes rapidly and the skills that were most marketable over the past 10 years are not the same as those that will be most marketable over the next 10. If you're not changing jobs constantly, the rate of tech change at your workplace is unlikely to be enough to keep your skills marketable. So you need t…
Re: Who Y Combinator Companies Want
#210Earlier quoted context omitted.
It's not only the applicants who have limited time. The startup founders are also time constrained. You can't found a successful startup if you spend 10+ hours a week interviewing potential employees. I suspect much of the initial bias and "hard line" preferences are due to a startup's unwillingness to spend inordinate amounts of time interviewing candidates to find that one diamond in the rough. Imagine 4 of every 1…
Many successful people who've built and exited massive start-ups have suggested that it's worthwhile on the start-up side to spend 25% of your time on hiring when you're actually hiring as so you can easily get above 10 hrs a week given a full time role on this and have that be a good result. Optimizing to minimize the cost of hiring an early engineer is definitely solving the wrong problem, given the early engineers…