28 ms·

Who Y Combinator Companies Want

• phlandis 11y ago
  If you're still in school build a product before you graduate. This will act as your resume and speak louder than your degree.
• minimaxir 11y ago
  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 11y ago
    I found the detail level close to perfect. It explains a lot of my feelings towards the recruitment process.
    • minimaxir 11y ago
      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 11y ago
        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 11y ago
    It is not what you know, but how you tell the story :) Human condition never changes, we are just emotional creatures and perception is reality. It is true in recruitment process, all these new fixes to recruiting are a different versions of that.
• cogware 11y ago
  "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)?
  • tdaltonc 11y ago
    probably because ML is the hot new thing. People that are interested in a hot new method (especially if there "excited to learn!") instead of the results that that method can product (a better product) are prone to running down technical rabbit holes over shipping.
  • exelius 11y ago
    Because ML/AI are feature enablers. They make a good product better, but they won't make a product successful. It's a signal that people are more interested in solving technical problems than solving business/product problems.
    • Alex3917 11y ago
      Also, a large percentage of ML/AI projects are scams. And even the people who aren't scammers tend to massively underestimate the amount of work required to make something good. It doesn't surprise me at all that interest in these technologies could be a red flag on multiple levels. Sure there are plenty of great startups built with these technologies, but both also tend to be the 'and then a miracle occurs' of the tech industry.
    • facepalm 11y ago
      So Google without good AI would be still as good because of the neat interface? Self driving cars would be just as good without good AI? I get what you mean, and it might be true for a lot of products. But there are also products were good AI is the core.
      • 11y ago
• tdaltonc 11y ago
  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 11y ago
    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 11y ago
      Out of curiosity, on the taxonomy of programmers, is that supposed to be mostly exclusive, or can they overlap?
      • tdaltonc 11y ago
        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 11y ago
          Bit of a nitpick, really, but you want a basis, not necessarily just a set of eigenvectors.
    • tdaltonc 11y ago
      You might not be able to share it, but I'd love to see a covariance analysis on that matrix. You have this hypothesis that companies hire based on some sort of culture. Is that culture random or are there types of culture? Product-focused v tech-focused. test-driven v code-review-drived. If so, the companies hiring practices should cluster. This would be very useful for triplebyte to know. It would tell you very quickly who this or that company would like, without just throwing a bunch of candidates at them and seeing what sticks.
• exelius 11y ago
  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 11y ago
    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 11y ago
      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).
  • endrebak 11y ago
    According to the psychometrics books I have read structured interviews are as good as IQ-tests when it comes to predicting job-performance. All types of hiring tests/interviews had some predictive power (except handwriting analysis).
• deleted 11y ago
  [deleted]
  • reitanqild 11y ago
    Patently false. Just because you get hired every time you have experience with a companys tech stack doesn't mean a lot of us has to jump through a lot of hoops without knowing why. Me? I have wondered if I should make job applications a hobby regardless if I want a new job right there or not. (oh, btw: I have had good work, without time between since 2007, when I had a few weeks between two jobs. I'm just so tired of wasting time on the recruitment process.)
    • deleted 11y ago
      [deleted]
      • reitanqild 11y ago
        I have been hired without experience: that was how my Java career started. Basically it went like this: registered with recruiting agency - got a call a few days later asking if I would like a plane ticket - met up with the company next time I crossed the mountains anyway, told them I knew next to nothing about Java, was told that I looked smart and as long as I picked it up within the next 6 months they would be happy. So I started after my summer holiday and was fixing bugs within the first week. At that place everone including our designer could code because they made sure to make it easy to get started. Since then I try to do the same. Edit: this is also the only time recruiting agencies hasn't been a complete and utter waste of my time.
        • deleted 11y ago
          [deleted]
          • reitanqild 11y ago
            To be honest I was honest at time as well and announced loud and clear that I knew nothing about Java. For those people smart seemed to matter more than experienced.
• ryandrake 11y ago
  > "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.
  • draw_down 11y ago
    A good example of why working at a place with such restrictive PTO is a trap. But, around here we like to have philosophical discussions about how unlimited vacation time is the real trap. I dunno, guys. It seems to work pretty well for me.
    • metamet 11y ago
      Or just start off with a proper number of days. Two weeks seems so short, especially if you get sick. 15 days total seems about right.
      • jenshoop 11y ago
        Was just having this conversation -- is there any precedent for offering different teams and/or differing levels of tenure different vacation packages? My husband used to work at Groupon and said it was really challenging to give all entry-level sales people unlimited vacation because they tended to abuse it. However, unlimited vacation may work well for more tenured positions or even for different types of teams (engineering / design?) We thought this might be too tricky to administrate / unfair, but it does seem that it can be a useful and underabused perk for some and a disaster for others.
• RyanZAG 11y ago
  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 11y ago
    Great advice! Mind if I add this to the blog post?
• deleted 11y ago
  [deleted]
• api 11y ago
  > "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.
  • frostmatthew 11y ago
    > 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 (<100k loc) that haven't been around very long and most likely won't continue to be in use for long. That's not productive when you're working on a product that has millions of lines of code and has been in use for years (and most likely will continue to be so). 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 this week.
• Jemaclus 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
        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 DISadvantage, 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.
• buro9 11y ago
  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.
• lackbeard 11y ago
  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.)
  • tstock55 11y ago
    I accepted an offer at IBM a few months ago and had to take an IQ tests of sorts. It was mostly focused around pattern recognition with some algebra problems thrown in. At best it seemed only tangentially related to programming ability.. I'm not sure that attempting to measure whether a candidate is "smart" or not is a good hiring strategy. A good analogy for this type of interviewing is like trying to judge how good someone is at basketball by measuring how tall they are. Is it related? Sure. But it certainly doesn't give you the whole picture and might not be a useful information at all. Watching them play a few games would be a better strategy. Fortunately there a quite a few startups working on this problem. Lytmus is one in particular that I think looks very promising.
  • marme 11y ago
    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 11y ago
      > 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.983635 http://www.tandfonline.com/doi/full/10.1080/10888691.2014.98...
• swalsh 11y ago
  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 11y ago
    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.
• jonathankoren 11y ago
  "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 11y ago
    This article might help explain that: https://news.ycombinator.com/item?id=10659600 https://news.ycombinator.com/item?id=10659600
• mercurial 11y ago
  > 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?
  • sharemywin 11y ago
    people who want jobs at test driven development shops.
  • atom-morgan 11y ago
    Or why not ask him, "Would you mind writing a few tests as well?"
  • bumbledraven 11y ago
    Uh, yeah. That company sucks. [edit: well, their interviewing process sucks.]
• jenshoop 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
        Spot on lackbeard ^^
• karmacondon 11y ago
  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 11y ago
    I totally agree with you. A good, recently published book, to read on this topic is 'Team Genius'.
• staunch 11y ago
  "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-programmers-based-on-puzzles-api-quizzes-math-riddles-or-other-parlor-tricks https://signalvnoise.com/posts/3071-why-we-dont-hire-program...
• js8 11y ago
  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 11y ago
    > 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 11y ago
      It comes from this lecture https://www.youtube.com/watch?v=P_dLJ1FxGuo&list=PLRKa53-za1rJb_rJdNmqQUhJWqFdeQijH&index=13 https://www.youtube.com/watch?v=P_dLJ1FxGuo&list=PLRKa53-za1..., around 10 minute mark.
• lazyant 11y ago
  So, random. Also the company interviewing the first candidate, couldn't they just told him that they wanted testing?
  • trishume 11y ago
    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?
• superuser2 11y ago
  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%.
• deleted 11y ago
  [deleted]
• deleted 11y ago
  [deleted]
• throwaway456789 11y ago
  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.
  • deleted 11y ago
    [deleted]
  • JustSomeNobody 11y ago
    I think age-ism is part of it. However, being an Enterprise dev myself (kind of), I feel that Startups don't think Enterprise devs "move" fast enough. They are too busy abstracting things and trying to get to the holy grail of the "perfect" architecture. Startups don't necessarily care about that right away, but enterprise devs have been steeped in it.
    • eldavido 11y ago
      Yeah well, that depends on whether you're used to working on a mature project with lots of structure and process (and usually, customers) or something newer where you're more in POC mode. I'd favor someone who could do either but I guess if you have to pick one or the other I'd take "hack and ship" over "let's make it perfect", especially considering the second probably has lots of great options at BigCo.
  • sgarman 11y ago
    I think a lot of companies want to hire people who also have programming as a hobby. It seems if this was true it would be very unlikely that someone would be a seasoned great programmer who only ever programmed in one language. I'd be curious why this candidate never wanted to try other styles/approaches.
• xiaoma 11y ago
  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 11y ago
    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 11y ago
      > 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 11y ago
        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)
        • 11y ago
• sremani 11y ago
  >>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 11y ago
    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#.
• bjacks 11y ago
  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.
  • deleted 11y ago
    [deleted]
  • zachrose 11y ago
    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 11y ago
      Don't forget to make sure your minimal skills section includes at least one language or framework that requires a Mac to use.
  • taurath 11y ago
    As someone who describes themselves as such and has had good success - demonstrate that you care more deeply about the success of the product than "technology" itself. Code is a tool to solve those problems - focus on what has worked and not worked in coding, rather than what is cool and exciting. Its more of a mindset thing than anything - spend enough time actually being interested in business problems rather than CS problems.
  • d0m 11y ago
    Talk more about the product you built (What worked, what customers said, how was it improved overtime, what did you learn from customers using the product and talking to them), rather than going in detail about the technical requirements of the product (Used technology, improved loading time by n%, rewrote using a different framework). And the reason why it's important is because startups fail because of bad value propositions, not lack of technical expertise.
• sloanesturz 11y ago
  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 11y ago
    We will be doing this analysis
• ditonal 11y ago
  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.
• Fiahil 11y ago
  > 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 11y ago
    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 11y ago
      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.
      • 11y ago
• etr71115 11y ago
  > "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?
• dustingetz 11y ago
  How does compensation play into these results? The 9 categories will have very different comp profiles
• UK-AL 11y ago
  Enterprise programmer bias? Could be higher salary expectations?
• UK-AL 11y ago
  Enterprise programmer bias? Could be higher salary expectations?
• krmmalik 11y ago
  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.
• soham 11y ago
  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 11y ago
    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 11y ago
      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.
• darkerside 11y ago
  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 11y ago
    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.
• moron4hire 11y ago
  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 11y ago
    Very cool! Wish more companies approached it like this.
• pcmaffey 11y ago
  Are you analyzing performance / satisfaction after getting hired? Would be interesting to see distribution across types.
• natmaster 11y ago
  Why does this contradict the myth that silicon valley is ageist and only wants to hire fresh college grads?
  • phlandis 11y ago
    They still want young self motivated talent.
• thaumasiotes 11y ago
  > 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 11y ago
    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 11y ago
      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".)
• lewisl9029 11y ago
  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 11y ago
    Maybe you only remember the super technical parts because the product-focused parts were effortless for you.
    • hawkice 11y ago
      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.
• axplusb 11y ago
  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?
• j2kun 11y ago
  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 11y ago
    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.
• steven2012 11y ago
  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 11y ago
    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.
    • steven2012 11y ago
      I think there is probably value for inexperienced programmers, or people that don't know how to properly write their resume, but for experience programmers, it seems like an unnecessary extra step. Going through a bunch of interview questions from TripleByte just to skip a 45 minute phone screen is absolutely unnecessary and not worth it, especially since you will have to go through the entire onsite anyway. As I mentioned, I had about a dozen interviews, with both YC and non-YC companies, and had no trouble getting contacted directly by any company.
    • asmdb 11y ago
      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?
• Mc_Big_G 11y ago
  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 11y ago
    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 11y ago
      Well, you ARE in the network right now. On HN :) networking doesn't have to be physical.
• lewisl9029 11y ago
  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?
  • 542458 11y ago
    If you search, there are lots of good plugins and bookmarklets to do the job. Yeah, it would be nice to have it built-in, but people have been asking for it for years - I don't think it's likely to happen soon. EDIT: Apparently posting really long strings without spaces breaks HN's layout now. Hunh. Here's my bookmarklet for that: javascript:(function()%7Bfunction%20getScript(url,success)%7Bvar%20script=document.createElement('script');script.src=url;var%20head=document.getElementsByTagName('head')%5B0%5D,done=false;script.onload=script.onreadystatechange=function()%7Bif(!done&&(!this.readyState%7C%7Cthis.readyState=='loaded'%7C%7Cthis.readyState=='complete'))%7Bdone=true;success();script.onload=script.onreadystatechange=null;head.removeChild(script)%7D%7D;head.appendChild(script)%7DgetScript('//ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js',function()%7Bif(typeof%20jQuery!=='undefined')%7Bif(!$('body').hasClass('collapsible-comments'))%7B$('body').addClass('collapsible-comments');var%20span_html='%3Cspan%20style=%5C'cursor:pointer;margin-right:10px;%5C'%20class=%5C'expand-handle%5C'%3E%5B-%5D%3C/span%3E';if(window.location.href.indexOf('item?id=')!=-1)%7B$('center%20%3E%20table%20%3E%20tbody%20%3E%20tr:eq(2)%20%3E%20td%20%3E%20table:eq(1)%20span.comhead').prepend(span_html)%7Delse%20if(window.location.href.indexOf('threads?id=')!=-1)%7B$('center%20%3E%20table%20%3E%20tbody%20%3E%20tr%20%3E%20td%20%3E%20table%20span.comhead').prepend(span_html)%7D$('.expand-handle').live('click',function()%7Bcurrent_level_width=parseInt($(this).closest('tr').find('td:eq(0)%20%3E%20img').attr('width'),10);$(this).closest('table').closest('tr').nextAll().each(function(index,el)%7Bvar%20elWidth=parseInt($('tbody%20%3E%20tr%20%3E%20td%20%3E%20img',this).attr('width'),10);if(elWidth%3Ecurrent_level_width)%7Bif(elWidth%3C=inner_level_width)%7Binner_level_width=1000;$(this).hide()%7Dif(inner_level_width==1000&&$('.comment',this).css('display')=='none')%7Binner_level_width=elWidth%7D%7Delse%7Breturn%20false%7D%7D);inner_level_width=1000;$(this).text('%5B+%5D').addClass('expand-handle-collapsed').removeClass('expand-handle');$(this).closest('div').nextAll().hide();$(this).closest('div').parent().prev().hide();$(this).closest('div').css(%7B'margin-left':'18px','margin-bottom':'5px'%7D)%7D);$('.expand-handle-collapsed').live('click',function()%7Bcurrent_level_width=parseInt($(this).closest('tr').find('td%20%3E%20img').attr('width'),10);$(this).closest('table').closest('tr').nextAll().each(function(index,el)%7Bvar%20elWidth=parseInt($('tbody%20%3E%20tr%20%3E%20td%20%3E%20img',this).attr('width'),10);if(elWidth%3Ecurrent_level_width)%7Bif(elWidth%3C=inner_level_width)%7Binner_level_width=1000;$(this).show()%7Dif(inner_level_width==1000&&$('.comment',this).css('display')=='none')%7Binner_level_width=elWidth%7D%7Delse%7Breturn%20false%7D%7D);inner_level_width=1000;$(this).text('%5B-%5D').addClass('expand-handle').removeClass('expand-handle-collapsed');$(this).closest('div').nextAll().show();$(this).closest('div').parent().prev().show();$(this).closest('div').css(%7B'margin-left':'0','margin-bottom':'-10px'%7D)%7D)%7D%7D%7D);var%20current_level_width=0;var%20inner_level_width=1000%7D)();
• DrNuke 11y ago
  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.
• iopq 11y ago
  > 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 11y ago
    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.
• a-dub 11y ago
  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 11y ago
    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 11y ago
      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.
• fredliu 11y ago
  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.
• staticautomatic 11y ago
  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 11y ago
    "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 11y ago
      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 11y ago
        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!
• abvdasker 11y ago
  > "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.
• bro-stick 11y ago
  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.
• joshavant 11y ago
  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.
• sytelus 11y ago
  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.
• gizi 11y ago
  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.
• dennisgorelik 11y ago
  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.
• abrbhat 11y ago
  I guess the reason that product programmers are most desirable is that most founders are product programmers themselves.
• datashovel 11y ago
  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.
• Joof 11y ago
  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.
• facepalm 11y ago
  "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?
• cageface 11y ago
  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.
• Animats 11y ago
  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.
• yks 11y ago
  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.
• jphelan 11y ago
  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.
• pron 11y ago
  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.
• bluecalm 11y ago
  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.
• dlwj 11y ago
  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.
• amydav 11y ago
  Do you need a legit hacker,to hack your WhatsApp,Facebook, bank account, Instagram,websites,or you wanna upgrade your score,change your university grade,fix your credit ,change your identity,erase your criminal record or learn how to hack etc, its no other genius than WALTSTEPH82@gmail.com or text +1 601 866 5203 ...
• amydav 11y ago
  Do you need a legit hacker,to hack your WhatsApp,Facebook, bank account, Instagram,websites,or you wanna upgrade your score,change your university grade,fix your credit ,change your identity,erase your criminal record or learn how to hack etc, its no other genius than WALTSTEPH82@gmail.com or text +1 601 866 5203 ...