
Who Y Combinator Companies Want - Harj
http://data.triplebyte.com/who-y-combinator-companies-want-c1880a08ac88
======
ryandrake
> "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 suspect in addition to not having the "stomach" for an unlimited number of
interviews, they don't have the vacation days to burn for them. Let's say you
are working already and have 10 days a year vacation (pretty standard). With
these ridiculous all-day interviews, you have the ability to waste that
vacation on a maximum of 10 companies, and that's if you choose not to take
any "real" vacation at all during the year.

In an environment like today, where every company is ostensibly hiring yet
overly picky, a job candidate potentially will waste their entire PTO balance
on interviewing with companies serious about interviewing but not serious
about hiring.

~~~
s_kilk
>> have 10 days a year vacation (pretty standard)

Wait, what?

Is it really this bad in the States?

~~~
L_Rahman
Yup. 10 days paid time off is the de-facto standard for just about every
company based in this country.

Some people negotiate additional PTO as part of their compensation package but
I don't need to tell HN that engineers are notoriously bad at doing this.

~~~
dragonwriter
> 10 days paid time off is the de-facto standard for just about every company
> based in this country.

Not to mention that _tech industry_ firms are reputed to be more generous than
what is otherwise common, that sounds really low _even outside of the tech
industry_ ; its lower than _any_ company I've seen, and lower than what most
sources I've seen indicate is common. [0]

[0] e.g.,
[http://www.bls.gov/news.release/ebs.t05.htm](http://www.bls.gov/news.release/ebs.t05.htm)
and [http://www.salary.com/time-off-paid-time-off-from-
work/](http://www.salary.com/time-off-paid-time-off-from-work/)

~~~
pkteison
What's probably happening here is there are company-selected vacation days
being left out of the number. You get to choose 10, but another 10 are picked
by the company.

I worked as a programmer at a big boring company which did this - 10 days of
company holidays, 10 days of you-get-to-choose. It's a month off total, but
you only have control over 2 weeks, so it's presented as 10 vacation days.

~~~
dragonwriter
> What's probably happening here is there are company-selected vacation days
> being left out of the number.

The first source I linked provides actual averages for paid holidays, paid
vacation, and paid sick leave.

10 paid vacation days is dead average for professional, technical, and related
employees -- with only one year of service, and low for such employees with
more service.

------
throwaway456789
I'm an "enterprise" programmer because I write in Java... I'm also older than
the average age of a start-up employee (late twenties). I've never written a
line of Ruby, and I've never written object oriented JavaScript or used
Node.js.

However, I'm a _really_ good programmer. I just happen to write the majority
of my code in Java. If tomorrow we decided to use a new language, I could pick
it up in a few days... I have a feeling the "enterprise" thing is just veiled
age-ism. Anyone can feel free to correct me if I'm wrong, but at this point,
it's literally _impossible_ to learn _every_ new technology. And anyone whose
worth their salt should be able to learn a new environment and programming
language without too much trouble.

I have a feeling that the enterprise thing is just a way for these employers
to screen out the older, more experienced programmers.

This will probably get this throwaway banned, but Michael O'Church (who I am
not) writes a lot about this on his blog. I tend to agree with him.

~~~
alexwebb2
Hiring manager here, and after many interviews with enterprise programmers, I
do find myself putting more and more of them into the "no" pile right off the
bat.

The problem is that those candidates, in my experience, tend to throw up way
more red flags than others - their code is extremely verbose, they rattle off
factory patterns like they're reading a textbook without any inkling what sort
of problems they're actually solving, they parrot popular opinions without
being able to articulate the reasoning behind them, they're not comfortable
with developing a new feature without extensive documentation, and they miss
the forest for the trees when it comes to things like testing and code
organization.

Enterprise programmers usually leave me with the impression that they're
heavily indoctrinated into one specific mode of thought, and that they would
struggle to break out of it.

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

~~~
shimon
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 developing mastery of a stable set of tools,
which is needed at a certain stage of company but not at most early-stage
startups.

Is that true of you? I.e. would you be frustrated by 3-4x/year significant
churn in your technological tooling and top-level business goals? Would you be
excited to learn a few new toolsets? If so, why haven't you done that on your
own?

~~~
hox
Wow. Really? Why is stability a _concern?_ Much of engineering is making solid
decisions and fucking sticking with them rather than changing to the latest
toolset because that's what hacker news says is the best today. Are you trying
to build a product and company, or a blog post?

~~~
Snowdax
Stability is a concern because startups are not stable. In 6 months time Apple
could open source something that makes your last 5 years of work irrelevant in
a night. If you can't ship in 6 months you're company will probably have shut
up shop in 12 because someone already ate your lunch.

If it's a choice between stability (via proper testing, architecture, etc.)
and staying operating, stability loses every time.

No matter what happens the tech world is a different place in a year. You have
to adapt regardless so properly thought out code will get thrown out just as
easily as 4am hacks.

------
xiaoma
So... I worked with over 50 engineers prepping for their first SF/Silicon
Valley tech interviews. And I worked at Groupon, interviewed at a bunch of YC
companies (including one where I took a job).

In my experience pretty much nobody is taking Ben Horowitz's advice from _The
Hard Thing About Hard Things_ —hire based on strength instead of a perceived
lack of weakness. Instead everyone seems to be looking for candidates who fill
out all the boxes and have zero thumbs down in interviews. That coupled with
extreme risk aversion means long interview cycles, and huge amounts of wasted
time for some of the most talented employees and founders on the planet.

~~~
ammon
Well, they sort of are, just not explicitly. The standard process is to have 2
to 5 interviewers, each asking their own question, and pass everyone who get
at least one strong yes, and no strong noes. This ends up with a random
factor, but ultimately favoring people at least one real strength. The
interviewer who sees this strength will fight for them. We've seen people with
high skill variance (great at one thing, bad at others) pass interviews at a
higher rater than people who are just OK at everything.

~~~
vonmoltke
> no strong noes

This is the problem. It allows one interviewer with a pet peeve to torpedo an
otherwise excellent hire. Where I work, whoever ends up on the wrong side of
the majority needs to make a case good enough to convince the majority to
switch. Being strongly in the minority is not good enough.

The culture of accepting high false negative rates leads to the "no
weaknesses" hiring the GP was complaining about.

~~~
ammon
Yeah, I totally agree. We actually asked YC Companies about their fire rates.
The fire rate at most of the companies was under 6% (documenting a high false
negative rate approach)

~~~
henrikschroder
Isn't it kind of weird that startup culture is supposed to be all about
failing fast, MVP, and pivoting, but when it comes to hiring, it has to be
perfect from the start?

~~~
frakkingcylons
Hiring is a critical piece of running a startup. It's one of the few things a
startup can control, so hiring choices should be as close to perfect as one
can manage. Also, the hiring philosophy at most startups is closer to the
'fail fast' principle than you think. The universal piece of advice is to fire
someone quickly when you realize you made a bad hire.

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

Reading this is somewhat reassuring. I've been over some interviews lately and
I had some trouble getting past the tech phone screen.

One particular rejection was very frustrating, because I've spend quite some
time preparing for the interview. Failed the first one. Got a second chance.
And I knew it was over about 5 minutes after it began. "Can you write an
algorithm that would sort efficiently this k-sorted array with a complexity
strictly inferior to O(n log n)?". Yeah. No. Neither my job nor my hobbies
includes sorting almost sorted arrays of integers, and O(n) complexity
calculations.

It really seems to me that, being hired by a tech company is just completely
random. Tech interviews in general are completely random. "Just a numbers
game"

~~~
taurath
Not completely random, but by my estimation being self-taught fully 40-60% of
engineering organizations (trending higher as they get bigger) care much more
deeply about academic CS than they do about whether you're able to ship a
product. Those companies are looking for people who fit a mold (a generalized
interface) so they can scale their teams out. Startups and smaller companies
tend to value people who are flexible and can learn new things very quickly
and are less likely to test you on alg analysis and are much more likely to
throw you an unfamiliar problem and see how you solve it.

~~~
Fiahil
I agree, I've been far more successful with startups than with bigger
organizations. The irony is, I have a Master's degree in software engineering,
but I never gave (until now) too much attention to these common O(n) sorting
problems. In practice, I would end up using whatever standard library's
default sort function and it would be perfectly okay for most use cases.

I wish tech screens didn't rely so much on these exercises; I have limited
brain space and I don't like to archive more important stuff.

~~~
sliverstorm
Well, you could argue that maybe they aren't looking for somebody to use a
library, maybe they're looking for someone to _write_ a library.

------
moron4hire
This is why I don't really interview my sub-contractors. If I run into someone
at a meetup that I think seems smart, I ask them if they'd be interested in
picking up a small project. If they accept, I... give them a small project. No
resumes. No demeaning interrogation. Straight to work on something real. And I
pay them.[0]

If they do well, I give them another one. If they don't, I tell them I'm sorry
but I don't have any more work for them.

Thinking more deeply on the issue, I think I want to know as little about a
potential candidate as possible.[1] I don't want to bias myself against them.
I've had a lot of bad experiences in my career and I'm sure I'm not perfect at
keeping my prejudices to myself. I want to get people into the chair as soon
as possible, get them working, and judge from the work. Once I see work
getting done, it's really easy to ignore everything else.

[0] I don't think I _can_ even make someone do an "interview assignment" for
free. I'd be receiving something of value--their labor--but I'd have no
accounting of it for taxes and I have no desire to try to figure out how to
keep track of something like that.

[1] Yeah, I'll say this probably includes whether or not they have any
experience with programming. If they can't do the job, we'll find out soon
enough. If they can do the job to a satisfactory degree, why do I need know
how long they've been doing it before? Give people a chance to surprise you.

~~~
20years
Very cool! Wish more companies approached it like this.

------
fredliu
I'm not a java programmer (my knee jerk reaction to quickly bang out an MVP
would mostly be python), but this negative attitude towards Java seems unfair.
There's a lot more to the Java universe than just enterprise Java. There are
companies using Java that do cool stuff at large scale, and very reliable.
Netflix is heavily Java, and nobody would (at least I wouldn't) argue that
their tech is dull. Even if you are looking for pure hip factor, there's
things like vert.x, and all these other JVM languages, which are not Java per
se, but one of the selling points of those languages is it can utilize tons of
libraries in the java ecosystem if needed. The last argument against java
would be its verbosity and productivity (lack of), but I'd argue Java has one
of the best IDE support among all languages, which helps alleviate the problem
significantly.

------
cogware
"Two large YC companies (both with machine learning teams) have told us that
they consider interest in ML a negative signal."

I wonder why this is? Since ML/AI are currently "hot" those programmers may be
trend followers? Or maybe interest in ML is correlated with being a junior
programmer (those that are more senior specialized when ML/AI were not so cool
and consequently are in different domains)?

~~~
majormajor
Not at a YC company, but yeah my guess would be that it's hard to get the
trend followers on board with other stuff. I've anecdotally seen myself a lot
of candidates (esp at the recent-university/recent-MS level) who've taken some
ML courses cause it's trendy and sounds interesting but (a) don't have a
serious enough interest in it or knowledge of how to apply it well enough to
be a good fit on our ML teams and (b) aren't open to other roles because they
sound less cool or have a perception that the day to day work will be more
tedious.

~~~
ammon
Author of the post. I think that this is exactly right. I don't know what
motivated the companies to put that policy in place (they just told us that
they had this preference). But I can speculate. There is an epidemic of
interest in ML. Four out of 5 college grads we speak to list it as an
interest. I think that interest has grown to the point where it's no longer
any kind of signal about technical strength, and perhaps a signal that the
candidates will not be flexible about what they work on.

~~~
lackbeard
I'd be curious to hear about the inverse. Have you found there are
skills/disciplines that companies are highly interested in but no candidates
are?

------
lewisl9029
As a "Product Programmer" myself, I find it highly ironic that despite the
fact that there is apparently more demand for product-focused developers than
technical-focused ones, the interview process for most startups is
_overwhelmingly_ technical-focused.

If you're looking for product-focused developers, please consider tuning your
interview process to evaluate whether or not candidates can build great
products, rather than following the herd and grilling them on obscure
algorithms and data-structure problems, which has a rather high chance of
weeding out the kinds of product-focused developers that you're looking for in
the first place.

~~~
tdaltonc
Maybe you only remember the super technical parts because the product-focused
parts were effortless for you.

~~~
hawkice
I've been in interviews where over half the questions were legit non-
programming puzzles, and the rest were algorithms. Most interviews are heavy
on tool-specific questions. I've had only two interviews where I've been asked
to fix a bug in code and in those circumstances I wasn't able to actually run
the code. Getting even remotely close to building something would be so
supremely memorable that I would have a hard time believing I built an entire
thing before I noticed.

------
Mc_Big_G
I've had 10+ interviews in the last month and it's really a shit process.
First of all, I'm terrible at technical interviews. There's just something
about being in that "we're watching your every move" environment that makes me
freeze. I found myself literally reading the same for loop line over and over
again, not even trying to comprehend it, but rather zoning out on it as my
brain continued to focus on what I thought the interviewer was thinking. This,
of course, gets worse as the seconds tick on and I've said and done nothing. I
also perform terribly when I'm given a take-home "test" with a time limit. The
pressure to finish on time overwhelms my thought processes. Then you have the
asinine binary tree questions for a front-end web dev position or the "tell me
what's wrong with this horrible, obfuscated code". If I have to work on code
like that, I don't want to work there.

I had multiple interviews where I was either being video recorded (karat.io)
or on a skype call with multiple developers "evaluating" me. This is a toxic
environment and I knew in the first few mintutes I didn't want to work there.

I have a portfolio full of sites that I've built and I can tell you with
confidence that my portfolio didn't matter even a little bit. Not one employer
looked at my github account (not that it's impressive, but that says
something).

The best way to get a job is through your network. A previous freelance client
was hiring and pursued me aggressively. Why would they do that if I'm a shit
developer as thought by my various interviewers? The experience of
"interviewing" with a company that knows my work and shows a genuine
enthusiasm for having me on their team is so night-and-day different from
every other interview that the decision was easy. They gave me what I asked
for and treat me like a valued employee.

~~~
TranquilMarmot
This sounds like exactly my experience as of late with interviews, so it's
nice to know I'm not alone; unfortunately, I don't have a "network" and live
far away from where any "network" could be set up so I'm a little stuck in the
mud.

~~~
gedrap
Well, you ARE in the network right now. On HN :) networking doesn't have to be
physical.

------
RyanZAG
The pattern matching issue with Java or C# is interesting, since all these
companies generally do want mobile. So I guess the humorous point of advice
for that: replace all occurrences of Java on your CV with Android, and C# with
WinPhone, and you'll probably bump your chances of getting passed the pattern
matching.

~~~
ammon
Great advice! Mind if I add this to the blog post?

------
api
> "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 technological trend. Of those traits I can't stress over-engineering
enough... it's epidemic everywhere but most of all in "enterprise" where
you'll see insane things like simple web application servers that use
gigabytes of RAM and XML schemas that lead to ten-page-long messages to do
trivial things. (The use of XML at all is usually a smell unless the domain is
very HTML-like such as word processing... and even there extending Markdown
would be better in every way.)

It doesn't have to be that way. Those facts reflect the management pathologies
that exist in large companies and governments where you have a lot of people
managing software projects who don't know anything about software... lots of
"pointy haired bosses." You also have a lot of dumb requirements in those
areas that twist things out of alignment with what users actually want.
Startups very often have the luxury of ignoring stupid requirements unless
they have to interoperate with legacy stuff.

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. If the systematic diseases of enterprise are
that extreme (and I think they mostly are), then I understand the desire that
some startups might have to also systematically avoid developers with
enterprise backgrounds.

That being said and while I do understand, I think this underestimates the
versatility of a good developer. A good developer might have gone into an
enterprise job because they need the money but they might be otherwise great
at what they do. You can find some great developers by offering to rescue them
from enterprise hellholes. Sometimes that alone is all they need to inspire a
ton of motivation and loyalty. I mean, you just dragged them out of hades.
They're gonna love you.

~~~
rowborg
I posted this as a comment on the original post, but will make the point
here...

Large organizations are often more dysfunctional than small ones, yes,
especially when it comes to building software. But that doesn't mean they
aren't filled with very smart people. The fact that enterprise programmers
can't get hired at startups is not, in my opinion, a reflection of the
dysfunctional nature of software development at large companies, but of a
mismatch in expectations about how to communicate your ability to do your job.

As an example: one pattern I’ve seen that consistently holds enterprise
programmers back in startup interviews (especially in phone screens and
technical screens) is the inability to effectively articulate the projects
they’ve worked on. Enterprise programmers have often worked on optimizing one
small part of a very large and complex system that no one person may
understand completely, and in my experience, they often cannot describe that
system clearly or holistically. Startups usually need people who can build a
system end-to-end, and when an enterprise programmer doesn’t seem to
understand their own projects, it reflects very poorly. I see this pattern way
too often.

My suggestion (and obviously this is a gross generalization) is for enterprise
programmers who want to work at startups to practice being able to clearly and
consisely explain what they worked on and how it fit into the overall product.
Startups will care more about this than showing, for example, a deep
understanding of how Java's various memory pools work (even if they work in
Java).

~~~
moron4hire
There is also a bias against enterprise developers in that most often their
work is on proprietary systems, leaving no code artifacts to view on Github,
which a lot of companies have started using in their recruiting process.

~~~
TranquilMarmot
This has been a huge issue for me- I used to be _very_ active on Github, but
the past year or so I've been working either on proprietary systems that are
internal to the company I'm at, or working on private projects that I don't
want in public repos. So, if you were to look at just my Github profile, you'd
see almost no activity. That doesn't mean I'm not constantly working, though!

------
buro9

        The “Product Programmer” and “Technical Programmer” profiles are identical,
        except one is motivated by product design, and the other by solving hard
        programming problems.
    

This is great.

I've struggled with trying to define the difference between the great systems
engineers I meet and the engineers who make great products (sometimes at the
expense of all elegance under the hood).

This sums it up nicely... it's where the focus is. I'm surrounded by engineers
focusing on systems programming, but I don't think of myself as similar to
them, I've always been end user obsessed and customer focused. It's nice to
see this difference acknowledged.

------
soham
Hi Ammon/Harj, Thank you for that effort and laying it out. Very helpful.

Just so the readers don't miss the context: By definition, most companies
referred here, I'm guessing, are startups. And startups will definitely want
more product-focused engineers, in order to keep moving fast.

Interviewing in general, is closer to a date, than it's to a standardized
test. The smaller the company is, the more pronounced that characteristic is.
For even slightly larger companies, it's a different story.

When I was a Director of Engineering at Box, the engineering team was tasked
with hiring 25 engineers in a single quarter. For several quarters. When
hiring at that scale, it's hard to hire based on personas and elaborate
preferences. At that point, process is more important. Anyone that meets a
consistent process gets hired. There are always biases at resume selection,
but those are only to benefit the later process, and not so much of a
preference.

[About us: [http://InterviewKickstart.com](http://InterviewKickstart.com)]

~~~
mquander
_When I was a Director of Engineering at Box, the engineering team was tasked
with hiring 25 engineers in a single quarter. For several quarters. When
hiring at that scale, it 's hard to hire based on personas and elaborate
preferences._

I just watched another startup in the same reference class grow at a similar
speed, and I don't believe you. Suppose it takes 20 interview loops to hire
one very good engineer, and each loop takes on average 10 engineer-hours.
That's 200-engineer-hours per new hire, or about one engineer-month. That
means if you have 100 engineers at Box (correct me if I'm way off base here,
but 25 on 100 in a quarter sounds like a reasonable fast growth) you can hire
25 new engineers in a quarter while spending only 10% of your total labor
recruiting.

The reason this doesn't usually work is because most engineers don't spend 10%
of their time helping with recruiting. That is in my opinion an unforced
error. They should.

~~~
soham
Not sure which part you're referring to, that doesn't work.

Average 10% spend by an engineer towards hiring is quite normal, from my
experience. Obviously, it's average, so there are some who spend way more than
10%, and there are some who don't spend any. 4 out of 40 hours a week
including phone-screens, on-sites and deliberations is easy to get to.

I'm sure you know, that a lot of hiring at that scale is systematized and
(hence) heavy-lifting is done by non-technical recruiting people.

~~~
mquander
_I 'm sure you know, that a lot of hiring at that scale is systematized and
(hence) heavy-lifting is done by non-technical recruiting people._

Right, this is what I'm arguing against. Doing filtering with non-technical
people requires a lot of systematization and strange, low-quality filters. I
suggest not doing that.

The typical response is that you need to do it because engineer time is too
precious, which I disagree with.

------
jenshoop
This was a great point: "There’s more demand for product-focused programmers
than there is for programmers focused on hard technical problems." A very
talented programmer from Dropbox once told me that if I wanted to attract top
engineering talent, I needed to be able to show the engineer "a problem that
no one else has solved yet." This totally changed the way I wrote my job
descriptions and conducted interviews. Led to great outcomes, too.

~~~
random_coder
Care to explain a little? Did your friend mean that talented engineers like
working on novel problems and companies facing hard problems are thus more
attractive?

~~~
lackbeard
I read jenshoop to mean: when recruiting, describe in some technical depth,
the difficult, unique problems your company is solving to build its
product(s).

~~~
jenshoop
Spot on lackbeard ^^

------
lackbeard
This is interesting data.

I liked what Joel Spolsky said a long time ago. Basically that companies
should want two types of engineers. 1. You want a few who are experts in the
company's tech stack. 2. The bar for everyone else is just that they're smart
and they get things done.

I guess the core problem is that we don't have a good objective measure of the
latter. (Maybe an IQ test for smarts, if that wasn't political incorrect, but
I don't know how you'd show definitively that you "get things done" in an
interview.)

~~~
marme
IQ tests are not only politically incorrect they are illegal in the US. It is
illegal discrimination to make hiring decisions based on IQ scores. You can
only use a test that shows those with higher scores perform better at the job.
A general IQ test can not be shown to do that. Basically you can not ask
questions that test skills that would not be used in the job the candidate is
applying for.

You must be able to defend the metric you use for hiring and that it is not
discriminatory. If you give an IQ test that is unrelated to the job and say no
one below 100 IQ will be hired you must prove that someone with 101 IQ can do
the job but someone with 99 IQ can not properly do the job

~~~
johncolanduoni
> It is illegal discrimination to make hiring decisions based on IQ scores.
> You can only use a test that shows those with higher scores perform better
> at the job.

There is more scientific evidence that IQ predicts job performance than for
most of the more qualitative criterions that employers use in practice. The
source of the illegality of using IQ tests is not legislative (intelligence is
not a protected class[1]). It comes from the precedent of _Griggs v. Duke
Power Co._ , in which the IQ test was being used as a barrier for jobs where
IQ was not a good predictor (not programming), and prior to thorough research
on the subject. There have been hundreds of studies showing that IQ tests
predict job performance (though not super strongly) at the beginning of
careers, even though this fades once they have more experience. This[3] meta-
analysis approaches these studies very critically, and concludes that many
inflate the effect, and that it doesn't validate the IQ test (i.e. there may
be non-cognitive reasons for it) but that the correlation still exists. (For
what it's worth, I suspect they're right about the non-cognitive part since
the correlation has become much stronger over time, particularly around the
1970s. However, when your goal is to test for something and not to explain it,
correlation is good enough.)

> Basically you can not ask questions that test skills that would not be used
> in the job the candidate is applying for. ... You must be able to defend the
> metric you use for hiring and that it is not discriminatory.

No, the burden set in _Griggs_ and later elaborated in a modification to the
Civil Rights Act is not to prove that a test is not discriminatory at all.
Instead for tests that _are_ discriminatory in practice (though not obviously
in design, like IQ), you must show that the test is truly indicative of job
performance. If this were not the case, you couldn't ask if people went to
college, due to the racial disparity in college graduates. Also you can ask
things you can't prove are related to job performance if it isn't
discriminatory (not that this is really useful).

> If you give an IQ test that is unrelated to the job and say no one below 100
> IQ will be hired you must prove that someone with 101 IQ can do the job but
> someone with 99 IQ can not properly do the job

Of course you don't have to show that anyone who fails your test will 100% be
worse on a case by case basis than someone who passes. If that were the case
you couldn't justify pretty much any test other than "applicant is not dead or
in a coma." You just need to show that it is clearly less likely. I would find
it _really_ surprising if there wasn't some kind of IQ threshold effect for
programming (i.e. the closer you are to the middle of the spectrum, the better
a predictor of programming performance IQ is). That would make it easy to
justify using an IQ test as a predictor, especially in combination with the
more general studies.

I don't think IQ would be terribly useful to weed out programmers because I
suspect there are more related ways to judge applicants that would already
weed out those in the region where IQ is useful, but it is not as simple as
"IQ testing for a job is illegal."

[1]:
[https://en.wikipedia.org/wiki/Protected_class](https://en.wikipedia.org/wiki/Protected_class)
[2]:
[https://en.wikipedia.org/wiki/Griggs_v._Duke_Power_Co](https://en.wikipedia.org/wiki/Griggs_v._Duke_Power_Co).
[3]:
[http://www.tandfonline.com/doi/full/10.1080/10888691.2014.98...](http://www.tandfonline.com/doi/full/10.1080/10888691.2014.983635)

~~~
tim333
Reading the Wikipedia link on Griggs it seems to have been about requiring a
high school diploma for jobs that didn't need that as a way of keeping blacks
out. That seems a different matter to wanting to hire intelligent people to
programme?

~~~
johncolanduoni
Yes, that's precisely my point. Griggs (and some later ruling and legislation
along the same lines) established when an employer can use a test to evaluate
applicants that indirectly discriminates against a protected class. From the
article:

> The Supreme Court ruled that under Title VII of the Civil Rights Act, if
> such tests disparately impact ethnic minority groups, businesses must
> demonstrate that such tests are "reasonably related" to the job for which
> the test is required.

For programmers (as well as many other jobs), IQ (within a certain range)
could be borne out as being reasonably related. GP was claiming that it is
illegal to administer IQ tests during interviews in the US, which is not true.

------
js8
This reminds of psychological study about superstition. They studied fishing
habits of South American Indian tribes; the tribes that fished in lakes, had
consistent and reasonable rules about when/where to go fishing. However, the
tribes that fished in the ocean, where you cannot predict the catch, had
rather random and superstitious rules about when/where to go. This is due to
our brains seeing patterns in randomness.

Also, it's perhaps understandable why companies don't want to reveal their
preference. If you do it, you open yourself to being gamed. I think it's also
better to have unreasonable requirements (looking to give genius programmers
some boring product work) than be sorry. Again this happens in absence of
actual test (other than wait and see) of who is a good candidate. Females do
the same thing when mating.

~~~
ssalazar
> This reminds of psychological study about superstition. They studied fishing
> habits of South American Indian tribes; the tribes that fished in lakes, had
> consistent and reasonable rules about when/where to go fishing. However, the
> tribes that fished in the ocean, where you cannot predict the catch, had
> rather random and superstitious rules about when/where to go. This is due to
> our brains seeing patterns in randomness.

Thats really interesting. Would love to read more about it if you have a
source for that off hand.

~~~
js8
It comes from this lecture
[https://www.youtube.com/watch?v=P_dLJ1FxGuo&list=PLRKa53-za1...](https://www.youtube.com/watch?v=P_dLJ1FxGuo&list=PLRKa53-za1rJb_rJdNmqQUhJWqFdeQijH&index=13),
around 10 minute mark.

------
jphelan
I had such a disappointing experience with Triplebyte. I take their automated
test and everything is hunkydory. After that they gave me a very ambiguous
technical interview live-coding session without an interviewer. It seemed like
an unreleased feature or a trial a/b test variant. Even now I go back and
they've removed every reference to a "programming challenge"!

Anyway, the problem involved writing a tree generation/traversal along with a
little equation parser and a lot of string parsing (I think, at least). I was
really uncomfortable because while it said "we will run this code" I didn't
know what their expectations where (In what environment are they going to run
the code? Is underscore ok? They said "you can't use built in eval" so do they
really want me to write my own eval? Do they care if I look on stackoverflow
for string parsing stuff?). I only had an hour for a difficult problem and I
spent most of the time wondering what they really wanted and stressing out
about little details that wouldn't consume ten seconds of thought on the job.

I've interviewed a lot and I'm pretty confident from a lot of experience
whiteboarding code or typing up an answer on the spot in interviews, so this
was very frustrating and I found it to be disrespectful of my time.

------
iopq
> He solved hard algorithm problems like they were nothing

That's mostly practice. When I did webdev I was really shitty at algorithms
because there were no algorithms in my daily work. When I did some Baduk AI
programming I started being much better at algorithms since I was implementing
some custom algorithms myself.

If you are interviewing someone for a web dev position, it's kind of
ridiculous to screen people by their ability of merging sorted arrays or
whatnot.

~~~
mavelikara
You highlight a very important point. Doing well on algorithms in interviews
only needs some dedicated practice. It is NOT a signal for higher intellect as
many people misunderstand it to be.

------
exelius
Well, consider that there are well documented academic studies (that I can't
be bothered to look up right now) showing that most hiring processes are no
better than throwing darts at a board with regards to retention rate, employee
success, and every other measure of success of the HR process. The only thing
that is remotely effective are IQ scores, and even then it's only a weak
correlation.

So regardless of what the companies want, it's near impossible to accurately
judge someone in an interview process. Even if you know what you want, it's
very difficult to assess how someone is going to perform in a job through an
interview process. The main benefit of interviews IMO is to help managers
"buy-in" on hiring decisions.

~~~
Matt_Mickiewicz
Not true.

Actually work sample tests have a .29 correlation to on the job performance,
followed closely by structured interview questions.

See: [http://www.wired.com/2015/04/hire-like-
google/](http://www.wired.com/2015/04/hire-like-google/)

~~~
exelius
The work I'm referencing specifically called out Google as an example of an
overly-complex practice that didn't result in objectively higher quality
candidates. Google's overall quality of engineering talent is high because
they are quick to push people out the door if they don't meet the high
standards. Regardless, it's very difficult to scale Google's hiring practices,
and it's overall seen as a growth limiter for them (even by people internally
- it can take 3-6 months to hire one candidate).

------
steven2012
What is the point of interviewing through TripleByte and going through their
interview process, if I just have to interview with the YC company again? It's
something I would completely avoid. I already know that almost 100% of the
companies I send my resume to will respond, so what is the point of adding
another set of interviews, which as the article points out, only adds a random
level of success.

~~~
ammon
Several reasons: 1) people who go through us skip the screening steps and go
straight to a on-site interview at the YC companies. 2) We've sent a bunch of
people to most of these companies, and have a good idea what they are looking
for. We help you avoid failing interviews for the reasons mentioned in this
article. 3) Perhaps you have no trouble getting responses to your resume, but
a lot of (strong) programmers do. We help them. 4) We help candidates
negotiate offers.

~~~
asmdb
I went through the initial TripleByte process earlier this year but was
rejected. I passed the initial multiple choice programming test, but I failed
miserably at the 1 hour programming exercise. I actually found the problem to
be one of the more difficult algorithm type problems I've encountered in an
interview situation. I am curious if the problems chosen by Triplebyte are
representative of the typical types of questions for YC company interviews? I
can't imagine they all have identical pre-screening processes, so how do you
choose representative problems?

------
sloanesturz
I would love to see this kind of analysis (i.e. Junior Programmer vs. Child
Prodigy vs. Rusty + Experienced) as it applies to hiring women. Are there
biases against women with different experience and different "culture fit?"
Would be a neat way to apply your data and your company contacts.

~~~
ammon
We will be doing this analysis

------
swalsh
Former C# programmer here, in my most recent job hunt I rewrote my resume. I
talked more about the value I provided for my company/customer (what the code
did) rather than how I wrote the code. I'd say my results improved
significantly in terms of getting my foot in the door.

~~~
TranquilMarmot
I do mainly C# at my current job, so it's pretty prominent on my resume;
perhaps I'll try a rewrite and focus more on _what_ I've done rather than
_how_ I did it. Sounds like a good idea.

------
a-dub
When I look to hire a lawyer, I'm going to evaluate potential candidates by
asking them to write statutes from memory in full on a whiteboard under time
pressure, because I really want to see how well they think on their feet.

As a forward thinking technology executive, I am certain this strategy is
correct, because Google does it.

~~~
DrScump
If you are going to hire a lawyer, you should be more interested in their
knowledge of _case law_ rather than how well they memorize statutes.

~~~
a-dub
We understand that our hiring process produces a lot of false negatives, and
given that our applicant pool is already generally of high quality, we are
able to fool ourselves into thinking that it has been a key to our ongoing
success.

Perhaps more importantly, we're not going to change it because this is how
Google does it.

------
tdaltonc
I like the ontology of programmers. Are there any other efforts to do this?
Anything data driven or externally validated?

Given what a big role personas and demo/psycho-graphics play in marketing, I'm
surprised that I haven't heard more about then in the context of hiring and
managing.

~~~
ammon
Yeah (author of the blog post here), I think it's a powerful idea. I don't
know of any other public attempts to do this (most ideas about hiring stay
locked up inside companies). I'd love to hear any ideas you have. Email me at
ammon@triplebyte.com

~~~
NhanH
Out of curiosity, on the taxonomy of programmers, is that supposed to be
mostly exclusive, or can they overlap?

~~~
tdaltonc
Not the author, but I know about ontologies generally. Non-overlapping is
great, but rarely possible because whatever you're trying to organize might
not divide up that way. Next best is eigenvectors. You would find the "pure
types" of programer such that each real programer would a linear composition
of the pure types. This is really handy for doing statistics. But you might
run in to trouble if programmers don't have interaction free types. Beyond
that you can use more elaborate interaction models, but those are more of an
art then a science. They require a lot of domain expertise to design.

Hope that helps.

~~~
brianchu
Bit of a nitpick, really, but you want a basis, not necessarily just a set of
eigenvectors.

------
lewisl9029
I apologize for being completely off-topic, but I find it completely
ridiculous that we have to scroll past half the page to see the next highest-
level comment.

Are there any plans for implementing collapsible comment threads?

~~~
jakub_g
FYI HackerWeb has collapsible threads:

[https://cheeaun.github.io/hackerweb/#/item/10698009](https://cheeaun.github.io/hackerweb/#/item/10698009)

It's designed for mobile web, but just zoom in and it should be fine

------
minimaxir
For a blog article under a data subdomain, there's surprisingly few numbers
and quantitative analysis, which is disappointing. And one matrix of survey
data as the only visualization.

I get that startups do not want to reveal their competitive advantage, but
there has to be some give-and-take. Taking an analysis on blind faith alone is
frustrating.

~~~
reitanqild
I found the detail level close to perfect. It explains a lot of my feelings
towards the recruitment process.

~~~
minimaxir
That's confirmation bias, which is dangerous especially since a lot of people
in this thread seem to have similar sentiment.

Quantitive data would confirm if the patterns are stereotypes or not.

~~~
reitanqild
Well you could also read it as a rare look into what goes on on the other side
of the table, couldn't you?

------
sremani
>>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.)<< This
makes me sad. I do not know who the caricature here is, the Enterprise
programmer or the YC companies.

~~~
rjbwork
YC Companies most likely. I've been doing C# for 3 years, none of which was in
an "enterprise" company. Both were/are small software companies in a SaaS
environment on the cloud (AWS/Azure).

I would laugh if a company rejected my proven ability to build giant
distributed systems in the cloud because they were built in C#.

------
ditonal
Keep all these spurious rejections and arbitrary hiring processes in mind next
time pg or BigTech's lobbyists bemoan the desperate shortage of great
programmers.

------
datashovel
I think the recruiting problem in technology in general is that programmers
don't meet and interact with enough different types of programmers in work
settings, so they really don't know what they want or what they should be
looking for.

I'd suggest everyone start doing this instead:

For anyone who meets basic criteria / filters, hire them at least part time,
and put them to work. If they don't make the cut 3 months later (based on some
objective criteria) let them go. Then after you've done all your recruiting
like this maybe 1-2 years later evaluate what your team consists of.

It's not even a question in my mind. I'm not 99% sure. I'm 100% confident the
team will not look like the recruiting team originally envisioned it would
look before they started hiring.

EDIT: And I'm 100% confident those teams will consist of an overall better
quality of engineer, and putting out higher quality products, than they
would've ended up with if they stuck with trying to find what they believe to
be the right "culture fit" or some concept of what a "prototypical engineer"
is / should be.

------
bluecalm
The discussion about interviews comes down to a fact that if you setup your
interview as a test where you position yourself as a chooser you will attract
people who need you more than you need them. The best people are going to pass
as they have enough options elsewhere.

For example I would be very happy to interview for Google 2 years ago and
endure the process. Today I could sit with them for an hour and talk about
stuff while sipping coffee. I have more opportunities than I can pursue anyway
so spending hours solving mazes like some kind of a lab rat is not something I
am going to spend my time on.

I am not a top expert in what I do but I can write and ship code. People like
me (and especially ones better than me) will just not show up for your
"process". Either you pursue them or you won't meet them. You will only get
people for whom you are so attractive an option that they are willing to
donate several hours or a whole day to have a low % shot. Those will not be
the best programmers as the idea of paying to get evaluated is not something
people with options entertain.

------
mercurial
> The company told us they valued process more than raw ability, and he’d not
> written tests during the interview.

Who the hell writes tests during an interview?

~~~
atom-morgan
Or why not ask him, "Would you mind writing a few tests as well?"

------
bjacks
I'd really like to know what it is about a resume or in an interview that
makes someone seem like more of a 'product programmer'.

Is it the particular things they have worked on at other jobs, i.e. their
experience, or is it the way they talk about what they want to build?

I'd be really interested to hear how I can make myself sound like more of a
product programmer.

~~~
zachrose
Use white space and minimal typeface variation in all your written materials.

Describe past work in terms of what was made, not tech used to make it.
Relegate tech buzzwards to a minimal "skills" section of your resume.

Use the words "make," "things," and "world" liberally. Say you got into
programming to make the things that you wanted to see in the world.

Have examples of things, especially small things, that a non-technical person
could use or see.

Have a BFA in some quasi-technological process like stone lithography or
ceramics. Describe approaching software with a similar sense of craft.

~~~
vonmoltke
Don't forget to make sure your minimal skills section includes at least one
language or framework that requires a Mac to use.

------
superuser2
This is oddly reassuring. Imposter syndrome is practically guaranteed when
there is a 99% chance that you only got (or could only get) a good job by a
failure of the interview process, since so many companies proclaim to only
hire the top 1%.

Goes to show that there is a far-greater-than-1% chance that you're
legitimately in _somebody 's_ top 1%.

------
karmacondon
When it comes to hiring, I think that the team is more important than the
individual. As the beginning of the piece stated, it's not so much about
individual characteristics as it is culture/process fit. I think the main
takeaway for applicants is not to take interview rejection personally. Even if
you do everything "right", you still might not be what they're looking for.

Ultimately, I don't think that individual programming ability matters that
much. It's extremely rare for the technical talents of one person to turn a
company around. Some people can inspire others and turn dysfunctional groups
into great teams, and there's never enough of that. But said great teams are
ephemeral, like sports dynasties. All a company can do is try to avoid toxic
employees and hope that the magic happens.

~~~
vskarine
I totally agree with you. A good, recently published book, to read on this
topic is 'Team Genius'.

------
staunch
_" I remember the first time I interviewed for a front-end programming
position and got asked how to do something in JavaScript on a white board. The
specifics are vague, but it’s crystal clear how stupid it made me feel and how
little it had to do with the actual job."_

...

> _" The only reliable gauge I’ve found for future programmer success is
> looking at real code they’ve written, talking through bigger picture issues,
> and, if all that is swell, trying them out for size."_

[https://signalvnoise.com/posts/3071-why-we-dont-hire-
program...](https://signalvnoise.com/posts/3071-why-we-dont-hire-programmers-
based-on-puzzles-api-quizzes-math-riddles-or-other-parlor-tricks)

------
pron
So someone programming in Java at IBM or Oracle with a mostly academic
experience would be all but completely unhireable by YC companies.

Incidentally, it was precisely that kind of programmers who built Watson at
IBM, possibly the most impressive software of the past decade, which is not
only both academically _and_ technically challenging, but also brilliantly
packaged and marketed and probably very lucrative to boot.

The exact same is true of the Graal team at Oracle, who have made what is
probably the biggest breakthrough in compiler technology in the last decade,
and might well power many important technologies in the near future (Ruby,
server-side JS, R) as well as commercial Oracle products.

------
lazyant
So, random.

Also the company interviewing the first candidate, couldn't they just told him
that they wanted testing?

~~~
trishume
Indeed, it's an issue when interviewers believe that the best candidates will
feel a compulsion to test their code without being prompted. I worked at a
company that was big into TDD without ever having done it before, it was no
problem and I wrote lots of tests, and so did everyone else on my team who
didn't have a TDD background before.

On the job people will tell you if they expect tests, so why interview people
in a different situation?

------
darkerside
I couldn't help noticing that "Strong Junior Programmer" stands out from the
rest. It as a category suffers from juxtaposition with "Child Prodigy
Programmer". The "Strong" prefix sounds like a meaningless qualifier that only
serves to blunt the label of "Junior". I have to guess that the reason
companies select out of this category is that the candidates are perhaps not
qualified.

~~~
marshray
Either they want the candidate to be physically strong, or more likely,
they're really looking for some other qualities which they can't easily
summarize.

------
krmmalik
I really liked how this analysis was done. Though i dont work in recruitment i
have to work with CEOs often and notice similar approaches to hiring for other
job roles as well. Way too similar in fact. I'd love to meet a recruitment
company that is taking the same approach as TripleByte or perhaps TripleByte
will aim to address other fields at some point. Either way its exciting.

------
Jemaclus
Some companies reject people based on green card status, because they don't
have the resources to sponsor them. Some companies have specific salary
ranges, too. Are those factors considered during your analysis? You seem to be
focusing primarily on what companies want, but sometimes what they want and
what they can accept are two different things. Thoughts?

~~~
ammon
We asked about visa sponsorship. We did not ask about salary. The general
pattern with visa sponsorship was that small companies don't want do it, out
of concern about the success rate (only 30% of H1B applications last year won
the lottery). Some large companies will sponsor visas, but they set a higher
bar (they have to be really excited to take on the extra work). The exception
is larger companies with teams outside of the US (several YC companies have
offices in Canada) to take advantage of different immigration restrictions.

~~~
biztos
Doesn't this imply that a branch development office, in a country with
friendlier immigration policies, should be a high priority for almost every
US-based startup?

I assume most startups want to grow their engineering headcount (there are
exceptions, of course). The pickier/more-focused you are about what kinds of
engineers you want to hire, the more you have to gain from casting a wider net
geographically.

But if you find the perfect teammate and she can't come to your main country
due to visa restrictions, or maybe even _won 't_ come because the immigration
story isn't worth the trouble, then what are your options?

I'm not talking about money here, though of course that will be a factor for
some people. It just strikes me that the "YC companies with offices in Canada"
have a serious recruiting advantage over those without, once they need to
seriously grow their teams.

~~~
finance-geek
Not really, until you have scale. It costs a lot of time/effort/money to
maintain multiple offices. There is lots of waste as communications break
down. You end up spending on flights/hotels just to get people on the same
page. This is not to say it cannot be done, just that it takes more directed
effort, which not all employees have or care for.

At larger scale, it makes a LOT of sense and is done regularly.

Some times, it can be a hiring _DIS_ advantage, as candidates run away from
jobs where they need to wake up in the early hours for a conference call and
also need to jump on conference calls at 11pm.

I do this currently, we have a dev team in the Ukraine. It is worth it price-
wise, but the cost not accounted for is my personal time, i'm often on
conference calls during kids' bedtime story telling.

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

THIS. In other words, the good ol' boy system still exists, only under the
moniker of "meritocracy."

~~~
clbrook
This article might help explain that:
[https://news.ycombinator.com/item?id=10659600](https://news.ycombinator.com/item?id=10659600)

------
dlwj
Employees these days have a paradoxical role to fill. On one hand, the value
in an employee is the ability to solve a problem. On the other hand, they have
to market themselves as passionate people. The only way to do so is to exclaim
interest in interesting subjects which often are directly tied to company
concerns.

Say a company needs good testers. I would find it very hard to sell myself as
a passionate tester. Instead I would say something that's actually interesting
to me like AI or machine learning.

In order for something to be interesting, it has to be somewhat unknown. How
can you be interested in something you have completely mastered and know
everything about. It just becomes process for you.

------
Animats
This data needs to be related to the size and stage of the company. That
YCombinator companies want UI people with application development experience
reflects the YCombinator startup approach - it's all about the cool demo.

The requirements may be different in the later-stage companies. But most of
the startups never get there. So looking at recruiting goals on a per-company
basis from a VC pool will generate a bias towards the skills needed for the
cool demo. What Lugg needs are people such as the article suggests. What Uber
needs at its current scale is quite different. Uber will hire far more people
than Lugg, but it's weighted the same in this model.

------
bro-stick
There is a subtle danger in only selecting candidate (people) whom think, act
of look like you... the venture may end, not for a lack of talent or
capability, but for a lack of ideas or questioning the normative, cultural
convention.

Hire tortoises, hedgehogs and hares, introvert and extroverts, peacemakers and
activists ... so long as there is respect, civility and productivity, because
it's the "pulling" away from the center of gravity and institutional momentum
that leads to exploring other great opportunities of venture successes that
weren't originally founders' core product.

------
gizi
I am growing less and less negative about recruiters. They can be a bit pushy,
but I think that recruiters can learn how to modulate and not exaggerate. If a
company wants good candidates, it will have to go to them, because the good
candidates will not come to them. Good candidates are usually already too busy
to bother. That leaves the company no other choice than to appoint a recruiter
and try to take the initiative in contacting the good candidates anyway.

------
UK-AL
Enterprise programmer bias? Could be higher salary expectations?

------
cageface
So companies want people that can build and ship products, and hire for them
based on their ability to solve tricky CS problems on a whiteboard?

Something seems amiss here.

------
Joof
Well if people really want product-motivated engineers, I'm going into the
video games field. Also becoming a game designer.

I guess the ideal place for the technically motivated is in large companies
like Google/Microsoft or in open source. Should we get a masters and find
something more suited to our interests? I'm not sure what the answer actually
is.

------
pcmaffey
Are you analyzing performance / satisfaction after getting hired? Would be
interesting to see distribution across types.

------
abrbhat
I guess the reason that product programmers are most desirable is that most
founders are product programmers themselves.

------
dennisgorelik
There is a good reason why startups prefer Product Programmers:

If you focus on product, then you have strong feedback loop in your design and
development cycle: you regularly see how users interact with your product and
improve.

If your focus is on technology, then there is almost no real feedback and you
are likely to optimize something not very valuable.

------
facepalm
"interest in ML as a negative signal"

Why, though? Is it because a candidate would be too interested in other things
than focusing on mundane web development? Passionate about programming doesn't
square well with passionate about ML, because the latter is not so much about
programming?

------
abvdasker
> "Reading bios of founders and applying to companies where the CTO shares
> your background is probably an effective job-search strategy"

My takeaway is basically that in an organization of sufficient size founders
should have little or nothing to do with technical hiring.

------
thaumasiotes
> We do our interviews without looking at resumes (in order to find great
> people who look bad on paper)

They don't ask for a resume, but the first thing that comes up in the
interview is "where have you worked in the past, and what did you do there?"

~~~
ammon
So, we ask at the beginning to talk about a programming project that you've
done it in past, but not about where you've worked. We don't ask for a work
history until the end (by which point the notes and scoring that go into the
final decision are over). We ask at the end so that we have the data to write
posts like this.

~~~
thaumasiotes
Perhaps you've changed your policy? I'm pretty sure that's how my first
interview started off. When I asked how that fit in with the advertising of
"get a job based on something other than your resume", the response was "well,
companies do care about which other companies you've worked at".

After the second interview, I was given to Harj and he asked me about work
history _again_...

(Also, since I applied through the project track, I don't think there was much
in the way of "tell us about a project you've done in the past".)

------
joshavant
It feels like this article contains a huge amount of bias. To sum it up in a
sentence... of course 'founders' all want 'product programmers'!

Ask only tenured, hands-on CTOs, and I bet that table would come out much
different.

------
j2kun
I am _very_ interested in which of these companies are the outliers. What is
the one company in the table that expressed a dislike for product-focused
programmers? Which are the few that like academic programmers?

~~~
ammon
I can't give company names, but we've not seen much of a pattern. It really
seems to have to do with the backgrounds of the founders, and who the early
successful hires were. This sets an engineering culture going forward.

------
staticautomatic
It's what your data "show." Not what your data "shows." I am always skeptical
of the analytical competence of someone who uses incorrect language to
describe their own work.

~~~
Nadya
"Is `data` a singular or plural entity?" is a question you should ask
yourself.

In this case their data is a collection or mass of data - and is _singular_.
In the blog, using "the data shows that" is the proper way to write the
statement.

~~~
chipsy
This may be a British/American English gaffe. Collective nouns in British
English are referred to using plurals, e.g. "Apple are planning a new
product," vs. the American "Apple is planning a new product."

~~~
Nadya
Perhaps. I know it as a more modern linguistic split that isn't really related
to the British/American divide. Regardless of the reason, many linguists would
laugh someone like them out of the building. Living languages are _constantly_
changing and while somewhat steady rules ensure there is less confusion - the
majority will always win.

If the majority of people refer to collective nouns as singular than that _is
the correct_ way to use them because the "correct way" is only ever defined by
the majority.

How is the pronunciation of a word decided? Majority of people saying it one
way. How do people agree upon the meaning of a word? Majority of people using
it to mean something. How does grammar become more lax? Majority of people
speak with fewer restrictions.

i contest the moderne way of speech is to be thovght proper as he has argvede,
bvt the olde way of speeking is the trve way!

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

How were you determining which YC companies were top?

------
axplusb
I would be interested in A/B comparison of company responses according to
immigration status (i.e. whether or not a candidate needs visa sponsorship).
Any data available?

------
yks
In this thread people stress how it is important to learn new things. And then
how showing interest in a new thing (Machine Learning) is a red flag. Go
figure.

------
natmaster
Why does this contradict the myth that silicon valley is ageist and only wants
to hire fresh college grads?

------
dustingetz
How does compensation play into these results? The 9 categories will have very
different comp profiles

------
DrNuke
Pattern here is you are better if you start up instead of looking for a job.
I've seen many and many mediocre engineers becoming employers just to spare
themselves rejection.

------
sytelus
The biggest issue in interviewing is the bad inexperienced interviewers. It's
very very hard to be a good effective interviewer and in my experience even
otherwise very smart programmers are not great at this. Here's few things that
would help to find better match and eliminate lot of false negatives:

1\. Pre-filtering should be based on candidate's public contributions at
places like GitHub, StackOverflow, Wikipedia etc. Pre-conceived notions of
someone being C# or academic is just simply bad.

2\. Don't ask question that you didn't had to solve doing your job. It's
absolutely the hardest part for interviewer to come up with great questions
that distill the problem they had solved on the job in to something that can
be described in 10 mins and worked on in about hour. Most interviewers are
unable to do this and fall back to puzzles stolen from websites or coworkers
like them. If you are not smart enough to form the great question using actual
problems in your job than you have no business being an interviewer.

3\. Don't do 45 minute interviews. That time is too short. Candidate has
already taken a day off, there is no reason why you should limit each
interview to 45 mins and make candidate rush. Countless great candidate get
eliminated because they fall short of 15 mins, do longer initial chit-chat or
just take one wrong turn.

4\. Strongly discourage interviewers to look for exactly the right answers.
Again hard to do than said. Most candidates that sail through problem have
very likely practiced similar problem to death. The bad interviewer than
penalize candidates who hadn't practiced that same problem VS who luckily
happened to do so. Ultimately you are required to eliminate 80%-99% of
candidates and this comparison is so handy that interviewers fall for it
despite of knowing it.

5\. Good interviewers knows the trickiest part of the problem and are willing
to help out candidate without penalties. Bad interviewers considers any hints
or help as sign of weakness and are mentally subtracting points. If you are an
interviewer who thinks that your job is to give problem, sit back and watch
the show then you are wasting everyone's time. Good interviews are lively
discussion, two way conversation and in fact a collaboration.

6\. Bad interviewers ask seemingly easy problem but that has chance of making
a big tricky mistake or omission. Interview turns in to sport spectacle to see
if gladiator candidate was able to duck the fire from the dragon that was
behind him. Good interviewers make sure problems are real problem and not a
competition to set up traps that everyone easily falls in to.

It's kind of bizarre that most companies claim that they have huge headcount
to fill and they don't find talent while their "rejects" have already been
having great jobs at great companies with nice history of career growth and
compensation raises. The real problem is bad inexperienced interviewers who
have been molded to ask same puzzles they had been asked and have been trained
to have expectation for candidate to magically arrive at correct answer with
error free compact code under 30 minutes. It's utter nonsense. The result is
that most candidates now keep working on puzzles for months which has little
relevance to actual problems in job and not even a remote indicator of
candidate's passion or ability to take initiative or collaborate or ship
something in real production consistently.

