Hiring and the market for lemons (2016)

128 pointsby ff_about 7 years ago

20 comments

When the topic of "great" developers comes up, I always challenge anyone to define precisely, in quantifiable terms, what a "great developer" is exactly.How do you know someone is a "great developer" if you can't, in tangible terms, say exactly what a "great developer" is?This is even more of an issue when recruiting because recruiting is an assessment process to determine if someone meets some requirement. But just like software testing, if you can't quantify the requirement, then you can't quantify a test to determine if someone meets that requirement, and therefore the interview/assessment process is simply voodoo recruiting.Voodoo recruiting is when you have the appearance of scientific process in recruiting. - a process, - a set of questions that appear good, - a coding test that seems technical enough that it must be telling you something meaningful about the candidate, - the opinions of many people on the candidate. But in fact all of this is voodoo because you still can't directly define the requirement and thus you never known if you ever found what you are looking for, which is not actually known.The final decision in recruiting a "great developer", as always, comes down to some subjective opinion based on a range of criteria that can't be proven to have had any meaning in the first place.

评论 #16834127 未加载

评论 #16834253 未加载

评论 #16834175 未加载

评论 #16834154 未加载

评论 #16834212 未加载

评论 #16834444 未加载

评论 #16834075 未加载

评论 #16834066 未加载

评论 #16834114 未加载

seattle_springabout 7 years ago

Want to know a great strategy for hiring lemons? Ask only Leetcode-style questions. Don't ask anything relevant to the job. Don't ask about past experiences, architecture, tech-specific questions, or anything like that.Only. Ask. Leetcode. Questions. If it's not a stupid algorithm disguised as something cute like a dog jumping over a river, then don't ask it.You will be in the exact situation this article describes: Passing up on good engineers, and not being able to tell if the people you do hire can actually perform on the job.

dvtabout 7 years ago

I hold Joel Spolsky in very high regard, but I just think he's fundamentally wrong here. I've seen (first hand) many times when great developers stagnate at various companies and they leave. This can happen for a few reasons, but we're deluding ourselves if we think every single job is "solving the big one" -- no, sometimes we need people to write the plumbing, the boring stuff, the unit tests, and so on. Great developers, more often than not, get bored. If they have any sort of intellectual curiosity, they will leave. In most cases, corporate programming is just not very interesting. So first, we have the curious geniuses. I know many of these people that hop around from job to job and they say "meh Google sucked" or "Facebook was boring so I'm at this new startup now."Second, we have the people like me. I hope my hubris isn't showing, but I think I'm a pretty decent developer. I wrote a few books, had some contributions to a few big-boy OSS projects, am in the top 1.5% of Stack Overflow (even though I haven't really been contributing for like 4 years now), etc. I also built things -- many, many things -- some have a few hundred stars on Github, many have none. My goal in life is to "do my own thing" and, eventually, get that FU money. That is never going to happen working a regular 9-5 job and, in my early 30s now, I've completely accepted that. So I work for a few years (2-3) and then take a sabbatical where I dedicate my entire time on a project or two, trying to get it off the ground. When it inevitably fails, I go back to a "regular" job. The gap, contrary to popular belief, doesn't hurt you. When you explain and show what you built, people are more likely to be blown away rather than derisive.Finally, we have people like Max Howell who famously got rejected by Google even though literally everyone at Google uses his software. Max Howell is most definitely a great developer, and yet Google tripped all over their own corporate shoelaces. Let me put it this way: if I did a startup, I would 100% want Max Howell on my founding team. I mean just take a look at not only the code quality, but also how PRs/reviews are handled in homebrew.

评论 #16834439 未加载

评论 #16834424 未加载

deviationblueabout 7 years ago

Everyone wants a Ferrari, but most work is ordinary enough that all they really need is a Kia. It's very unlikely that you're the next Google etc., better to hire according to your needs and stature. Maybe you know what you're doing, and if you need a Ferrari to get it done, get a Ferrari.But let's be honest, most jobs out there are "sell this to people, faster". How much intellect are we supposed to spend on that? I digress. All you really need for that shit is a Kia.Also, it's really hard to hide both competence and incompetence. I wouldn't worry about passing resume screens or coding interviews if you can actually make something. If you have the skills to make things, you can even start your own business.Most people are average skilled, though. To be honest, that's all you really need. Let's not pretend otherwise.

评论 #16834386 未加载

评论 #16834234 未加载

mixmastamykabout 7 years ago

I do freelancing. Three times in the last few months I’ve had to sit in front of coderpad to attack a problem I’m not familiar with and come up with a solution—with one or two folks watching, the clock ticking, my family’s livelihood on the line, next to ~two hundred grand in a suitcase. I write well tested code every day but can’t perform under these conditions.It’s basically the scene from Swordfish, and just as ridiculous.Two of the three groups seemed to realize it’s a poor test, didn’t have high expectations but went through with it anyway. One seemed to think I was incompetent because I didn’t have his trick memorized about keyword args making closures possible in a loop in Python.I don’t write clever code on purpose, and certainly not enough to have it memorized to use under the gun.The 'shortage' is a myth and I blame time-wasting hiring practices such as these. Am thankful a smart guy like Luu is highlighting the bullshit.

Tehdasiabout 7 years ago

> needing a weird combination of skills, can be solved by hiring people with half or a third of the expertise you need and training people.I'll add that companies don't mention their internal tools/libraries/current code base (which is most likely of pretty crap quality and poorly documented) which is much more a hurdle than whatever language/toolset than they put in a job ad as required experience.

评论 #16834368 未加载

chrisbennetabout 7 years ago

"Joel's claim is basically that "great" developers won't have that many jobs compared to "bad" developers because companies will try to keep "great" developers. "This is a not what Joel said. Joel said that great developers are not on the market very often. They don't need to go on the open market to find their next job.

thoughtexprmntabout 7 years ago

Most teams should not waste their time searching for a “great” developer (whatever that is, exactly). Instead they would be better off just hiring the first candidate that comes along in whom they have reasonable level of confidence will soon be a productive contributor to the team's goals and makeup, and then move on with business. Everyone involved in the recruiting, screening, and interview process should not lose sight of this as the objective, and resist any temptation to get sidetracked by silliness like “pedigree” and “trendiness”.

hpcjoeabout 7 years ago

What I've tried to do over my career has been to hire people who showed ability to learn and grow, and then offer them the ability to step up to challenges. What I've gotten has been a rather bad mixture of incompetence, cluelessness, etc. They were eager to pass the interviews and get the job. They were not eager to do the work under the timelines we needed.This isn't just devs. This was sales, ops, and finance.I don't believe in any hard and fast rules about good vs non-good. I do believe that past performance is no indicator of future ability. That at least has been my experience.Even more relevant, pedigree is of no value in estimating potential success or failure of an employee at their mission. The best dev I'd ever worked with had a GED (high school equivalency diploma), and never went to college. The worst had a top-of-heap pedigree.Hiring is hard. You have to be an optimist. In the case of a small company, a bad hire can be a fatal mistake.

评论 #16835249 未加载

评论 #16835822 未加载

rdlecler1about 7 years ago

This is sort of like the venture capital market. Entrepreneurs will sort rank their investor list based on perceived value of that investor and will work their way down. Most VCs simply never see the great companies, which is why top firms consistently outperform while the overall asset class has fared poorly. In short, deal flow is everything.

taurathabout 7 years ago

I think there's a really key point with nontraditional developers. I'm also terrible at interviews because of both anxiety and lack of formal education (I can usually get optimal answers, but come across as "not confident" in them), but consistently get really high ratings and reviews from wherever I work.

tabethabout 7 years ago

I've been thinking about this for a while and have an interesting idea -- feedback welcome!Imagine a fully open company -- code, tools, library, marketing data, strategy, etc. Literally anything about the company you can think of is accessible on the open and ready to interact with, except for the underlying database data.Following along? Cool. Now, imagine all of this stuff being on some open repository (not necessarily Git, but for the sake of example let's suppose so). As employees create their backlog of items they add four properties:- A 1-100 score on how much difficulty they would have completing the item, 100 being extreme, 1 being none- A 1-100 score on how much difficulty they think an entry employee would have with the item. An entry employee would be defined clearly as the lowest level for their ladder, e.g. Software Developer I.- A time estimate on how much time they would have completing the item.- A time estimate they estimate on how long they think an entry level employee would have.So, knowing on this. Would the perfect hiring process simply not be taking the items, picking things that should take a reasonable amount of time (less than 8 hours) that are in the highest reported entry difficulty possible and then scaling that by the average self difficulty? With this system you could even anonymize the dummy interview pull requests and have employees rate the quality of it. Differences in quality and difficulty could be a positive signal (e.g. high quality for low difficulty item is good, obviously, but high quality for low difficulty item that was estimated to take less time than the average estimate, by employees, is even better).---So the purpose of this is less to identify who is objectively great, but rather to figure out how good the candidate is relative to people in your own organization. Personally I think finding an objective measure is an intractable problem.

评论 #16838829 未加载

rurabeabout 7 years ago

I think it's possible for both of these to be true if you back off of the extreme positions.1) Great developers are seldom looking for new jobs, but 2) There are a ton of inefficiencies in hiring that making finding great developers possible if you think outside the box.

mattsfreyabout 7 years ago

The problem with this is that so many companies (especially startups with young ceos) have _no idea_ how valuable an employee is. They negotiate hard and underpay often because that's just a general prescription in business. From my personal experience "great" developers change jobs all the time.

jamestimminsabout 7 years ago

Does anyone know what he's referring to when he talks about Matasano's unique hiring strategy?

评论 #16835648 未加载

评论 #16834345 未加载

nstjabout 7 years ago

The article paraphrases Spolsky incorrectly: great developers don’t look for jobs more than 4x in their career not because they stay in their jobs longer (ie: career length/4) but because they are headhunted for most of their jobs so don’t have to look themselves

PaulHouleabout 7 years ago

The "Bob" scenario happens all too often. Sometimes the "slow and sure" developer gets a lot of grief from pathological management that doesn't realize that developers who seem faster as short tasks might go in circles for years on bigger projects.

johngaltabout 7 years ago

Dead on.There is also an environmental component in play. You'll find a lot more noise in the hiring pool when the tech field is booming.

naveen99about 7 years ago

That’s why the best time to hire is out of grad school, college or high school.

itsdrewmillerabout 7 years ago

This is just not persuasive - here's a key point from it:"If we put aside Joel's argument and look at the job market, there's incomplete information, but both current and prospective employers have incomplete information, and whose information is better varies widely. It's actually quite common for prospective employers to have better information than current employers!"Ok, sure, maybe there are employers who don't know what they've got. But just based on the raw amount of information on either side, all else being equal current employers should have a much better idea of actual performance.