Who Y Combinator Companies Want - <AUTHOR> http://data.triplebyte.com/who-y-combinator-companies-want-c1880a08ac88 <comment><USER3> > "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.

<comment><USER4> >> have 10 days a year vacation (pretty standard)

Wait, what?

Is it really this bad in the States?

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

<comment><USER6> > 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/)

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

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

</comment></comment></comment></comment></comment></comment><comment><USER8> 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.

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

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

<comment><USER10> 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?

<comment><USER11> 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?

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

</comment></comment></comment></comment></comment></comment><comment><USER13> 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.

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

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

<comment><USER14> 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)

<comment><USER16> 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?

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

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

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

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

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

</comment></comment></comment></comment><comment><USER21> 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.

<comment><USER22> Very cool! Wish more companies approached it like this.

</comment></comment><comment><USER23> 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.

</comment><comment><USER24> "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)?

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

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

<comment><USER26> 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?

</comment></comment></comment></comment><comment><USER27> 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.

<comment><USER28> Maybe you only remember the super technical parts because the product-focused parts were effortless for you.

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

</comment></comment></comment><comment><USER30> 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.

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

<comment><USER32> Well, you ARE in the network right now. On HN :) networking doesn't have to be physical.

</comment></comment></comment><comment><USER33> 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.

<comment><USER14> Great advice! Mind if I add this to the blog post?

</comment></comment><comment><USER34> > "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.

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

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

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

</comment></comment></comment></comment><comment><USER36>
        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.

</comment><comment><USER37> 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)]

<comment><USER38> _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.

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

<comment><USER38> _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.

</comment></comment></comment></comment><comment><USER39> 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.

<comment><USER40> 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?

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

<comment><USER39> Spot on lackbeard ^^

</comment></comment></comment></comment><comment><USER26> 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.)

<comment><USER41> 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

<comment><USER42> > 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)

<comment><USER43> 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?

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

</comment></comment></comment></comment></comment><comment><USER44> 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.

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

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

</comment></comment></comment><comment><USER46> 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.

</comment><comment><USER47> > 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.

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

</comment></comment><comment><USER49> 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.

<comment><USER50> 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/)

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

</comment></comment></comment><comment><USER51> 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.

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

<comment><USER52> 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?

</comment></comment></comment><comment><USER53> 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.

<comment><USER14> We will be doing this analysis

</comment></comment><comment><USER54> 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.

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

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

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

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

</comment></comment></comment><comment><USER28> 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.

<comment><USER14> 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 firstname.lastname@example.com

<comment><USER56> Out of curiosity, on the taxonomy of programmers, is that supposed to be mostly exclusive, or can they overlap?

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

<comment><USER57> Bit of a nitpick, really, but you want a basis, not necessarily just a set of eigenvectors.

</comment></comment></comment></comment></comment><comment><USER27> 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?

<comment><USER58> 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

</comment></comment><comment><USER59> 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.

<comment><USER60> I found the detail level close to perfect. It explains a lot of my feelings towards the recruitment process.

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

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

</comment></comment></comment></comment><comment><USER61> >>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.

<comment><USER62> 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#.

</comment></comment><comment><USER63> 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.

</comment><comment><USER64> 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.

</comment><comment><USER65> 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.

</comment><comment><USER66> > 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?

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

</comment></comment><comment><USER67> 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.

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

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

</comment></comment></comment><comment><USER69> 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%.

</comment><comment><USER70> 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.

<comment><USER71> I totally agree with you. A good, recently published book, to read on this topic is 'Team Genius'.

</comment></comment><comment><USER72> _" 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)

</comment><comment><USER73> 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.

</comment><comment><USER74> So, random.

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

<comment><USER75> 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?

</comment></comment><comment><USER76> 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.

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

</comment></comment><comment><USER78> 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.

</comment><comment><USER79> 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?

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

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

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

</comment></comment></comment></comment><comment><USER81> "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."

<comment><USER82> This article might help explain that: [https://news.ycombinator.com/item?id=10659600](https://news.ycombinator.com/item?id=10659600)

</comment></comment><comment><USER83> 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.

</comment><comment><USER84> 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.

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

</comment><comment><USER85> 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.

</comment><comment> UK-AL Enterprise programmer bias? Could be higher salary expectations?

</comment><comment><USER86> 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.

</comment><comment><USER87> 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.

</comment><comment><USER88> Are you analyzing performance / satisfaction after getting hired? Would be interesting to see distribution across types.

</comment><comment><USER89> I guess the reason that product programmers are most desirable is that most founders are product programmers themselves.

</comment><comment><USER90> 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.

</comment><comment><USER91> "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?

</comment><comment><USER92> > "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.

</comment><comment><USER93> > 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?"

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

<comment><USER93> 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".)

</comment></comment></comment><comment><USER94> 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.

</comment><comment><USER95> 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?

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

</comment></comment><comment><USER96> 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.

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

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

<comment><USER97> 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 - <USER2> 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!

</comment></comment></comment></comment><comment><USER99> > "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?

</comment><comment><USER100> 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?

</comment><comment><USER101> 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.

</comment><comment><USER102> Why does this contradict the myth that silicon valley is ageist and only wants to hire fresh college grads?

</comment><comment><USER103> How does compensation play into these results? The 9 categories will have very different comp profiles

</comment><comment><USER104> 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.

</comment><comment><USER105> 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.</comment>


Members – For Managing Associations and Clubs - <AUTHOR> https://www.members.org.au <comment><USER2> The home page needs to improve the message. Don't talk about the what, talk about the why. When selling, you don't talk about pasta sauce and that it goes with pasta, you tell the consumer how the pasta sauce is going to liven the taste buds and give you the nutrients to make you feel healthy.

> mail and campaign marketing You may get this, most club owners might have an > idea but most aren't thinking about marketing, they are thinking about how > they can "reach people", "get announcements to members"

> social collaboration I have no idea what this means on a practical level, it > sounds like a corporate buzzword. Who would buy based on just those two > words.

> subscription collection (online payments) Oddly, this is great and then you > explain it further.

> training programs and eLearning What training? Training for the site, for > me, for members, do I have to fill in training material, do I charge members > for this, does it apply levels? Again, just buzzwords with no why.

> custom data What is custom data and why would I need that?

> completely extendable via API's Most people paying the bills will not know > what an API is, you are talking about sports clubs, social clubs, etc. These > people don't know or care about an API.

I know the retort might be that you click on the features page and find out more, but the average person probably won't make it that far or would have to enlist the services of a tech person to help explain.

Otherwise, good luck.

</comment><comment><USER3> AUD $220 (~USD $145) per month base price for 300 members heading up into the thousands?

That's $8.80 AUD per year per member, many such organisations have annual membership fees in the $5-$50 range in my experience which would put that at a pretty hefty price bracket. Even the next level up is $3.35/person/year.

While they do seem to have quite a feature list and I appreciate many services including bulk mailing can easily be say $50 per month on their own that cost doesn't scale with the member numbers in the same way theirs do.. So that seems a little crazy for the low end.. especially as something that seems to aim towards being for non-profits (having a .org.au and being for "Members").

Long time (also Australian!) actor in this space "TidyHQ" (formerly TidyClub) has pricing of $34-$83 USD (~AUD $52 - $127) per month. And a bunch of similar features and more that I don't see listed like keeping track of committee meetings and finances which in my experience are the more base line problems small non-profits have and the features I've most often used there.

The sales pitch and demos on their website are not really great outside of the feature list. So there's definitely some plusses over TidyHQ like a website and helpdesk but you can typically acquire SaaS services like that again for "10s of dollars per month" and at a price that doesn't scale with member numbers either.

Am I missing something? I guess if nothing else the site really needs a much better product walkthrough of what it handles outside of the basics on the Features page.

</comment><comment><USER4> So glad this made it to Hacker News! i started as a founder in 2019</comment>


The Swift Programming Language: A Swift Tour - <AUTHOR> https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/GuidedTour.html#//apple_ref/doc/uid/TP40014097-CH2-XID_1

<comment><USER2> Just what the world needs another proprietary language.</comment>


Property-Based Testing with PropEr, Erlang, and Elixir - <AUTHOR> https://ferd.ca/property-based-testing-with-proper-erlang-and-elixir.html <comment><USER2> This book is great! I was already familiar with the basics of property testing, but the book shows it can be used for way more than just the usual JSON parsing examples I had seen until now.

In particular I liked the idea of negative testing: making sure bad things _don 't_ happen, even if you generate data from a wider domain than what a function is meant to support.

The targeted property-based testing example is really impressive. The author tests a version of Quickcheck, and asks the framework to target a high runtime, putting an assertion in the test to make it fail if the runtime is very high. The framework then goes and generates an example of data causing O(n^2) behavior in quickcheck. Just beautiful.

I'm not done with the stateful testing part, but already I applied some of the stuff to a Python project (using Hypothesis) with good results. I hope I get to apply it to Elixir in the future.

<comment><USER3> What you got here is one thing that make test-case generation tools (quickcheck, fuzzing) still useful even if you've done a full functional (platinum-level) proof of your program. Functional proof, at least in Spark, doesn't give you hard guarantees about running time, stack or heap space. So even after you've proved the absence of runtime errors in your deserializer, you might still be able to generate a test-case that blows the allowed stack size, or the available heap.

Some tools are starting to emerge, like gnatstack for Ada & Spark that gives (or tries to give you) the maximum stack size, statically - a parallel step to compilation, like the Spark examiner and prover). It's very limited in my opinion (some dynamic-sized object returned on the stack are not handled yet, function pointers, I don't have the list handy but it was quite limited). You can get similar stuff (less integrated) with gcc options, IIRC.

There's also all the work on WCET that might get interesting but modern architectures are so complex and changing that I'm not sure we'll get near ubiquitous, user-friendly availability for those tools in the near future (next 10 years). For the time being it's mostly used in 'hard' safety-critical projects (avionics), especially since multicore, deeply pipelined architectures, with shared resources (memory, cache, buses) are getting used more and more and they're harder to predict than the previous architectures.

</comment></comment><comment><USER4> Elixir now has streamdata/exunitproperties which is designed to be integrated with the built in testing platform.

I've been using property testing to issue random workloads and test some of our work software, already it has found some bugs.

</comment><comment><USER5> I'm really interested in property-based testing but I haven't found any non- trivial examples out there. Anyone have any great repos or other resources they could point me to beside the author's work (which I plan on getting)?

<comment><USER6> I've been using my own property based testing framework [https://johtela.github.io/LinqCheck/](https://johtela.github.io/LinqCheck/) for .NET projects and jsverify ([https://github.com/jsverify/jsverify](https://github.com/jsverify/jsverify)) for Typescript projects. Below are some repos using those:

[https://github.com/johtela/Flop](https://github.com/johtela/Flop) [https://github.com/johtela/lamath](https://github.com/johtela/lamath)</comment></comment>


Jessica Alba startup The Honest Co. raises $70M - <AUTHOR> http://techcrunch.com/2014/08/27/honest-co-jessica-albas-e-commerce-startup-has-raised-a-70m-series-c/

<comment><USER2> This isn't related to this post in particular (congrats to the Honest Co. team), but I think HN would be a better place without constantly cross-posting funding announcements.

<comment><USER3> But where else would we post our thinly-veiled plugs as compliments?

"I've known Jessica since we bumped into each other in a co-working space five years ago. Literally haven't spoken since that day, but I always knew her and her team were destined for great things. So congratulations to an amazing team, I hope my startup ThingStuff (www.thingstuff.com) will be as successful as them!

P.S. Jessica if you are ever in the San Francisco area, we need to catch up!"

<comment><USER4> you should copyright that and start your own thinly-veiled-plugs-as- compliments startup template generator written in python|rails|scala|go|clojure. veild.us?

<comment><USER5> veiledthin.ly

<comment><USER4> thanks. i clearly need to brush up on my designer domain names.

</comment></comment></comment></comment></comment><comment><USER6> duh

[http://www.businessinsider.com/attractive-people-are-more- su...](http://www.businessinsider.com/attractive-people-are-more- successful-2012-9)</comment>


Cloud 9 IDE is Down - <AUTHOR> http://c9.io

<comment><USER2> ...and this is why I will never depend on such a service.

<comment><USER3> Well, that's ok, because we have a new local version, too. It'll sync your projects both ways.

</comment></comment><comment><AUTHOR> Note: The homepage is up, but the actual IDE is down.

I really like their platform and I invested in a premium account yesterday so I'm hoping that they pull through today's service outage successfully and remain viable going forward.

I do believe that cloud IDE's will all but replace locally installed ones over the next few years and C9 has a great head-start.</comment>


The DynamoDB Book: Data Modeling with NoSQL and DynamoDB - <AUTHOR> https://www.dynamodbbook.com/ <comment><USER2> I bought the book, I read the book, I've used DynamoDB for awhile. It didn't change my mind. DynamoDB makes tradeoffs in order to run at massive scale, but scale isn't a problem many people need solving when 2TB of RAM fits in a single box. Meanwhile I need to handle eventual consistency, an analytics pipeline, another database for fuzzy search, another geo lookup database, Lambda functions to do aggregations, and a pile of custom code. All while giving up tooling so readily available for the RDBMS world.

In a world where Opex is much higher than Capex DynamoDB might make sense, but for me server costs are 5% of dev costs. And even if it works from a cost perspective, how many AWS services have the console experience ruined by DynamoDB? The UI tricks you into thinking its a data table with sortable columns, but no! DynamoDB limitations strike again and you are off on a journey of endless paging. The cost savings come at the expense of the user.

DynamoDB also isn't fast. 20ms for a query isn't fast, 30ms for an insert isn't fast. Yes its amazingly consistent and faster than other systems holding 500TB, but that isn't a use case for many users.

<comment><USER3> If you treat DynamoDB as a DBMS, you're going to be disappointed (for the reasons you mention). But if you think of it as a highly-durable immediately- consistent btree in the cloud, it's amazing. DynamoDB is closer to Redis than MySQL. Amazon does it a disservice by putting it in the databases category.

<comment><USER4> DynamoDb is like redis without the fun data structures, the fantastic cli and discoverability, the usefull configurable tradeoff between fast and consistent, and really much-needed features s.a listing your keys.

<comment><USER5> So my quarantine project is building a Redis API on top of DynamoDB - [https://github.com/sudhirj/redimo.go](https://github.com/sudhirj/redimo.go)

</comment></comment></comment></comment><comment><AUTHOR> _Waves_ Author here. Happy to answer any questions folks have about the book, about DynamoDB, or about self-publishing.

NoSQL modeling is waaay different than relational modeling. I think a lot of NoSQL advice out there is pretty bad, which results in people dismissing the technology altogether. I've been working with DynamoDB for a few years now, and there's no way I'll go back.

The book has been available for about a month now, and I've been pretty happy with the reception. Strong support from Rick Houlihan (AWS DynamoDB wizard) and a lot of other folks at AWS.

You can get a free preview by signing up at the landing page. If you buy and don't like it, there's a full money-back guarantee with no questions asked. Also, if you're having income problems due to COVID, hit me up and we'll make something work :)

Anyhow, hit me up with questions!

EDIT: Added a coupon code for folks hearing about the book here. Use the code "HACKERNEWS" to save $20 on Basic, $30 on Plus, or $50 on Premium. :)

<comment><USER6> The biggest problem I'm aware of with DynamoDB is the hot key / partition issue[1]. Throughout is distributed evenly across nodes, you can't control how many nodes you have, so you always have a node that's hot either temporarily or permanently and so you end up having to over provision all your nodes to be able to handle that hot case, which ends up costing far more than alternatives. What's your take on this? This is the chief reason I avoid DynamoDB, which in theory would be a good fit for some of my problems.

[1] [https://syslog.ravelin.com/you-probably-shouldnt-use- dynamod...](https://syslog.ravelin.com/you-probably-shouldnt-use- dynamodb-89143c1287ca)

<comment><USER7> As of a couple years ago, DynamoDB will redistribute throughput between shards based on usage [1], so in theory this should eliminate the hot shard problem. I haven't had a chance to test this in practice, if anybody has hands-on experience I'd love to hear it.

You also finally have a way of identifying hot keys with the terribly named CloudWatch Contributor Insights for DynamoDB. [2]

For exceptional use cases, you also have the option of On-Demand Capacity to pay for what you use and not worry about capacity at all. [3]

[1] [https://docs.aws.amazon.com/amazondynamodb/latest/developerg...](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp- partition-key-design.html#bp-partition-key-partitions-adaptive)

[2] [https://docs.aws.amazon.com/amazondynamodb/latest/developerg...](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/contributorinsights.html)

[3] [https://docs.aws.amazon.com/amazondynamodb/latest/developerg...](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/HowItWorks.ReadWriteCapacityMode.html#HowItWorks.OnDemand)

<comment><USER6> That sounds like the problem had been solved and my information is just out of date now. Maybe I should give DynamoDB another look now.

</comment></comment></comment></comment><comment><USER8> After using Dynamo for 2 years now the biggest problem I've seen thus far is the pretty extreme expectations it puts on your application code to manage things that have traditionally been considered the responsibility of the data store. We found it was a bit onerous to ensure all facets of modeling/validation/indexing were into consideration when writing that layer of the application. To address the constant bootstrapping you either end up with a crap ton of utilities that form indexes or create updateExpression strings, etc, or you end up constantly reinventing the wheel.

The JS landscape for Dynamo is a bit bare, notable options all largely ignore the indexing principles that are the real draw of Dynamo. This heartburn caused me to sit down and write a library myself ([https://github.com/tywalch/electrodb](https://github.com/tywalch/electrodb)) that allows you focus on the models and relationships while taking care of all the little pitfalls and "hacky" tricks inherent in single table design.

Alex's book covers all these things and I honestly wish I had had it sooner before having to learn via foot shooting. It's pricey but if you have a need for Dynamo on your project it really pays off knowing you're swimming with the current, and Alex definitely gets you there.

</comment><comment><USER9> I bought this a few weeks ago and am about 130 pages in.

It is just stunning how much better it is learning Dynamo/NoSQL in general from this than effectively any other source. Anyone who's had to rely on AWS docs knows how face-meltingly dense they can be.

I went back and refactored all my previous Dynamo work last night, and the difference was night and day. I'm planning to migrate some relational structures later this week, as well.

Is good book.

<comment><USER10> What has this book taught you that could be applied outside DynamoDB? I'm close to buying but the price is kinda steep... if however I can take away some general NoSQL insight then I'm sold.

Edit: nevermind, I see another review elsewhere and the author replying. Though, your opinion would still be appreciated! :)

</comment></comment><comment><USER11> DynamoDB is very compelling for performance, scalability, and low ops overhead, but I recommend thinking _very_ carefully about the limited transaction support before going with it, as it's likely to be a dealbreaker for many use cases, whether or not you realize that up front. I think most apps will need a transaction involving more than 25 rows at some point, and with dynamo your only option is to fire them off in groups of 25 and hope none fail (plenty will at scale).

You can get many of the benefits of dynamo (sans auto-sharding), by applying its elegant indexing strategy to an sql database. It will be as fast or faster, your transactions can be as big as you need them to be, and you retain the ability to occasionally fire off un-indexed ad hoc queries for development or convenience. Running and scaling an sql db is also fairly painless these days with options like aurora.

<comment><USER12> > I think most apps will need a transaction involving more than 25 rows at > some point

I ... can't think of a single time I've ever needed this.

<comment><USER11> A common one is cascading deletes when you delete a user or a 'project' or something else that has a lot of stuff associated with it. Those will exceed 25 rows very quickly. Also any kind of bulk update or data import... hell even just initializing a new account can easily require writing more than 25 rows in a moderately complex app.

<comment><USER13> Still, why the need to be transactional? An eventually consistent delete seems fine here.

<comment><USER11> Maybe it is, or maybe some of the rows are involved in a security check. Or could cause race conditions if out of sync. Or otherwise need immediate read- after-write consistency.

And eventually consistent isn't the worst case scenario. Being unable to rollback correctly from an error could mean you'll _never_ end up in a consistent state... that's a lot worse than "eventually".

</comment></comment></comment></comment></comment><comment><USER14> For my current serverless project I'm using Fauna which I think is a better option than Dynamo. You get relations, complex queries, etc. You also get authentication and authorization baked-in.

I haven't done any serious tests but I'd say on average my reads to Fauna from Cloudflare workers are 30ms. Seems a lot compared to querying a local instance of Postgres but since Fauna is distributed you end up getting much better latency on average for your worldwide users compared to a single DB in us- east-1.

Writes take longer (probably around 200-300ms on average) but considering these are replicated to all Fauna servers with ACID I'm ok with that.

I wrote a little intro to Fauna's query language which is very powerful if anyone is interested:

[https://github.com/PierBover/getting-started-fauna-db- fql](https://github.com/PierBover/getting-started-fauna-db-fql)

</comment><comment><USER15> DynamoDB is monster scale but... tricky to use and difficult pricing model. The paying for writers / readers thing is strange to me and makes it difficult to scale up for bursts. I recommend not using this tech for most things. You need to know exactly why you want to use it and have a good reason.

<comment><USER16> > makes it difficult to scale up for bursts

Can you tell me why the On Demand mode doesnt work for you?

<comment><USER2> 7x the cost. I find it interesting that the DynamoDB cheer squad points out most databases only run at 10-15% utilisation and are burning money every hour. In the next breath they suggest running on demand "till it hurts" and paying AWS as if they were running at 15% utilisation.

<comment><AUTHOR> I recommend On-Demand pricing 'until it hurts'[0], but that's because a ton of people I talk to are spending <$50/month on DynamoDB. At that point, it really doesn't make sense to spend hours of time optimizing your DynamoDB bill.

If you are at the point where you are spending over thousands of dollars a month on DynamoDB, then it does make sense to review your usage, fine-tune your capacity, set up auto-scaling, buy reserved capacity, etc. But don't waste your time doing that to save $14 a month. There are better things to do.

But it's really nice to have a database where you can set up pay-per-use, don't have to think about exhausting your resources, _and_ have an option to back out into a cheaper billing mode if it does get expensive.

[0] - Hat tip to Jared Short for this advice & phrase

</comment></comment></comment></comment><comment><USER17> > While your relational database queries slow down as your data grows, > DynamoDB keeps on going. It is designed to handle large, complex workloads > without melting down.

I mean- hand a person a gun, and they might shoot themselves in the foot. While you can make bad queries/workloads for a relational database, you can just as easily make bad workloads for DynamoDB.

<comment><AUTHOR> My contention is that it's _much_ easier to have an access pattern that won't scale in a relational database than in DynamoDB. DynamoDB basically removes all the things that can prevent you from scaling (JOINs, large aggregations, unbounded queries, fuzzy-search).

This is underrated, but it's really helpful. So many times w/ a relational database, I've had to tweak queries or access patterns over time as response times degrade. DynamoDB basically doesn't have that unless you really screw something up.

<comment><USER18> So what is the cost of doing a bit of query tuning and de-norming every now and then compared to the development costs imposed by DynamoDB?

<comment><AUTHOR> It depends!

For me, I like that 98% of DynamoDB work is frontloaded. I spend the time building the model but once it's done -- set it and forget it.

With RDBMS, it's like there's a hidden 5% tax that's lurking at all times. You have to spend time tuning querying, reshaping data, changing patterns, etc. It can add up to significant drag over time.

Different teams might think the costs are different for their application, or they may be fine with one pattern over the other. Fine with me! I just know which one I choose now :)

</comment></comment></comment></comment><comment><USER19> What I like in DDB is TTL. It is a fantastic feature. I read someone comparing it with Redis. Redis is faster because of TCP connectivity, whereas DDB is over HTTP.

</comment><comment><USER20> I work a little outside the standard startup hyper-scale, fast growing business, so forgive my question.

But how widely used is DynamoDB? And for what use cases?

And what are the problems with it?

<comment><AUTHOR> In a nutshell:

\- It was designed for super high scale use cases (think Amazon.com retail on Cyber Monday). It has decent adoption there. Competes mostly with Cassandra or other similar tools.

\- With the introduction of AWS Lambda, it got more adoption in the 'serverless' ecosystem because of how well its connection model, provisioning model, and billing model works with Lambda. RDBMS doesn't work as well here.

A lot of people find 'problems' with it because they try to use it like a relational database, which it most certainly isn't. You have to model differently and think about it differently. The book helps here :).

</comment></comment><comment><USER21> This looks like a great resource. One thing I'm struggling with is the ability to sort and filter and was wondering if the book goes into detail about this topic.

If I have a person entity and its attributes listed out in a table. How would you go about sorting by first name, last name, created at, etc... I was thinking of streaming everything over to elastic search, but that would add extra complexity to maintain.

<comment><AUTHOR> Yep! There are entire chapters on sorting & filtering. Note: it's different than in a relational database, but it's doable :)

<comment><USER21> Awesome! Glad to hear that there's a section on that. Quick question. I'm thinking of leveraging elasticsearch for the fulltext search capabilities. Is the work to get sorting on various different attributes heavy from a dev perspective and is there any advantages of doing it through dynamo rather than querying with elasticsearch?

</comment></comment></comment><comment><USER22> Well I'm a sucker for this kind of stuff- how do the videos work in the premium package? Do I get to download them for offline viewing?

</comment><comment><USER23> Can some knowledge be transferred to other NoSQL flavours like mongo or is the book heavily specific about DynamoDB?

<comment><AUTHOR> All the examples are specific to DynamoDB and use DynamoDB features.

That said, the principles apply pretty well to other popular NoSQL databases, especially MongoDB and Cassandra. There will be some slight differences -- MongoDB allows better nesting and querying on nested objects -- but it's broadly the same. If you want to model NoSQL for scale, you need to use these general patterns.

If you want to check it out but find out it doesn't work for you, just let me know. I've got a 100% money-back guarantee with no questions asked if you don't like it.

</comment></comment><comment><USER24> Wonder if anyone agrees that Uber's order processing can be handled by DynamoDB very well.

</comment><comment><USER25> The book looks great, but being a startup, the price is hard to swallow for 20+ engineers.

<comment><AUTHOR> Email me, and I'm happy to discuss :). email@example.com

</comment></comment><comment><USER26> Does anyone have book recommendations on NoSQL modeling in general?

<comment><USER27> Tbh I don't think that makes sense since it depends on what your definition of NoSQL is. Some people say 'no relations' others say 'no sql' others say 'eventual consistency'. Some people call FaunaDB NoSQL because it's distributed and scales yet it offers strong consistency and relations and hence normalized data and joins is an option.

In others, you might have relations but lose consistency, in others you might have relations but only keep consistency under specific conditions (sharding keys etc)

NoSQL modeling typically depends on the specific characteristics of the database. Essentially it's about looking at these, see what it doesn't offer, compare that with what you need, and find workarounds.

</comment></comment><comment><USER28> $79 for the basic package? A bit pricey if you ask me.

<comment><USER29> If your rate is low enough that you can learn everything that is in this book for $80 worth of your time, then sure. Price is relative, it's not like he's selling prescription drugs for $1000 per pill.

I bought it and have found it to be completely worth the money. I don't look at prices for these things in relation to how much other books cost but how much time it will save me.

<comment><USER30> Yeah I think that the medical comparison is a good idea.

We tend to criticize people for asking decent amount of money in our industry whereas people on others industries shamelessly ask for ludicrous amount of money even for pretty much anything (think medical or legal)

</comment></comment></comment><comment><USER31> thanks for this. I just started creating my first DynamoDB database yesterday

<comment><AUTHOR> Awesome! Hit me up if you have any questions :)</comment></comment>