Why are we so keen on redefining words? I'm genuinely curious about this. Is it political correctness? If not, what is it?
"Stupid" is pretty much defined as the opposite of "smart". You might be thinking of "unwise" or "ignorant" or "inexperienced". Or maybe you're thinking of "untalented" or "incompetent". None of those are "stupid" and their opposites aren't "smart".
For example, I'm good at programming, I have a good ear for music and I absolutely suck at drawing. None of that necessarily makes me smart or stupid. As a matter of fact, I'm pretty sure people wouldn't call me "stupid at drawing".
"Smart" and "stupid" are measures of a characteristic, just like "tall" and "short".
Colloquially that person would probably be called smart, but their (social) actions might be described as stupid. A smart person can be prone to doing stupid things.
Plenty of times. Heck, I used to be a lot closer to that end of the spectrum than I am now. That's how I know that there are plenty of words to describe that, because I've been called a number of them ;)
It's not political correctness. It's observing that often people who are smart and do smart things also do very stupid things. There is not one personality trait which means to do more smart things and fewer stupid things at the same time. That is the idea.
I think we do that because old words don't really fit in a new area, and there are always new areas. Look at the OED's historical definitions for any of the common verbs, IIRC "take" is a fine example.
Specifically: I'm smart but I do stupid things every day.
Fixing one's own stupid mistakes is half of what smart programmers do... perhaps "egoless" rather than "smart" is the proper opposite of "stupid" as far as programmers go.
It is also to some extent the product of the environment, not just an intrinsic property of the employee. I think in the long run, creating an environment that encourages dumb programmers to become smart programmers is as important as hiring the right people to begin with.
> Smart and stupid are not opposites. In fact, they happily co-exist in the same brain.
Definitely. I've worked with people I refer to as "blithering geniuses". Like the guy who could write memory managers for OSes and so forth, but who would not only miss his own exit on the freeway, but suggest that we do crazy shit like switch C++ compilers two weeks before shipping (there was some feature he wanted out of another vendor's toolchain . . . hoo boy).
It's worthwhile knowing what your blind spots are, and where you are stupid.
I don't know why you think missing exits is in any way indicative of someone's intelligence. I've missed plenty of exits, and let me inform you of something: it's not a big deal. Like, at all.
You know what stupid is? It's focusing on things that are not a big deal.
It's indicative of not paying attention to your surroundings, which, when you're piloting a 4000 lb hunk of metal, could be considered a stupid thing to do.
You're rationalizing. My wife misses exits constantly, but she does it safely--she's paying attention to the cars around her, but following a habitual route to some other place.
The coolest, most technically challenging code I ever worked on was sheer idiocy that added immense risk to the business. It was back in the dotcom days. If one of my own employees proposed the same kind of thing today, I'd threaten semi-seriously to fire them on the spot, and I'd flatly prohibit them from wasting man-months of effort on something we could buy off the shelf. Then again, management paying no attention to what the engineers were doing was pretty stupid, too.
Think about the thing you like most about someone. Think about the things you dislike the most about that same person. 9 out of 10 times, it's the same thing. Same goes for strengths and weaknesses.
Not necessarily the same thing, but often interdependent. Like "great sense of humor" and "unable to take anything seriously"... not really the same thing, but often interdependent.
Maybe your idea of "great sense of humour" is off, if you can't see how "great sense of humour" is connected to being able to take everything seriously.
Don't take it so literally. The point is that the personality traits that give us our strengths and good characteristics are very often the source of our weaknesses and bad characteristics. Take a look around at the people you know well - I bet it's almost always the case.
To further emphasize your point, there are skill lines. Someone could be smart at X but stupid at Y. So unless you're trying to hire someone that's A-level at everything...
Yeah, but there's also correlations. If someone is "stupid" in one area, they are much more likely to be "stupid" in another area as well. It's not a guarantee, but it's highly probable.
Success in one area typically correlates with success in many other areas as well. Otherwise we wouldn't have polymaths. There are people who are among the best in the world in fields that are completely independent.
This is not true in my experience. It's just as likely that someone's "intelligence" in one area gives them a false sense of their ability to understand other areas. They'll jump into some unrelated or semi-related area, learn a little, and quickly act as if they understand it as well as the understand their main area of expertise.
This is especially true if the new area is something they're peripherally familiar through everyday experience. I'm a teacher, so teaching comes to mind, here. Everyone has opinions about teaching and learning because everyone spent 15-20 years of their life doing it.
Intelligent people often act as if
Understanding of Area A + Familiarity with Area B = Understanding of Area B
But as Hegel said, "The familiar is not understood precisely because it's familiar."
See also: every thread ever on HN about law, politics, race, or gender.
In my experience, one's ability to develop expertise in many fields has much more to do with one's temperament. Most people I've met who who are able to do this live in a kind of visceral, mortal fear that they might believe something that isn't true. They're more likely to see certainty (in others as well as themselves) as a symptom of utter, hopeless confusion than as a symptom of understanding.
Success breeds success, yes. And some people are truly more talented than others, yes. But it still leaves tremendous gaps for the stupid to occur.
Consider the recent story about how Elon Musk (arguably the most brilliant polymath of our era) chewed out an employee for missing a work function attend the birth of his child. That's appallingly stupid. That's pure blindness to instinct, cultural values, and compassion. There you go. Elon Musk, fscking idiot.
More generally, a lot of people with brilliant technical skills have lousy social skills - social failings that can drag a team's effectiveness down as much as a technical idiot can.
And more than that, I'd say. People who are truly brilliant in one area can often get away with being absolutely, irredeemably stupid in another because nothing in their environment ever forces them to deal with their stupidity.
A brilliant engineer can have an amazing, world-changing technical career without ever realizing that he'd be 10x more effective with better social and leadership skills. Whether one sees that truth about themselves has much more to do with their personality and temperament than it does with their intelligence or expertise (IMO).
I'm not a Musk-apologist, but he already denied that vehemently on Twitter. And the "source" of that statement is anonymous with little credibility. Seems like an easy case of libel.
Polymaths exist, but are not the norm. I've more often run across the opposite, where people who are good in one area are not good at all in another. For example many people who are very good programmers are very poor salespeople, and vice-versa, which is one reason you don't have your sales team and your programming team be the same. Good programmers and good documentation writers are often not the same people either. At least among my colleagues, I definitely have a sense that I should ask A for some things, and B for others.
I think the problem with the concept of the 10x coder is that it assumes "10x" is an attribute of the person, rather than a complex interaction with the environment. It's sort of like when they say about an athlete "he just wins". Well it could he just wins on that team because that team is a really good match for his skills, and the coaches did a good job, etc. You could also say "he just wins" because he has a knack for finding situations he will excel in compared to ones he wouldn't.
That doesn't mean it doesn't take some special sauce to be a 10x developer, but my observation is most of the things that 10x developers do are teachable. For instance, they almost always are concerned with removing small inefficiencies from their work (learning keyboard shortcuts, using better tools, asking a lot of questions, etc.), and when they do find they're in a situation where the environment tends to pull people down to the mean, they usually move on quickly.
This is just my opinion, I'm not a manager, but if I were a manager I think I would be more concerned with how to "coach up" talent more than finding a unicorn.
For the last 2 years I was acting as the coach of a team in this way. I've now moved to a remote location and can't really coach effectively any more, so I'm mostly just lending horsepower to the cause at the moment. In case you are interested, I'll give a little bit of background: I've got 20-25 years as a developer (kind of lost count) and had spent 5 years teaching English immediately prior to doing this coaching role. I also have experience as an XP coach on several teams, but on those teams I had much more focus on process improvement, than on skills improvement.
When I started at this position, money was very, very tight. While we had managed to get and retain some good people due to a variety of factors including luck, there was no realistic way for us to be able to afford to go after and hire the top people in the industry. So our strategy was to train the people we had and help them develop whatever potential they had. I think it was quite a risk for the management team to hire me because they had to believe enough in the staff that the cost of my salary would be compensated by the improved performance of the team. Not many management teams trust their staff to this degree (it is one of the best things about working on this team).
There are a few observations which I will make. First, it's a really, really difficult job :-). Even though I have probably more relevant experience doing this kind of thing than most people in the industry, it stretched me pretty far. Had I not been very motivated from the start to do it, there are probably many times I would have just given up. I will speak of some of the difficulties a bit later on.
By and large, I would say that we were successful. One measurable result is that we had very little attrition during that period. I think the fear many companies have is that if you spend money training people that they will just leave for a better paying job. It is a reasonable fear and you do have to be careful to track the development of people and to try to offer salary improvements as their skills grow. I think it is fair to say that we were not always successful in this aspect (due to very real constraints on our budget at the time), but that people valued the personal growth aspect of the job enough to decide to stay anyway.
In many cases, I think as a coach your role is not so much to tell people how to do their job better, but simply show them where they are not performing well. The thing about programmers is that they are both intelligent and also problem solvers. Even if the person is not functioning at the top of their game, I think this generally holds true, at least compared to the general population. I found what worked best was to try to formulate the problem in terms that the person could understand and then encourage them to find their own solution. Of course you have to give tips and guidance from time to time, but most programmers can improve themselves quite a lot simply if you show them what is lacking.
Of course this is not always easy. I'm just going to have to be blunt. Not everybody wants to improve. It is a testament to the team that I barely ever had to deal with this, but I think it is a real possibility in general. What I did have to deal with is the problem that sometimes people don't want to improve right now. Sometimes their life is full and they just don't have the capacity. This is really, really difficult because you have to wait until they are ready, never really knowing if they will ever be ready. This is pretty stressful for the coach.
The other main problem that is difficult is when the person you are coaching simply doesn't believe that what they are currently doing is sub-optimal. In fact, they may think exactly the opposite -- that what they are doing is amazing and that everybody else is crap for not doing it. To some extent, this happens to everybody. The kicker is that it happens to me (the coach) too. So you often find yourself in some pretty intractable situations where you are pretty sure that you are right, but then so is the other person. You are paid to coach them, but if you get it wrong... you could potentially do a lot of damage.
So the main thing here is that you need to be pretty flexible in allowing people to examine their ideas. Even if you know you are right and the other person is wrong, once you have broached the subject you have to let them find their own way. It can be extremely painful as you watch the person make the same mistakes over and over again until -- finally they get it. At some point you have to trust that the person will get it, while doing your best to do damage control for the mistakes they make while they are learning.
If you have read this far, you may have noticed me use the word "trust" a lot. I think this is the most important part of doing a role like this. If you think the people on your team are crap and can't be trusted to improve, then I think the job will be impossible. If you can believe that no matter what situation you are in today, the person/team will blossom then the job is (barely) possible ;-)
How you get that belief in the first place and how you maintain the belief and trust over a long period of time will largely dictate the level to which you can succeed as a coach, I think. If you ever get a chance to do this role, I highly recommend it, but you need to be prepared to do a lot of sole searching.
The thing to really fear is the toxic hire, the /10 or /100 worker. He'll ruin your business while deflecting blame to others, driving away your best employees.
Don't fear the mediocre worker, fear the toxic worker.
And it's not either-or. You can be a 10x worker and be toxic. Sometimes those are the worst to have.
You think you need them because they do X, Y, and Z beautifully, but in reality they're destroying morale and tanking everybody else's ability to do A-W.
It's very, very easy in this situation to try to put a band-aid on things and hunker down, try to encourage the other folks to just give the toxic person a little more space. But it never works, and the longer you drag it out the more the A-team folks who aren't toxic will jump ship.
Yes, it's much better to hire a team of OK people who will work together as a team than it is to hire a team of superstars who's egos are too big to fit through the door.
I have been watching teams form and succeed -- or die -- for a long time.
I'm very close to believing that you'd be better off with hiring smart people right off the street who have never worked in IT -- but get along great and truly care and help each other out -- than you would trying to screen out folks who know algorithms and/or data structures and then filter a second time for not being a douchebag.
I have seen a lot of average ability teams who had social skills kick ass. I've never seen a team with tremendously smart people without them do so. In fact, I continue to be amazed at the brilliant people I meet sometime whom I wouldn't want bagging groceries for me, much less creating an web application.
ADD: If anybody's interested in running an experiment where we create teams basically out of thin air, hit me up. I've been kicking around some ideas in this space for a couple of years or so.
I have no personal desire to start or run a project services company, so it's not something I would fund. My interest is from the standpoint of understanding and accelerating how teams perform. (Or don't)
Also there's an interesting relationship between the people, the team, and the company. As it turns out, all are important equally, just in different ways. You really need a pre-existing company to do this.
Finally, I don't care what anybody tells you, work in this area is experimental. Everybody and their brother has a pet theory and most of it is based on limited/non-existent sample sizes or the conflating a plethora of data with an abundance of understanding. If people were robots, we'd just hire robots.
Apologies my HN response time drops when I go on holiday.
I was not meaning you should start a "normal" project services company - more that most such companies just grab semi-random contractors and throw them into the latest contract, meaning a company that made experimentation the basis of its allocation may have a both a commercial attraction and greater scale than ordinary lab-scale experiments.
Not that I know what you are planning so it's likely to be off target. (Well actually your second sentence suggests taking existing teams in existing company)
Yes. You can even have a team of 1/10 folks who, put together, work at 10x.
More counter-intuitively, you can take a 10x team full of folks everybody agrees are brilliant, stick them in other teams, and have the other teams tank and folks in the other teams think those folks are losers.
It's a humbling (and enlightening) thing to watch.
ADD: A lot of the myth of the 10 or 100x developer is just a really, really capable guy with a supporting team that is able to meet all of their needs and clear all of their obstacles. The team (including our star) is the cool and irreplaceable part, but the "genius" or "boy wonder" gets all the good press.
> ADD: A lot of the myth of the 10 or 100x developer is just a really, really capable guy with a supporting team that is able to meet all of their needs and clear all of their obstacles. The team (including our star) is the cool and irreplaceable part, but the "genius" or "boy wonder" gets all the good press.
I would argue this is almost always true especially in todays world of ever increasing software complexity. Building services, handling ops, fixing bugs, high level architecture, low level architecture, front end, back end, etc... are just impossible for a single person to ever be 10x at across the board. It takes a team to deliver software.
I look at it a lot like Michael Jordan and the Bulls in the 90s. MJ was the 10x player, but without the other hall of famers and all stars on the team they would not have won like they did. The same also goes for the rest of the team.
If you ask me, this phenomenon is the reason we see a lot of incredibly successful founders flail at a second startup -- and it's also the reason we see some folks continue to kick ass year after year. The first guys started believing their own press (One wag said that in SV, you either grow into the CEO role or you swell into it). They flipped, then started over -- leaving folks from the previous team spread here or there and not realizing they destroyed the magic. The second bunch just keeps honing a better and better team, moving the team into high positions of leadership. Each team member becomes a CEO, but the team survives (and continues to improve).
"You're looking for three things, generally, in a person," says Warren Buffett. "Intelligence, energy, and integrity. And if they don't have the last one, don't even bother with the first two."
It's a favourite quote of his, mentioned in this speech[1] as well, around the 1:55 mark.
I've seen several cases that looked like this superficially, but never a case where it turned out to be true when more closely investigated. Every single time, it has turned out that the "10x worker" who "writes all the important things and knows everything" has been doing essentially nothing for a very long time. Every single time, the primary features of these people have been:
* They have an opinion on every subject, and express one in every discussion ("leadership")
* For any proposed task, they can give a list of plausible-sounding reasons why it should not be done ("technical expertise")
* Nobody challenges them because doing anything that sounds even a little bit like a challenge results in you getting shouted at ("respected by their peers")
Words in parentheses are what management sees.
Every time I have seen a case where these people have persisted, it has been because a clique of them back each other up and the rest of the people in the company are essentially docile. Every competent engineer who finds themselves in this scenario then discovers that they are (a) outnumbered, and (b) able to find a better job somewhere else, so that's what happens.
I'm going to disagree here, based on personal experience.
I've not met a single individual whose contributions were so amazing to make up for their toxic personality. Most all of the toxic people I've worked with have had poor productivity, precisely as a function of their toxicity.
I mean, its totally fair that that's your experience. But I personally know at least three individuals who fit the archetype of the "10x(-ish) developer" and all of whom have toxic personalities I'd never work with. They may be able to code from scratch in a couple weeks what another team would take months to do, but in terms of the organization they are a loss, because no one can work with them.
Certainly, there are developers who fit the mold of what you're talking about. I'm not suggesting that all toxic developers are 10xers. But the ones to really fear hiring are the ones who produce lots of code while they corrode your organization.
If that's true, then they are not "10x developers". Being super-productive, but only by yourself in a vacuum, is next to useless to any company with more than 1 employee.
If you're a 5-10 person startup, don't you want to have the person who can write version 1.0 of your product by himself in a couple of weeks? Then, when you start having customers, have a bigger team and redo things cleanly.
There's another important fallacy.
From the viewpoint of a 10x worker, the /10 worker is toxic.
From the viewpoint of a /10 worker, the 10x worker is toxic.
Not if that person is toxic and awful to work with. I don't care if he's 10X, 20X or 100X (Not that I even believe in the myth of the "10X developer").
10x in this context usually refers strictly to their programming ability. I've certainly known people I'd consider 10x programmers, who I'd never hire without a specific difficult task that doesn't require collaboration.
I can relate to this. I once worked with two very smart people, extremely brilliant and could do amazing things. The only problem is they fought, were ill mannered and chased away every single person who every worked in the team. The manager was powerless because both of them had connections in the higher management and got anything they wanted.
The net result was there was never a stable team to get anything significant done. The project never did release anything. Needless to say they blamed everybody else apart from themselves. The last I heard, they did two more projects and met the same fate.
Perhaps it's also important to recognize that sometime someone who is the second best, or even just "good" at something, rather than "the best," might actually be a better person for your company. Having worked with people who are at the pinnacle of their field I have noticed 2 trends:
1. Such people tend to be very good at what they do, and largely bad at most other, even related, fields. This is not one of those tired stereotypes of a genius who is bad at social skills. There is a good explanation for this: someone who managed to become one of the best in their field, probably did so through concentration of their knowledge in that field, to the exclusion of others.
2. People who are the best of the best can sometimes overspecialize. You know the old saying, to a hammer, every problem is a nail.
In a small company with a few employees you can not afford to have such a person unless their field of expertise IS the domain within which lies the problem you are trying to solve, and even then, you should be careful. In a large company, you can have more specialists, but be careful as well.
It is also important to realize, as the author of the article pointed out, sometimes good enough will do. You do not need the best iOS dev or the best JS person if all they are doing is creating a front end for you new revolutionary AI engine. You probably want to go for the best AI person you can find, however.
My mother says a specialist is someone who knows more and more about less and less until they know absolutely everything about nothing. Likewise, a generalist knows less and less about more and more until they know absolutely nothing about everything.
This applies to looking for "top experts", and also to "full stack developers".
This is true in a useful sense. The more you know (about anything worth knowing) -- the more you realize you've yet to learn.
The more holes and short-cuts you're (painfully) aware of in tools and libraries everyone use every day, to get stuff done.
To be aware of how artefacts are made, is to be afraid. Be that artefact sausages or firewalls. The trick is to then learn enough to know which sausage to eat: or at least find a level of acceptance that lets you enjoy the stuff that tastes good, even when you know how it's made.
And after lunch, maybe you'll serve a json rest api with php.
I'm a generalist myself. I've become decent at a wide-ranging set of skills - cooking, feminist lit-crit, Arabic drumming, odd things like that. I've become a good but not awesome expert at a few things - configuration management, guitar, and others.
An important exception to this entertaining aphorism is observed in the Dreyfus Model of Skill Acquisition. Becoming an Expert (in the five level Dreyfus model) in something makes it much easier to become Competent or Proficient in other things. This has certainly been my experience, as things I learn in one area apply to learning others.
The result is that people who never commit to expertise in anything struggle to achieve proficiency, or even competence in anything. They're neither generalists nor specialists... they're just trapped.
Very true, like with most things in life, balance is key. Full stack developer who's emphases is X is a grate candidate, assuming X is what you are looking for. Full stack developer who is "great" at everything is probably not so much. My personal attitude in life is to know as much as I care about subjects which are my core competency and are most interesting to me, and know enough about other fields to be able to competently hire an expert in those fields, and be able to spot instances when that expert is bullshitting me.
I've seen brilliant people who can't deliver and mediocre players that get shit done day in and day out. Software is built upon hard work and compromise; it's more of a contact sport than it is a craft. Despite what people with little or no real world experience would have you believe.
There are people who would rather look good then play well, and then there are true ballers who never even thought about anything but winning the game by any means necessary.
This is related to the 10x debate, but kind of tangential to this post:
If you are actually 10x and super-duper smart, you're probably undervalued as an employee at any company. For example, companies have actively colluded to lower rates, so you are fighting to be on top of a sinking ship. Although salaries are probably still rising, you should really be a consultant if you actually want to get paid what you're worth. [0]
If your 10x comes from natural talent and work ethic, you should seriously consider moving to security (app, embedded, web, whatever) to help prevent governments from robbing the interwebs of privacy and security. [1] I'm blatantly arguing for 10x people to strive for a 'higher calling' and to get out of line-of-business software development if they are actually this person. In all likelihood, you will probably be better compensated as a consultant in this side of the software field anyway. I do realize there are other noble pursuits outside of security, so good on you if you're chasing that already.
The way most companies conduct interviews is one sure way to never hire the best talent anyway, even if they actually wanted it. So they end up with mediocre people, those who have memorized all the right answers to standard questions.
At the same time, these hiring practices push away the real talent who has better things to do with their time than to play the game. This talent is now sitting somewhere and building a startup of their own. Perhaps even a competitor of yours.
Oh no, I never got job for giving out memorized answers to standard questions. Those kind of interviews are not working for me, because I can give quick memorized answer when I am stressed. I was never angry on person asking in that way, only on myself that I fell easily into this trap. Worse part is that I know it and just after finishing phone call I realize fully that I was silly again.
It is easiest way to weed someone out, quickly ask couple canned questions and if you got standard reply then you got your "not hire" mark.
As someone that has been "actively seeking a new new role" in the last couple of months (not using the terms "job hunting" as not to confuse the recruiting police into thinking "easy 9 to 5 job"), i think i've covered quite a few of the recruiting methodologies around:
* Codility (online timed) test. I like Codility and their tests; worse case can always learn a new trick and believe my skills (not my recruiting standard answers) would improve if i spent more time solving their problems, so -1 kudos here for me. Never faired better than a 40/50% result and companies that use it don't follow up with applicants that score less than 60% or more.
* Hackerank (online timed) test. Not a good experience at all and separated this entry from the above, instead of just categorizing "online tests", just to express how crappy i felt it was. Weird and poorly described problems (written by the customer, unlike Codility, as far as i perceived, may be wrong). Small textbox in which to type the solution, without any kind of editor like feature (not even syntax highlighting) which you DO have to utilize all the time (no separate editor copy paste), since they do key logging on it, which they then allow the customer to view as video. Actually spent a large part of the minutes or so hacking that texbox (size) on Chrome Dev tools, which was actually the only interesting thing in the whole process :) Since the goal of a test is to demonstrate ones abilities and not have "fun" per se, -1 kudos for me here as well. Although, should also note that i was asked on a Friday (afternoon was it), to complete two of these assessments over the weekend, for a Monday noon interview, which ended up being cancelled 30m before since the company was not happy with the test results (nice one guys!). Sour butt and all, if a company feels entitled to "push around" an applicant like this, what should the applicant think about when it's on a payroll, to say the least.
* The surprise timed sample project test. This was actually the process that irked me. Was asked to set a day and time in which i'd have 2h availability, for implementing a surprise task i'd be sent over e-mail and which i'd have to reply 2h after receiving the task with the result, by providing a github/bitbucket/etc url. Ok. After some persistence, managed to squeeze information in that i would have to implement a web page as to "behave a certain way". The test ended up being about implementing a small django project in which you'd be able to enter an URL in a form, press submit and information about the URL would be displayed (page title, word count, meta tags and other stuff). In the e-mail that contained the task, and only then, was i informed that in the case i did not implement the full solution in the couple of hours, i would have to deliver the full solution at a later date. Not gonna -1 kudo myself on this one, that's for sure. Felt like i was doing free work for a client that either didn't knew what it wanted or did not wanted to tell me :) though i can go as far as understand why they were behaving this way.
* The sample project. Applied for a role in a company which the main language was new in my skillset (Ruby) and was tasked to do a small web app. They were aware of that. Bring it on, challenge accepted! Didn't implement all the features, but learned enough Ruby in one week to, in my opinion, demonstrate enough skills (as in "i know what i'm doing") on the frontend and backend (picked up some Sinatra, Sequel and took the opportunity to utilise Docker Composer in something useful). Ongoing recruitment process.
* The talks. Was invited to the offices for informal chats where i was asked about previous experiences, tech related and test questions. Was told directly what the company was about and had chance to ask what the company is expecting from the role and did my best to pass on my previous experiences (and passion about the tech areas that related to the role). Ongoing recruitment process.
All in all, even though i understand companies need to be able to, for example, put pressure on applicants so as to understand in a short period of time, how they would behave and perform and what their skillset is, i feel that there's some arrogance and irrealistic test methodologies around, but the truth is that if someone asked me the best way to asset a candidate, i wouldn't have an asnwer either. Personally, at the end of the day, i only want to improve my skills, solve real problems, get paid, not becoming better at interviewing.
edit: fixed some typos, added extra sour butt comment :)
C Players think that they are A Players and believe in only hiring A players. This has been my experience for the past 30+ years. I've worked with people much better than me and much worse than me, and hired many people for startups over that time.
It is a good idea that if you find someone who is smarter than you, then you probably should hire them.
But the whole "we're looking for A players only" crap is the mantra of mediocre companies and in my experience has resulted in really messed up hiring practices (Eg: Amazon passed on someone I know (because I worked with him) was smarter and better at programming than I am... while hiring me. Not that I'm bad.)
The basic root of the problem is, if you think you're an A player then you think you're at the top of the heap. This means you're not actually aware of people enough to know the people who are stronger than you... which means you can't hire people stronger than you.
Also, I've seen really good people be mismanaged to the point where they aren't really contributing what they should. The difference between an A player and a C player is sometimes really silly stuff- like not giving them an office or otherwise constantly interrupting them, or refusing to give them specs, etc.
This pursuit of the best of the best also sends you down rabbit holes of looking for college graduates (only) who come from ivy league schools. There are a lot of people coming out of the Stanford CS department, I believe, that I would not hire. (Can't say for sure, because I'm not in California) But the skills of producing great grades at Stanford are not the same skills that produce great software at a startup. Not that Stanford students are bad, bu that it's not really a metric for success.
However, the "over achiever" "type-A" "A player" types tend to think it is, the conflate conformance in the pursuit of success with quality, and that's not accurate.
Yes, you need hard work to graduate from stanford, that's true, and that's a key element. But you also need innovation and critical thinking, and unfortunately, colleges these days actually undermine that. Generally, anyway, I'm not saying all college graduates are mindless sheep. Just that people who are more independant thinkers are less likely to go to college. Or less likely to have gotten a CS degree. (I was studying physics for instance.)
Always love Zach's writing. Personally, with hiring and growing an engineering team I've found the key component is to just not hire anyone toxic. Beyond a certain size, teams have to have well-defined processes to function, and toxic people will rail against and subvert the process.
I was actually thinking a lot about this the other day, and it's one of the big differences between say a 5 person engineering org and a 20+ person engineering org. In a 5 person org it may be super valuable to have an independently minded superstar who avoids process but gets things shipped fast while a larger org will actually turn that person toxic by imposing too many restrictions and process on them for them to follow their normal patterns. This is why I think there are some folks that are really good that just jump around from one early stage startup to the next, so they can be mostly free from the bureaucratic politics of large organizations. I wanted to think with the right culture that bureaucracy and politics can be avoided, but my experience has been that eventually these things will shape how your org works, and like Zach says, that's not a bad thing if that org is filled with average people, as long as the process is designed to help those people do the best job they can at large team scale.
Just want to add that many like to ridicule bureaucratic politics of (large) organizations. But in a way, bureaucracy is needed when a organization gets bigger.
"Quality of individuals is only one part of what makes an organization great. Sports is rife with examples of the nimble, well-connected team triumphing over the team of individual superstars."
However the author doesn't really expand on this theme. How does a startup that's not obsessed with hiring "A-level rock stars" groom its people to mesh them into a great organization, a well-connected team? This is not elaborated.
The conclusion of the post is: "Sometimes people just want a greasy burger"... Which does not conjure up images of a team that is greater than the sum of its parts, unless McDonalds somehow qualifies :)
I agree with you but I think the point pretty much explains itself. Team play and willingness to produce the best your customer wants (and not the 3-star best) is exponentially efficient when you start to grow a team.
However I wouldn't say the same things when it comes to the first version of your core team. Every "10x" developer can work with 3 people but are they still "10x-effective" (do they even exist?...) when incorporated in an existing 5/6/7 people team? I don't believe so.
Our typical filter question is: "are you happy to use PHP, C++, Mongo, Java?"
Not that we have those in our stack yet, but it quickly weeds out those that sneer at any or all of that list. Let them destroy someone else's startup with their wanky tech attitude.
We are more interested in problem solvers.
The best answer we had was from employee # 2 - "if it gets shit done, and we ship, sure, why not?".
Why do they need to be 'happy' about it, though? I'd be willing to use any of those, but I wouldn't enjoy working with them as much as I would with others. Does that mean I have a "wanky" attitude and immediately disqualify me?
This one is good question. Why do all hiring people want you to be UBER happy to work for them and if you are not extremely aroused when you think about their company name they will not want to hire you.
I can be super happy to work for company after year or so when I get to know how it is to work there. Before that I can be interested or looking forward to get to know how it is working for them.
The real problem is that landlords, grocery stores and, in particular, pubs don't really understand when you tell them that the reason one can't pay that bill is because one hasn't yet came across a role in a super cool company, with wonderful customer experience around a product that one loved to the point of wanting to have sex with it, jazzy open space office and relaxed, integrating company culture, that scores 12 on the Joel Test!
Yes, some employees' obsession with people having to love their jobs is so weird. I can't imagine someone looking at a job description and exclaiming "wow, I love this!". Maybe after a year, though. When they actually know what they're supposed to do, and are invested in the work on some level.
Or preference <> condescension, if you swing that way.
I'm currently dayjobbing in a world of Java on Windows. It's kinda horrible, especially after recent experience with Ruby, Docker, and fully automated infrastructure. But there's more to the job than tool choices. Fifteen years of legacy code has its own interesting challenges to overcome, and the work environment is terrific in many other ways that I probably wouldn't get at a modern startup.
Well, my answer would be "Not particularly. In particular, PHP is a security nightmare; there are far better options than C++ nowadays; NoSQL stuff tends to be overhyped relative to real databases like PostgreSQL unless we have a zillion customers (and you don't or you would be giving talks at scalability conferences); and Clojure/Scala/whatever is probably better than straight Java although Java isn't actively bad. However, I'm also not going to rewrite a working stack if that's what you guys wrote it in. Revenue rules."
So, you wouldn't hire me, and that's probably a good thing.
You can get "shit done and ship" with practically any technology choice. Ironically, there's probably some other startup which has a similar question, but filters out everyone who is happy to use e.g. PHP.
Why would you not say "shit" during an interview? I wouldn't make it my every other word, but I find nothing wrong in talking to someone as I'd talk to them on a daily basis if I were hired.
I have no idea what the interviewer's attitude toward casual swearing is. Once I'm hired, I'll cuss like a sailor, cause by then it's really too late for them to do anything but ask me to keep the profanity down.
Because, and maybe I'm old-fashioned, I don't think it is the appropriate place for it. Besides, I try to find other ways to express myself. Swearing, to me, is lazy and I don't want that to be something someone remembers me by.
eh, i think the stigma associated with swearing has started to wane over the last decade or two. Admittedly if you swear every other word, you're not a very good communicator, but the occasional, impassioned (and well selected) swear word can be endearing, even in a professional environment.
Am I alone in thinking that the entire conversation around hiring A players is one big inside joke played on us programmers? What do we get out of dredging this particular argument up again and again and again? It's like vim vs emacs. Not only is arguing about it pointless, even if you were to come to a consensus about it, what would it matter?
I apologize if this seems overly negative, but it really does seem like programmers reach for any opportunity to be viciously divisive.
While a business may seek to hire a 99 percentile or even a 90 percentile, keeping them under your thumb and doing what you want, and keeping them on your side is a whole other kettle of fish.
90+ percentiles have a lot of opportunity and mobility. Why would they want to work on your VC funded cat comparison platform?
As an aside: Michelin Red guides are like Yelp, but Francophile-centric, uses dedicated reviewers instead of crowdsourcing and without the extortion. The issue with Michelin is that places outside France aren't rated very often (6 months to 2 years). And like a newspaper, the physical Red guides get outdated as soon as they're printed. Most people are better off with Yelp, especially if they can determine whether an establishment pays the Yelp "tax" or not. Speaking of which, a great personal project would be an invite-only, private Yelp scraper that doesn't play by the "tax" ranking rules (don't get busted by keeping it anonymous, obviously).
I doubt Zach himself agrees with his article's title.
Because the title isn't his point.
His point is, and I quote: "What I think is bad is that there’s so much pride and focus on The Best of the Best of the Best, With Honors."
Which doesn't conflict with 10x. If 95% of the world's best software is written by the top 5% of programmers, the programmer who isn't in the top 1% and barely made the cut at the top 5% is still exceptional.
It's true companies seek pain avoidance rather than pleasure seeking behavior. But pain avoidance also gets you Windows instead of Linux or Mac.
If the question Zach is asking is: "is there such a thing as a 10x engineer?" the answer is yes.
The story from philosophy class was educational though.
I understand your sentiment, the reason that this is such a stigma in the industry is because if you do have the ever-elusive, ever-exclusive, high performing team - a single person who doesn't fit in (not saying in what aspect, could be culture, skill, collaboration, communication, etc) will ruin the entire team and the team's momentum.
That definitely was a good thing. Sometimes, an obvious thing doesn't become obvious unless it is pointed out. Yup, it makes total sense. Every company claims to hire and be filled with rockstars. That's statistically impossible. I guess, 90% of the companies are stating what they wish for, but know that ain't true.
Once you have started a business, built a product, found a way to market to profitable customers and now need to hire an employee, I say 80% of the "I need 10x people" part is over.
Founding a company is hard - so hard I fucked it up. You need to be 10x. Then you can hire who you like.
The headline made me expect hexadecimal codes for classifying engineers. Read the article, disappointed.
0x48 0x65 0x6C 0x6C 0x6F 0x57 0x6F 0x72 0x6C 0x64.
One person may not, but a group certainly can. You might have several candidates, each of whom at least someone doesn't like, and end up choosing one that everyone can "settle on".
You could also be so desperate for growth that you hire someone with high hopes knowing full well it's a bigger risk that you'd want to take if you had more time to choose properly.
Why is this type of post upvoted to the front page on HN? I thought HN attracted folks sympathetic to the creation of startups.
>The hip thing nowadays is that your software company should hire only A-players instead of B- or C-players, or focus on engineers that are ten times better than anyone else. [...], but I think the sentiment itself is the wrong question to ask.
If people are starting companies, it's not the wrong question to ask. The first 5 programmers hired with fast dwindling startup funds all need to be ultra talented and smart. The competition will kill you with your staff of B & C programmers. When you get to the size of Microsoft with 128,000 employees, you can afford to have some deadwood C, D, F, and 0x employees wasting cubicle space. When you're a startup, you'll go bankrupt because the C players are floundering around not generating enough value in the product to help make the business succeed. It's not a matter of hip or not hip -- it's a matter of survival.
[...]the average company is pretty average. Not everybody can hire exclusively top-tier people. And you know what? That’s fine.
If the readership on HN is plugged into the startup scene, hiring mediocrity is not fine.
EDIT to reply to the replies:
Most of the replies think of "A players" as an absolute ranking on a world scale. Linux Torvalds, etc. That's not what I'm talking about.
Hiring employees or finding a marriage partner is hill-climbing algorithm.[1]
The startup would have some notion of an "A-player" suitable for the company's goals and business standing.
It does not mean you try to lure AI expert Peter Norving away from Google Inc to code a bash shell script because you insist on the "best of the best of the best."
Whatever pool of candidates your startup can realistically attract, over a constrained time frame, funded by a limited budget -- that's where you find your Local Optimum.
To you, you hopefully find your "A-player" although others may view that same candidate as B/C player compared to to someone like Linus Torvalds.
>, the reality was that most of the companies using our hiring software were most interested in finding people that don’t suck.
That's totally opposite from my observations.
Startups are most interested in finding great people.
They only "settle" for people that don't suck as a consequence of reality.
Their hill climbing didn't find their "awesome" programmer so they cross their fingers and hope it works out.
The blog post is saying most companies actually prioritize "don't suck hires" over "great hires".
The blog has it backwards and that is an outcome instead of the motivation.
As a meta comment, the advice from Warren Buffett, Steve Jobs, Bill Gates, Paul Graham, the YC Sam Altman startup school vids with the dozens of guest speakers (angel investors, VCs), etc all
stress the point of hiring the best people you can.
The only sources of advice for "just aim for hiring people that don't suck" are obscure writers of blogs.
Why is that? And why does that sentiment have to be delivered as explicit "advice"? Since you can't hire all A-players, you'll inevitably end up with mediocre employees that don't suck even when you don't pursue "don't suck" as a primary goal.
> If the readership on HN is plugged into the startup scene, hiring mediocrity is not fine.
i'm curious what this means exactly. having worked for startups in my area of things (graphics, games) i can say that 99% of the startups i see here only require mediocrity in my specialty area at best. most of them would do fine with a bunch of juniors and just one moderately experienced engineer to keep them focused.
solving a simple problem with a sledgehammer language on top of a tower of web stack is not the place you find the exceptional engineer, at least from my native code, down to the metal perspective, but its what most tech startups are about, and lots of them are doing very well with positively mediocre engineers.
i understand there is a different skill set involved in the really niche areas of pretty much anything... e.g. where you need to squeeze the most bandwidth efficiency out of some obscure type of database query by juggling SQL and PHP or .NET libraries or whatever... but that sort of 'excellence' is pretty mediocre from my perspective too.
its like mechanics who prefer working on the F1 car to the tractor. its not even specific to software. however the vast majority of mechanics will have to suck it up and do day-to-day work on pretty normal stuff, just like programmers at tech startups.
so from my perspective it seems like there is no choice but to hire mediocrity actually...
And I would go even farther and say that the article is even more applicable in the startup setting: you can get good work out of a decent engineer, but one actively bad hire can be very costly in very small company.
Most of my experience with startups, including my own, is that the technical team is usually built around 1-2 intelligent people (and I say intelligent, not geniuses), usually without a lot of experience and a lot of cheap labor (free interns from local universities, low-paid junior jobs..)
For most tasks that fall out the real core of the business, mediocre developers will do just fine.
> The first 5 programmers hired with fast dwindling startup funds all need to be ultra talented and smart. The competition will kill you with your staff of B & C programmers.
First, what is the evidence for this claim?
Second, what is the evidence that anyone's so-called A players are actually A players? The best people have better things to do than foof around with startups that may or may not work, like solid, well-paying senior jobs at established companies.
Yeah but most startups are not willing to pay the 10x salary for these 10x players. And they are often doing tasks that do not require 10x skill either. They usually don't start with such 10xer tools such as Haskell, Lisp or Erlang because hiring is 10x harder than blub. People have to be honest with themselves and realize that is totally ok. 10x people are doing HFT, working at places like Renaissance Technologies or working on hard tech projects such as the google self driving car.
For example airbnb, although very useful, does not require 10x engineering skill. It's a CRUD app, and there is nothing wrong with it.
If your business startup requires 10x skill, that is an existence risk. The only hard thing is scaling a large numbers, and that is a problem you can fix once your making it big, just like facebook.
Especially because "One of the most important things that made Microsoft successful was Bill Gates' devotion to hiring the best people. If you hire all A people, he said, they'll also hire A people. But if you hire B people, they'll hire the C people and then it's all over."
Microsoft also used stack ranking, one of the worst management practices from an employee perspective that I know about. It operates on the same principle: arbitrarily execute everyone at the bottom of the perceived bell curve.
That leads me to a translation of a quote by Stalin: "Those who cast the votes decide nothing; those who count the votes decide everything." The counting method has a greater effect upon the outcome than the actual votes.
How you measure the worth of someone may have little relation to the value they can actually provide. If you rank people by how quickly they can move 100m, and subsequently hire Carl Lewis and FloJo to manage Justin Gatlin, Tyson Gay, Mo Greene, Carmelita Jeter, and Tori Bowie, you're going to be disappointed when they try to do the same 5m 20 times, or 100m up a vertical rope, or 100m across the surface of a lake, or 100m while carrying a 50 kg backpack, or 100m across ice and snow, or 100m across a tightrope, or 100m on a flat, straight, level track, at local noon, in June, in the Sonora desert, with only 1 L of water.
So that Gates quote sounds to me a bit like begging the question, defining an "A person" as "someone Microsoft ranks well", a "B person" as "someone Microsoft ranks neutrally" and a "C person" as "someone Microsoft ranks poorly". Without establishing the ranking metrics, all he's really saying there is that Microsoft hires people with a good cultural fit for Microsoft.
That doesn't make them the best people. It makes them the best people by Microsoft's method of estimation.
There really are no 10x or 0.1x developers. The worth of the worker cannot be meaningfully separated from the conditions of the job. Someone who is 10x while working alone on his own side project may be 0.1x on a team using a management-mandated process. You can't really know ahead of time how well someone will do when thrown into your unique variety of bullshit. (And pretending that your company has no bullshit does not make it magically disappear.)
When you get done reading spolsky's defunct blog, try looking around and counting how many of the startups you're looking at are solving 10x problems.
Especially when your back is up against a wall and you've got little time and less money, its more important to have a squad of B players who all pull in the same direction at the same time than to have your 1 mythical 10xer playing hero.
Not sure if you meant founding or funding. I'm assuming funding.
I was one of the many that thought "meh, rsync" about dropbox. I still do. About the technology.
To be honest, I don't think I gave the business side much thought at the time (I hadn't given much thought to the idea of a sustainable business, other than "make more than you spend"). That said, I think it was obvious to me even before the success how this could be a product people would pay to use. It's crap (for my use cases) -- but it is useful.
Funding mediocrity isn't bad. Funding is about returns -- not beauty.
And talking about founding: I think founding mediocrity is genius. You just have to find un-serviced mediocrity. Like dropbox. Awful idea - but also great idea. Crappy tech (see: security holes).
But it works. People leverage dropbox to increase their productivity. That is great stuff. I'm not sure if it makes me a worse or better developer to think that I'm happy I didn't make dropbox. But I'm certain it makes me a worse business person. I'm fine with that -- but I can still recognize success in that arena.
Sorry, should've been more clear--I mean, there is a focus on having non-mediocre engineers and sales folks, but it doesn't seem like that same lack of charity extends to the cofounder clubhouse.
Zach works in the Bay and did a long stint at Github. "Average" in either of those contexts is severely graded on the curve. Average for a much larger company, or average in say.. the US, or San Diego... is saying a very different thing.
There's a huge gap between actually mediocre and say, @antirez. I only took the article as a suggestion that your expectations and ideas around who to hire be better tuned to your reality. There's an obvious dissonance between the number of companies saying they only hire the best, and the ceiling of available "bests".
When you get to the size of Microsoft with 128,000 employees, you can afford to have some deadwood C, D, F, and 0x employees wasting cubicle space.
IIRC, Amazon (and/or possibly Microsoft, someone can recall better details for me) has a policy of "don't hire the wrong person". They'd rather miss out on awesome than get stuck with sucks. And that's the point of the headline: don't worry so much about hiring 10x as making sure you don't hire 0x, startup or monopoly.
> The first 5 programmers hired with fast dwindling startup funds all need to be ultra talented and smart.
I'm not sure what to make of that. Maybe I'm suffering for impostor syndrome, but when people mention "A-players", I'm thinking people mean something like "top five percentile". Which, if I'm going to pull names out of a hat, means you have a short-list like:
Steve Wozniak
Bryan M. Cantrill
Slava Akhmechet
Colin Percival
Linus Torvalds
And you've maybe already ruled out the "B-team" (here comically chosen because of their lack of direct engineering visibility -- currently obvious commit sign-offs -- not because of any assumed "lack of ability to make the A-team"):
Alan Kay
Guido van Rossum
Larry Wall (I really have no idea, I don't use perl. I suppose writing perl as a reaction to posix-shell fatigue at NSA actually qualifies for the A-team... but I mean ... perl. B-team. ;-)
I've only met one of the persons on either list. And they are all, way above what I can assume is available for most start-ups. For one thing, even if they all were awful 10 years ago, they've had 10 (30) years to really, really improve.
Now, if you mean that people with some kind of coherent idea of coding, adaptability etc -- or want to "shop down" to something like: https://www.codeeval.com/profile/e12e/ (that's me) -- feel free to send me an email.
But impostor syndrome aside -- I'm not "A-level" in any sense that is meaningful.
That doesn't mean I haven't encountered my share of javascript jockey's or single-minded php masters that have both fewer skills (not so bad) an more of a constrained mind (much worse) than me. But please don't label me "B-level" and "can code a wet paper bag in CSS" "C-level".
There was a time when all I did was code wet paper bags in CSS. Of course, I did web standards before it before it was cool[1] (and I'd learned to spell check emails) -- but I'm not sure how you can tell talent from mediocrity+experience. If you do, you should probably run an HR-startup.
I'm hard pressed to pull the names of all top 5% programmers in the world out of a hat -- as an example. I was trying to illustrate how I might pick some candidates, and try to bucket some into "A-level".
The way I see it is a little different: Take how much value you add to the business and subtract your compensation. You're either above zero, around zero, or below zero. In other words, you're either adding lots of value, adding very little value, or subtracting value. All this hand-wringing about whether so-and-so is a 2X or 4X engineer is unnecessary--the vast, vast majority of people you'll work are not even above zero so it's kind of pointless. This has pretty much been true in most places I've worked.
You'll have a handful of people who are actively destroying value by just being there. These people will make your project later and buggier if you even give them commit access. They're the toxic personalities who, although nominally might be helping to improve whatever they're working on, are causing better people to leave or be less productive because of their personality or attitude. These people must go. I haven't worked with too many, but you can spot them pretty quickly, usually the first time they open their mouth.
Then, you'll have the folks who just clock in and do something every day, but they're not really adding or subtracting value--they may as well be furniture. This will be, by far, the vast majority of people you work with throughout your career. They're sorta competent, probably really nice people, but at the end of the day not exactly fueling the engine of whatever the company is trying to do. Depends on the company to a certain extent, but you'll generally see them everywhere. It's many of the people you currently work with. It might even be you, too. It's not really good or bad to have these folks around, they'll work on a project and you'll break even on it or maybe even meet some internal rate of return. There's really no reason to actively not look for this group.
Finally, there are the people who are net value-adds. Some people call them rockstars or unicorns or whatever. Whether they're 2X or 3X or 5X doesn't really matter--they're NX where "N" is a positive number, and that means they create more value than you pay them. When companies say they're looking for the top-5% or top-1% developer, they're really looking for anyone in this group (given the company's salary range), regardless of their particular "N" value. You'll encounter a number of these people in most companies. Some companies have more than others.
Someone can go from one group to the other either by getting better/worse at their jobs, getting a better or worse role fit, or taking less or more salary. Top talent at one company might be "furniture" at another one simply because they make more there--more than the value they can add.
The people you really want to actively avoid hiring are the net negatives.
The middle one is not adding "very little value". It's adding the amount of value that you are paid for. Likewise, the first one isn't adding "lots of value", but undervaluing the value that you bring, meaning you're not getting paid enough.
> It turns out, it’s much easier to focus on avoiding pain than it is to envision pleasure.
You just have a one-dimensional imagination. Don't want to shoot heroin up your veins forever, or have an infinite orgy? Just imagine playing paintball or walking on the beach, the cool sand running through your toes... or whatever. The mind is your oyster.
I'm sure if you were in Heaven, you wouldn't be worrying about making every moment the most exquisite you have ever experienced. It's not a competition; just chill out. You're in Heaven. Or day dreaming, same difference.
Thinking that you can avoid stupid people by only hiring smart people is naive, and misses this basic truth.