It seems that "great" developer is somewhat a synonym for "public" developer. I'm not sure how companies would just "know" someone is "great" otherwise. And yes, not all publicly known developers are necessarily great (or even good), but I'm not sure how one would recognize a 'great' developer without that person also having some degree of publicness to them.
And yet, I've known more than a handful of developers who are really solid, great people to work with, and I'd like to work with again. None of them have ever blogged, podcasting, presented at conferences nor run a public repository on github. Yet by many definitions of 'great', they fit the bill, but not the sort of 'great' that would mean companies would just 'know' of their greatness, and go out of their way to hire/recruit them.
> It seems that "great" developer is somewhat a synonym for "public" developer.
Not really.
What Joel and Dan are both talking about is that great developers tend to have coworkers who know they're great and will happily hire them at other companies.
I'm certainly not a "public" developer. My most popular repo on GitHub has maybe 10 stars. But I do have a handful of people who I've worked with in the past who will readily hire me at their new companies.
Referrals are how most hiring works, and it's the predominant way that companies recognize "great" developers even though said developers are not public.
I have been in this industry for 14 years. I know three developers I have worked with who are both still working and not still at the companies where I worked with them. It's kinda hard for me to take advantage of that. This kinda ties in to the point tptacek made elsewhere about the problems of relying on this kind of recruiting.
> It's kinda hard for me to take advantage of that.
Why? That's 3 companies where someone should be willing to give you a strong referral, not to mention that really your network should include second-degree referrals as well.
Offtopic but there was another post here recommending that people do just that, be very visible and public so when the layoffs happen you aren't the person laid off even if you're just doing the same work as everybody else you appear to be indispensible. Recruiting works the same I guess.
I understood that notion to mean the companies would recognize a "great" developer when they were presented with one, either during the interview or even when said developer was working with them.
there were refs to companies "knowing" people and sending them offers as soon as they heard of a layoff, for example (either somewhere in the piece or in the comments here).
That assumes those people keep an active network. While I - a freelancer - am still connected with former colleagues through LinkedIn I don't expect to ever get a job through any of them, and vice versa, despite having much enjoyed working with them and received offers to do a project together while we were together at a particular job. It's just that we have had zero contact apart from the time we were on the project together. It would feel extremely awkward to now, years later, send them an email "would you know a job for me", no matter how well we worked together. You just don't do that, at least I wouldn't. If I was asked by someone by someone I once knew I would immediately feel like an unwritten and unspoken social contract was broken. It just doesn't feel right to me. After a few years it's just too much time that has passed. It feels like putting social pressure on them, similar to those "endorsements" on LinkedIn.
> It would feel extremely awkward to now, years later, send them an email
If you ever have a reason to send that email I hope you do. Most people enjoy a chance to help someone out and they'll often get a bonus for it. I've gotten emails from people I didn't actually know and just sent them on to the recruiting team. For people I did know or had a trusted recommendation for I'd follow up with the hiring manager directly.
> It would feel extremely awkward to now, years later, send them an email "would you know a job for me", no matter how well we worked together. You just don't do that, at least I wouldn't. If I was asked by someone by someone I once knew I would immediately feel like an unwritten and unspoken social contract was broken. It just doesn't feel right to me.
Anyone that I worked with (even 20 years ago) and who was a good colleague then would be more than welcome to ask me for help in a job search. I'd think of it as totally normal and something that I'm happy to do.
By far the most common way to hire people is through referrals.
Whenever I am looking for a new job, I send out emails to my network saying I'm looking for a new opportunity and to let me know if they know anything interesting. It's a win-win for everyone.
Even in this thread you can find many people besides myself attesting to the consistent power of referrals in most hiring. In fact, that's even one of the central
I am, frankly, amazed that you have never had a former colleague approach you about a job opening they had or express that they're looking for a new job. That's literally one of the most basic uses of networking out there, not to mention that many companies have explicit cash bonuses for referring new hires.
Most companies give cash bonuses to current employees if they successfully refer someone. I'm sure they'd be happy to have a shot at that money if nothing else.
Maybe you don't but a great many people do, myself included. If you did a great job, people remember that. Of the colleagues I've worked with in the past that I respected, I would have no hesitation in passing on leads to them or referring them to my current employer.
I think the author is talking past Joel to some extent. Joel's emphasis is not on good developers not changing jobs, but more about the fact that they very seldom go through a traditional application process of sending in a cv to a hiring manager. Instead, these people "travel as fast as beer" when they're looking for a new position - they mention it to a friend or colleague who has a beer with someone else who sends over a job offer.
It can seem paradoxical that companies are saying that they can't find people to hire, and even with the tech boom there are developers who can't find jobs (at least ones that they are completely happy with), but this is because a huge percentage of CVs on desks are from people who have needed to take the time to send off job applications, and are often therefore representative of the not "great" developers.
Spolsky is wrong. I think we all have a clearer view of that now than we did in the '90s, which is the era of software development he's writing about. I'd be surprised to hear that Spolsky himself still believes everything in the Guerrilla Guide to Interviewing.
But the notion that the best developers rarely go through the normal interview process is itself problematic and worth picking apart.
It's true: the developers with the best reputations don't get interviewed. They can get their pick of jobs just by networking.
But that's bad.
It's bad for multiple reasons:
* It creates an informal guild of developers --- not all of whom are actually good --- who can bank on career mobility regardless of performance. Those developers are often hard to motivate and always hard to retain. Some of them are toxic, but because it takes 1+ years for most companies to cough up a bad developer, they end up with resumes that are indistinguishable from the rest of the cool kids, so they get to "fail up".
* It means some of the best developers are never informing the hiring processes of companies, because they get to skip unreasonable candidate screens. This means the screens never get any better. If you're serious about screening candidates, you standardize your process and you have an ironclad nobody skips the process rule. But almost nobody has these rules, because they feel like they can't and retain access to the cool kids guild.
* It reinforces and amplifies stereotypes and privileges. It means it's super easy to get a job if you know the right people and look like Zuckerberg. It's part of the reason the demographics of our industry look this way.
So, apropos little else of this thread:
Don't let elite candidates skip your process. Standardize your process. If an elite candidate balks, then you've learned something about them: they'd rather your process suck and keep sucking than take any time to help fix it. That sounds to me like someone who isn't prepared to invest their time and energy in your team.
> That sounds to me like someone who isn't prepared to invest their time and energy in your team.
And why should they? If you are running them through some elaborate hazing ritual before they are a member of the team. If at any point during the hazing ritual, any unknown person can black-ball them, in what way do they owe you the courtesy of helping you improve your team?
The contract in this instance is not "I will help you out of the goodness of my heart" the contract is "I will help you for x hours a day in return for a wage of y"
Anyways, I appreciate where you're coming from, and agree that you want to work with "generally agreeable" people, and should hire the same.
In my opinion, it does not necessarily logically follow, that someone who is unwilling to prostrate themselves before a noxious process is not willing to invest in the team they join.
It is incumbent upon the hirer to respect the applicant as well as the inverse.
At least at Google I don't believe it's the case that "any unknown person can black-ball them". There are hiring committees and they can ignore a bad interview if they have other evidence that the candidate is solid.
Now, if there are two different people who rank a candidate badly, or the other interviewers are meh, that might be taken more seriously.
I agree about the hazing ritual aspect of it though. I think it comes from engineers doing interviews who are just going through the motions without taking it seriously or trying to improve, which is what you get if everyone is supposed to do interviews.
in Gayle Laackman's "Cracking the coding interview":
> Amazon’s “bar raiser” interviewer is charged with keeping the interview bar high. They at-
tend special training and will interview candidates outside their group in order to balance
out the group itself. If one interview seems significantly harder and different, that’s most like-
ly the bar raiser. This person has both
significant experience with interviews
and veto power in the hiring decision.
You will meet with your recruiter at the
end of the day.
I can confirm that for me, the interview was 4*45 minute whiteboard coding sessions. In two of the interviews it was 2-on-one.
Unlike Gayle's description however, I received no debrief or description of what aspect of the 4+ hour ordeal I was rejected on. (Not to mention the night before where there was a 5 hour social/mixer).
It seems that since her writing, they've adopted a no-feedback policy.
So all in, I spent a day "investing the effort in their team's interviewing techniques" but got nothing but a black hole in return and down a day's vacation.
I've got a lot of sympathy for the person who says "this interview process is a lot of work" and who, after 17 years coding in production, decides they don't have time to invest in helping a room full of 20 somethings improve their interview skills.
It probably sounds a lot more bitter than I mean it to. I've looked for work 3 times since '98 and found it pretty quickly each time. (One of those times was within a day of starting to look)
I do worry about ageism going forward. Fortunately my current place has a lot of those gandalf-looking fellas. I love working with they grey-beards of programming.
In fairness, I think my experience with Facebook's interview process was worse.
> Standardize your process. If an elite candidate balks, then you've learned something about them: they'd rather your process suck and keep sucking than take any time to help fix it. That sounds to me like someone who isn't prepared to invest their time and energy in your team.
... huh? A candidate has no power to change your process. They aren't employed by your company yet. Even if they do go through the process and become an employee, it probably won't be in the capacity of senior manager, which is the rank that has some power to change the process.
If you ask the candidate 'okay, what do you see as the problem with our process, what do you think should be changed?' I'm sure you'll get some answers. Granted, if a candidate replied 'I'm not going to tell you. Looks like your process will just have to keep sucking!' then you could reasonably conclude that grape was sour anyway. I would be surprised to actually encounter that reaction; have you ever encountered it?
You missed the implication that interviewing a candidate you know in advance you want to hire helps true up your interview process. Just doing the interview improves the team's hiring.
I dunno, "you're great, I would love to work with you again" and "come pay a day of vacation time ($500+ cash; actual value much higher value due to scarcity) and jump through these hoops like everyone else" are somewhat hard to square with each other as a pitch to my former coworkers.
I get why a calibration process is useful to the company, but it's not particularly useful to the person who pays the costs.
Ah! I did indeed miss that implication. Okay, the logic of wanting to test your interview process does hang together, but still... this is at the stage where you are trying to convince the candidate to join your company; requiring them to test your interview process might end up being an expensive way to gather data points, if it gives some candidates a bad first impression. Are you sure it wouldn't make more sense to ask people to do interview process testing after they've already been in the company for a few months?
Having random existing employees go through the interviewing process as a test of the process itself is an interesting idea, though you'd have to be a big enough company to choose interviewers who don't know the "candidate" and there are probably other reasons why it would be difficult to pull off.
Throwing in an observation from one of the successful processes I've seen:
Before a new session or technical question gets added to your company's tech interview corpus, you require the team to dogfood it on in-house engineers. If the people you've already hired have poor feedback on the question/session, it may be in need of serious work or may just be something you shouldn't use.
they'd rather your process suck and keep sucking than
take any time to help fix it. That sounds to me like
someone who isn't prepared to invest their time and
energy in your team.
To be fair, you're asking them to make that investment of time and energy before you've decided if you're going to pay them for it or not.
Gotta have a pretty good prize if you want people to gamble for it.
> Perhaps the elite candidate is a canary in a coal mine, and fixing your interview would help your less privileged interviewees, too?
Yes, exactly. After all, fancy new dev is here to help your company, right? Well, make his first job contributing his insight and expertise to the interview process.
Your interview process probably _is_ bad. Having preferred candidates bypass entirely while leaving it there for people who aren't cool kids isn't the solution.
Labeling known engineers as "cool kids" is an easy way to dismiss it without addressing the very hard question: how do you condense weeks or even months of getting to know someone's skills into mere hours? If you know someone personally or have someone you trust vouch for him/her, is that not a pretty good way to focus your decision?
Those of us who don't have days or weeks to waste interviewing do what we can to build a good team. Yeah, that often means allowing good engineers to fall through the cracks, but we're all optimizing for time & effort.
No, what I mean is that if you rate the cool kids as better than the normal candidates, then it suggests that the cool kids do not think your test is an appropriate measure of ability.
If that is the case, either the cool kids are wrong and your test is doing an excellent job of evaluating your candidates, or they are right and you should find a new test which they and other candidates will be able to go through.
>> It's true: the developers with the best reputations don't get interviewed. They can get their pick of jobs just by networking.
This is arguable. Personally, of the local (London) developers I look up to, not one of them is in what we'd call here a prestigious job. They are still forced to apply to jobs as any other average candidate. I am referring to people I've worked with, and other with amazing github repos.
Despite all we've heard, I am forced to conclude that talent is mostly unrecognized in this industry.
> If an elite candidate balks, then you've learned something about them: they'd rather your process suck and keep sucking than take any time to help fix it. That sounds to me like someone who isn't prepared to invest their time and energy in your team.
Yeah, no. A thousand times no. The interview process isn't just you (the company) interviewing the developer, it's the developer interviewing your company. If I saw tons of red flags suggesting:
* a lack of knowledge about the software development process
* a lack of respect for the time of others, paid or unpaid
* a lack of standardized tooling and an unwillingness to use it
* a lack of flexibility (e.g. the inability to recognize multiple ways of accomplishing the same task or to go off script)
* a dependence upon non-managers to pick up after managers and administrative staff
* a surplus of bureaucracy or bikeshedding through which people exercise power
* kool-aid and enthusiasm instead of proper remuneration
I'd respectfully excuse myself from further contact and run the other way. New positions come with limited authority. Few good employees get excited about working their way up the respect ladder just to finally get the chance to tell everyone how inefficient they're being. And it certainly doesn't build those new team relationships to get hired and immediately turn around and scrap the recruiting process.
Yes, there are polite ways to approach someone about bad processes, but there are some people who don't like advice, even if it's polite. If they mention that they're clueless about hiring and that they want help, yeah, you can pitch in. But that's pretty rare in interviews, as it's not usually a positive factor in attracting talent.
Fixing broken code is one thing. That just planning with some T&M. Fixing a broken culture or business model is another. Usually that involves offending some old goat(s), playing politics, advocating for transitions, and in general stepping on lots of toes. That's not a software developer - that's a business consultant. There's a reason why those are generally not employees.
If you're wanting business advice, throw an extra zero on the end of the compensation and give them the actual authority to make changes. Then they'll be glad to give you all the unsolicited advice you can stand. But don't expect people interviewing for non-managerial positions to be able to (or want to) do your job for you. Some people enjoy that, but just as many hate it. And that preference has absolutely nothing to do with their skill or work ethic.
It's kind of obvious that no one really knows how the perfect way to select good software developers through the interview process. That's why we put up with interviews. But a bad interview can be sufficient reason to skip a potential employer.
"This model is certainly different from Joel’s model. Joel’s model assumes that “great” developers are sticky – that they stay at each job for a long time."
Is false. Joel simply did not say that. Joel actually said:
"..prospective employers recognize their greatness quickly, which means, basically, they get to work wherever they want, so they honestly don’t send out a lot of resumes or apply for a lot of jobs."
Great devs aren't on the market because they don't use the "market" to get their next job - not because the don't leave jobs very often.
> Instead, these people "travel as fast as beer" when they're looking for a new position - they mention it to a friend or colleague who has a beer with someone else who sends over a job offer.
Not that I am some great developer, but in multiple jobs over almost 20 years I have sent a blind resume exactly once. Even then, it was on a whim.
That may be true in the silicon valley, where there are companies ready to poach you on every other floor of the building you work at, and every other building in the street.
In the other cities of the world. There aren't that many places where you can work at in the area. Your network is limited and you still have to go through traditional interviews (supposing there are even companies to work for in the area).
I think you might be overstating the hiring activity in Silicon Valley, or confusing "interviewing" with "hiring". There indeed seems to be a lot of interviewing going on, not so much hiring.
I think you might not realize how lucky you are to be able to have interviews. There are places in the world where you can look 50 miles around and only find 3 companies who are (even remotely) a match for you. Whether they happen to have open positions at the moment doesn't even come into considerations yet.
No, I agree, and do consider it fortunate to at least be physically located among companies that are at least going through the motions.
But, in some ways, all-interview-no-hire is worse for candidates than no-interview. When you interview you're blowing at least one vacation day, and when the company is not serious about hiring it's a total waste.
I think nobody's done more damage to the developer hiring market than Joel Spolsky. His inductions about the liquidity of "great developers" seem to have become true mostly because he was the only one writing about it in the 90's.
But a lot of it is anecdote and faulty assumptions. I don't know of many other professions that have 8 hour oral exams that test the sum of all knowledge in the field with such a strong negative bias towards hiring. Or a profession that so strongly assumes ability is innate and cannot be trained.
I've not seen weak candidates that got hired get much better even after extensive coaching and pairing.
It may be that coaching, pairing and code reviews are simply ineffective in teaching people. They are also very expensive, since they sap the productivity of the rest of the team, and make planning and sequencing less predictable.
Overall, in my experience it's a lot less costly to turn down a candidate that might be good than to take one on.
(FWIW, the main metric in our company's hiring after meeting a minimum bar of an online coding test (~15 minutes to solution) is pairing with them on a problem that can be solved in several different ways. Getting a key insight into how to solve the problem isn't the metric; it's communicating different approaches and seeing how much explanation is needed to get the implementation idea across and how fluent they are at turning the idea into code. It's 2 hours of working together; it is not 8 hours of trivia.)
I've not seen weak candidates that got hired get much better even after extensive coaching and pairing.
I was very much a weak candidate when hired for my first programming job after university. No experience with shipping code or working on large code bases, virtually no experience with C++ or OpenGL/3D programming for an application where the core was doing 3D visualisation in C++, minimal relevant domain knowledge etc. etc. And I'd really like to think that not only did I get much better in the first 6 month I was there on a temp contract, but that I kept getting better in every aspect of the profession for the rest of the 3 years I was at that job. And even being on the other side of the 'table' I've seen people who could hardly code at all turn out perfectly acceptable code 6 month later.
It doesn't even take "extensive coaching and pairing", just a lot of nudging and pointing in the right direction, some well timed pieces of good advice and the occasional bollocking when they're being just a bit extra dense.
Everybody's weak the first time they do something for reals; that's not really what I'd classify as a weak programmer, but rather junior.
When interviewing a junior, ideally they'll have been programming since before college and are actually intermediate devs in disguise. But when actually hiring a confirmed junior, you look for a spark of intelligence but also go in on the understanding that (a) their potential is unknown, and (b) there are only so many juniors you can allocate across teams and maintain productivity. Juniors are a speculative investment.
Why is it ideal that a candidate has been coding since before they were in college? I understand wanting people who have an interest in the job, but how many other industries feel that the only good candidate is one whose been involved in it since they were a child? Sports are the only one that come readily to mind
> how many other industries feel that the only good candidate is one whose been involved in it since they were a child? Sports are the only one that come readily to mind
Classical musicians.
Of course there will be relatively few areas where early involvement is even considered in a candidate. How many 9 year old lawyers do you know?
Sadly true. If you haven't been practicing since before puberty, you will never be a professional classical performer.
But it's an exceptional and unusual field. Many professional non-classical musicians start much later, and still do okay - although it's a much more brutally selective field than software development.
Edit: I see no evidence that starting late makes it impossible to be a good developer, and plenty that an early start is irrelevant. Any reasonably intelligent graduate should be able to learn to be at least averagely competent at basic code grinding. It might take a few years, but there's nothing inherently magical about the process.
> Sadly true. If you haven't been practicing since before puberty, you will never be a professional classical performer.
This is correct about 99.999% of the time. The exception is when extreme levels of talent and interest are simultaneously involved.
Barry Tuckwell, one of the great virtuoso French hornists of the 20th century, started playing at 14 and was playing professionally within six months.
Hermann Baumann, another virtuoso French horn soloist, started playing when he was 17.
Anyway, I think that interest in programming before college is a likely indicator of independent interest and self-directed learning. I know a lot of folks majoring in CS or trying to get into development simply because it's a lot more lucrative than many other professions. Many(not all) of these folks don't have a genuine interest in programming which makes it unlikely that they will be effective developers.
I started programming around the beginning of high school and then stopped at the end of high school and became a car salesman. 8 years later I went back to school and got a CS degree and am thriving. So, I did have some early experience, but given the gap I feel like I'm more closely aligned with a late starter.
Now that there is a push to get all kids coding in school, this criterion will have to be tightened: I wouldn't be surprised to see: "had first PR merged into a Github project before college".
Of course these arbitrary criteria to filter junior programmers add no value, but are another symptom of how broken the entire business is.
Right, it's along the lines of people declaring that the only good programmers are the ones who have outside projects regardless or whether 8-12 hours a day of programming at a job is enough to sap anyone of creativity
Why is it ideal that someone has been coding before college? Simply because they have that many more years experience than everyone else. You may even be able to argue that coders are amongst the only people who have a non-negligible likelihood of starting the practice before college, I could believe this is the case.
I can also tell you that most the lawyers, bankers, consultants and doctors at my university will have been doing work experience + shadowing from around 14-15 years old. The even more ambitious ones will have been doing slightly more enterprising things (entering school/local/national entrepreneurial competitions), or reading around their interests, or joining/running societies.
When looking at the most successful people I know around me, what becomes apparent is that they started way earlier than everyone else. Look at Zuckerberg, he wrote Synapse when he was 16. It's unlikely you'll hire a Zuckerberg, but when someone started coding is a pretty reliable heuristic for how dependable they'll be in the job. Think of it as hiring a senior analyst to do an junior analyst's role, if you will...
> Why is it ideal that a candidate has been coding since before they were in college?
Imagine if civil engineering students were taught arithmetic for the first time at college. Firms would favor applicants with an interest from a much younger age, no?
The problem with software engineering is that understanding it well is as fundamental as understanding arithmetic. We teach arithmetic from the age of around six, yet we expect that starting to code only at college is somehow equivalent.
This is a quite unintelligent response - people can learn if they put their minds to it.
Case in point, I'm a PhD dropout from a top 15 math program in the US - I did not really code at all to any serious degree. After pouring a lot of time & effort, even after starting, I became very good at what I do. I have encountered plenty of people in the profession who have become solid to very good developers, including a former grad school colleague. The people have come from all sorts of walks of life, from college dropouts to sales.
Also to contrast, I have also worked with not great developers who have CS degrees. A degree does not tell me if you are passionate about what you do, or if you retained any knowledge from schooling - nor does various indicators that you have coded prior.
You seem to have assumed that I exclude anyone who did not code before college as incompetent, but I never said anything like this. I only assumed the context of the regular "attempted to become competent through college" route.
> ...people can learn if they put their minds to it.
Sure. I never said that it isn't possible to learn. All I'm saying is that there is a correlation when you consider the population in aggregate.
I'm sure the civil engineering industry (to continue my example) would be happy to accept somebody who started to learn later in life. However, given that it takes years to learn engineering if you start at the beginning of the knowledge tree (say, arithmetic), why should coding be any different (say, your first "Hello, world!")?
Since the current education system puts the learning of the beginning of this knowledge tree many years apart, it makes sense that the acquisition of competence at the other end is also years apart. Hence, if you follow the regular education system to learn software engineering, someone who started early will be years ahead of you. This is common in our field because the current education system is so far behind. Therefore, employers in our industry (as opposed to other industries) value those who started early more, and this is reasonable behavior.
> After pouring a lot of time & effort...
Right - and people who pour in a lot of time & effort are correlated with people who started early. This does not necessarily exclude people who pour in a lot of time & effort at other times.
I think I might not have made myself clear enough, sorry. Let me add some context to what I meant:
The problem with software engineering is that understanding [things like indirection] well is as fundamental [to software engineering] as understanding arithmetic [is fundamental to civil engineering].
I presume that this assertion, then, is uncontroversial?
Indirection may be fundamental to programming, but it is a fairly self-contained concept that in my experience can be grokked quickly. The math required for an engineering degree is based on arithmetic, algebra, trig and calculus, all of which are taught over a period of years.
I may still not be understanding you, but my own experience, when I learned programming as part of an EE degree (first language was C with lots of pointer manipulation) was that concepts like indirection are a lot simpler to pick up de novo than Partial Differential Equations, Fourier Transforms and other college-level math concepts are, even with 12 year grade school background.
"ideally they'll have been programming since before college"
Lot's of people get into computer programming as a second career. Rich Hickey, who created the Clojure language, studied music when he was in college. Later, when he was working at a music studio, he got serious about writing code in C++, and from that experience he developed his opinions about the flaws of object oriented programming, and the possible benefits of immutable data.
Your remark says a lot about the hunger for stereotypes in the tech industry. As if everyone is suppose to follow the same path to a career in computer programming.
This is very true, and I say that as someone who has been programming since age six.
With my prior employer, I briefly had the privilege of working with one of the smartest and most driven junior devs I've ever encountered, who'd been a professional figure skater in a past life and was fresh out of a Ruby bootcamp. This was a Node shop, and I've never seen anyone else go so quickly from zero to fully productive in a new stack. If the various dysfunctions of that organization included a prejudice toward long-term hobbyists, I still wouldn't have.
I'm saying that early coding implies a higher probability of having useful experience in a junior dev (i.e. straight out of college). You seem to be suggesting that I think that the probability of someone having useful experience is lower without early coding. But I don't think that at all; I don't care whether useful experience comes before or after college.
For a fresh recruit, lack of experience is expected and will be trained away. Nobody who is looking for fresh/junior developers ought to expect anything else. But most needs aren't filled by a junior developer.
It is absolutely the case that a good developer will have perhaps a few interviews, and then pick the best offer available. Meanwhile, a marginal developer will go to interviews for months until something sticks. Thus, of the candidates I actually see, I expect the ratio to be perhaps 50:50 whereas perhaps 95% of all engineers are actually qualified for their jobs.
When a "senior software engineer" candidate can't read ten integers from a text file and print their sum after 45 minutes in front of the language of their choice, I have to assume that I'd have an equally bad experience working with that candidate in the future, and pass.
The article leans too heavily on "great developers are sticky," which may or may not be true, but the above dynamic is the main reason we have coding screens for programming jobs.
Nobody has shown me a better way of screening that actually works any better, and the cost of a mishire at the senior level is high, so on we go with the tools we have, primitive as they may be.
I don't think i could type that off the top of my head. Sure, the normal java stuff public class Foo { ... blah blah blah ...}. Integer parsing with Integer.parseInt(...); do the sum in a loop, couple minutes maybe. But i have to look up references.
File because one of the constructors overwrites whatever is there there, and the Reader family because i can never remember what i need in the stack. I don't think i've had to open a file this year.
I guess it's better to just type in everything you know, then explain what you're looking up and why. But really at my desk, I'd instantly know what i needed to look up and go look that up before typing. Rather than local javadocs, i'd google for FileReader. But in an interview i'd feel bad.
Ah yes, and after actually doing it, i'm an idiot, and there's a nice convenience method that is perfect. Files.readAllLines.
Also, figuring out the package prefixes without an IDE kind of sucks.
Google has ruined me.
But yeah. stock linux + jvm and no internet connection? maybe 15 minutes? 5 minutes to figure out where the javadocs are, another 5 to find the docs. 5 for typing. Eh, maybe another 5 for remembering the weird path conventions for javac.
I'm kind of embarrassed it would take me that long.
edit
Oh gosh. you wouldn't have ctrl mapped to caps lock. I'd look like a complete moron.
Let's be fair, Java I/O -blows-. The whole stream, reader, buffered, file, blah blah blah, multiple levels of abstraction on top of the basic "Look, it's a file, let me read it", is what is getting you there.
Ideally if you chose Java, the person would let you handwave the actual library calls. Or you'd pick something saner. In Javascript, off the top of my head -
EDIT: Node, specifically, and with the spoken caveat that devoid of context of how it's being used, you're just going to let it block; were it a real application you'd use the async variant of readFile.
In C, in a handful of minutes (and with no reference):
#include <stdio.h>
int read_and_sum_ints(const char *filename, int n)
{
FILE *fd = fopen(filename, "r");
int c = getc(fd);
int sum = 0;
while (n-- > 0 && c) {
int m = 0;
while (c && c != '\n' && c != '\r')
m = (m*10 + (c - '0'));
sum += m;
}
fclose(fd);
return sum;
}
int main(int argc, char **argv)
{
print("%d\n", read_and_sum_ints("foo", 10));
return 0;
}
Given that I'm currently just an intern, I would expect both junior and senior developers to be able to do this.
I wouldn't be able to do that off the top of my head because, in my C experience, I hardly ever read files. Everything we did was reading from or writing to memory buffers.
Furthermore, we did almost all system interactions through a platform-independent middleware interface. So, while I, for example, knew what a semaphore was and how to use it I could not remember the standard Linux interface for semaphores because we used the platform-independent API for ours.
Expecting people to remember APIs off the top of their heads is ridiculous. Some do, some don't. The people who don't aren't lesser engineers just because they don't.
I agree people shouldn't have to remember APIs, but you should at least have a vague idea of roughly how to go about reading a file and parsing numbers from it.
As long as we're posting code/golfing (and since I've been lots of file parsing lately and it's fresh):
use std::io::prelude::*;
use std::fs::File;
fn main() {
let mut s = String::new();
File::open("numbers.txt")
.unwrap()
.read_to_string(&mut s);
let sum = s.lines()
.map(|l| l.parse::<i32>().unwrap())
.fold(0, |acc, i| acc+i);
println!("{}", sum);
}
The value of EOF is platform-specific, but is commonly -1. I'm fairly sure it's never 0.
But I was referring more to the fact that c is set exactly once in line 4 (`int c = getc(fd)`), outside of the nested loops, and never touched again. So if it's not initially a NULL, newline or CR, it never will be, and the inner loop will never exit.
I don't know why it's so important to see a junior developer's work before college. A junior is supposed to have near 0 experience, it's more important that they can demonstrate problem solving skills and willingness to learn.
Eh? I don't think it's important to see a junior dev's work before college. But if someone has been coding from a young age, if they've been self-taught, it's a very promising sign - they're self-motivated and are likely to stay up to date on tech - and a bonus is you're effectively getting a more experienced dev for the price of a junior dev (though in reality people should recognize this and bid their price up).
I disagree, whether a young developer have projects to show before college is near irrelevant to if they'll become a better developer as a professional. It doesn't automatically translate to self motivated, the only thing it shows is the candidate has early exposure to some technology. To my experience most people start programming from a young age are because they have family members in this profession and were asked to learn programming from a young age. I'm not saying there aren't any really due to interest and motivation, I just haven't met any yet.
To me whether you start programming before college is like graduate from Stanford, you may or may not be good, it will make me more likely to interview you, but not more likely to give you the job.
I've met several self-taught programmers with very bad habits that had to be unlearned and missing fundamentals (writing O(N-squared) algorithm and not understanding why not to). Not all self-taught programmers are this way but it's not an unambiguous green flag.
I was an inexperienced candidate when I got my first dev job. I had literally some very basic front end skills in that I could use jquery to change font colors. I'm now a fairly seasoned backend developer - if nobody had taken a risk on me (for low pay at first) or mentored me I would not be anywhere near where I am today. We treat training like a cost center and despite the huge amount of money being made out of the tech industry there are very few companies organizations or even groups of people that prioritize taking time to make people productive. I don't know the solution but it seems that there is a huge untapped amount of potential skill that will never get used.
I don't think programming is much different than any other endeavour. Talent will bring you a long way, but requires practice and training to get you to the point where you are good (or better than good).
People with average talent can become quite good, but just like everything else, they won't be able to catch the more talented person who puts in as much effort and receives as much coaching.
However, if you look at things like sports, the margins are really fine. A 2 minute margin of victory in the Tour de France represents less than 1% of the total time in the race. People at the top end of sports have the best training, the best coaching and the best talent because 1% is the difference between winning the championship game and not even making the team.
The margins in programming are huge in comparison. Someone with average talent who has good coaching and works hard in a consistent way will be so much better than your average developer that I think talent barely works into the equation. Just like everything, the super talented are rare, but in our field it doesn't matter because we can potentially train people to be much more than "good enough".
You have hit the nail on the head, though, with respect to the problem. Training is a cost centre. Let's say you take a person right out of a boot camp -- they can write code, but have only a couple months of practice under their belts. While they can improve dramatically over a year or two, it's still going to take 5 years or more for them to hit the "much more than good enough" level. If you want them to be able to handle the nuances of making sure a project is successful, you need at least another 5 years on top of that.
People change jobs every 2-3 years on average. You are just starting to see some payback on your investment and they are gone. Even worse, investing in training costs you more than buying talent. If you spend time and money (and factor in the cost of lost opportunity by hiring people who are still learning their craft), when they reach the level of a more experience/talented individual they want the same pay!
So you can pay double for someone talented who has 5-10 years of experience, or you can try to train someone up to that level. After 5 years, they still want double (if they are even still around), even though you have invested in them.
This is why the top teams are willing to spend ridiculous money (2x the median) on top people and are unwilling to train anyone. The teams who aren't willing to pay top dollar also are unwilling to pay for training. They think they can get twice as many people if they pay half as much and will get more done. They aren't interested in paying for increased skill.
Unlike sports, 1% difference in ability has virtually no meaning in programming. This means we don't need to scour the world for the best young programmers and build a world class training program for them. At best, we pay double for people who have the talent and/or experience to be "much better than average".
I think part of it is about the price of failure - why do people need not only GOOD programmers but the BEST? Because their business model doesn't work unless they succeed fully, the first time (and most still fail). I wonder if it would be better for innovation if ventures could be made without putting ones entire livelihood on the line - I've found that the more "assured" a business is of its model, the more willing they are to coach and train people (at scale, it costs less to have a training regime so you can move lower-paid programmers through your company than it does to pay the highest sought after people in every place of your company).
I think part of that perception may come from the kinds of companies you have dealt with. There are many companies where the "IT" side of the company is considered to be mostly superfluous. In fact, most programmers work for these kinds of companies. In my experience, there is still very little training. At best you'll get a 2 day "Scrum Master" course, or a couple of days to go to a conference here or there (which is sadly often seen in the same light that sales people view a sales junket). Even in big insurance companies, etc people don't stick around as employees for long. Of course these companies are not the ones paying double for good programmers.
People make that judgment based on inconsistent opinions though because ultimately it's measuring developer ability against a commonly held standard and we don't even know how to do that.
What were you working on, if you don't mind my asking? I really enjoy graphical programming and I'm curious what kinds of jobs involve that, besides the obvious ones like video game programming.
I know this is all very anecdotal, but I certainly have seen developers that I wonder for months how they could have ever been hired, and given time become quite capable. I first started to notice with out of college developers, but eventually saw beyond that too.
In my experience, the ones that were 'capable' from the get go either had a lot of experience programming on their own, or had some internship or other real world work experience. The ones less capable didn't.
Then I realized that my measure of 'capable' was probably unfair, because I expected people without having worked before to be aware of all the complex details that working with other developers entail. All the annoyances you have to deal with about writing real code that needs to evolve and change that only a stable work environment provides.
Then I took it one step further. What if the ones that weren't out of college were just never expected to really improve. They never had the chance to be exposes to a stable work environment that required growth. They just either were let go from previous jobs before being allowed to grow, or weren't put in an environment that neither required nor promoted growing? I think not all jobs do a good job of demanding and providing space to grow. And that's a problem. It's possible to 'get good' on your own, but it shouldn't be expected; and it's far from the only way.
So maybe we are being a bit unfair when we say a candidate is weak. Maybe they just haven't been in an environment that would require and allow them to improve.
In all walks of life, people with more experience are expected to be more formed, more of a known quantity, than people with less experience. The distinction between a junior candidate and a weak programmer is mostly down to the length of their CV. If someone has been programming for a few years, it's a bad sign if they're not very good at it.
You can spend ten thousand hours doing the first hour of the same work, at a bad job. There's a lot of bullshit positions with poor management that don't exactly lead to programmer development.
Yes. And if I'm expecting to hire a senior developer, I quite naturally don't want the person with that experience, because that's not an actual senior developer.
No, but if you had a crystal ball that could distinguish between those who had been given lots of opportunities but never improved, and those who just need a little bit of training to make them a world class engineer, then you'd have an amazing hiring advantage relative to your competitors.
I know some smart, thoughtful, enthusiastic developers who have only ever worked in one team, and that team had a bunch of dev practices that don't fit the industry's typical expectations (e.g. zero automated unit tests). Many companies would pass them over because they'd bomb that apart of the interview, but with a couple of months of on the job training, they'd fit right in.
When they go looking for a new job they're going to find it hard, but whoever can see through their inexperience an is willing to take a chance on them will be happy they did.
I have. In fact: it became sort of a norm. Want to talk more about it?
I'm sure there's a definition of "weak candidate" that perfectly captures "uncoachable". But my definition, and I think it's the common-sense definition, is that a "weak candidate" is one who gets as much negative feedback as positive (Joel Spolsky famously advocates for "if you have to ask, the answer is NO HIRE"). Most of the people we hired at Matasano for several years fell into that category, and most of them wound up outpacing the strong candidates (none of them did badly).
Are there any other companies that you know of that do what you did at Matasano (offer post-hire specialist-type training to non-specialists/generalists is how I understood your posts about it)? The moneyball/trainingball idea seems like such an obvious way to get the people a company needs that one would think it would be somewhat common by now.
For all the alleged shortages, can it really be that all these years later companies are still unwilling to gamble on training because they feel like people will leave too quickly?
Companies have too incomplete a notion of the value of training and a positive environment to retention and productivity. People really do think skill is innate and people 'are who they are' more or less.
It's probably not true in 80% of cases, is true in 20% of cases, and the 10% of cases where people got burned by a poor candidate who couldn't improve are the ones they remember and say "never again;" likewise the 10% of cases where they are amazed by a highly skilled candidate and think all of them should be that way. They're missing the majority effect that impacts the productivity of 80% of their workforce.
This is why it's crucial to have an innate sense of human variation and psychology, a la W. Edwards Deming. So, in that sense, it's not the employees that need the training, but the managers.
I know lots of the big name consulting companies in London at least used to do it. A friend of mine with a physics degree from Oxford got job offers for all kinds of things on the assumption that if you can get a physics degree from Oxford, you can probably learn other stuff as well. He ended up doing some sort of forensic accounting.
A friend of mine in Australia became a management consultant with a PhD in physiotherapy, they essentially were saying a PhD in anything is a good base.
From my perspective, I see that several other skill-based professions assume novice hires, and emphasize a some sort of on-the-job training as part of career progression.
In software dev, as much as we have stack overflow and such where we can figure out trivia of the tools we have to work with, I guess we'll come to the realization that some kind of formalized training post-hire will be useful, especially as development becomes more specialized or domain specific.
I know you've talked about your case as a counterexample, but I think it's because it's not coding ability you were finding hard to get, but security and pen-testing knowledge and experience.
To my mind, that's domain knowledge, and domain knowledge can definitely be taught, and much faster than how to write good code in good time.
I think sending some pen-testing books to a bored and under-exercised VB programmer may well get good results; but put the same guy in front of a problem that is almost completely abstract, and if he's able to understand the solution you present to him and create code (in any language he likes; we don't care about specific language experience either) that implements the solution, then he'd get hired at my company too. Because we don't test for domain knowledge; we don't expect it. We test for ability to communicate, understand and turn concrete implementation ideas into code.
It's a programming job. Matasano wasn't a netpen firm; every project involved us digesting and processing some giant blob of other people's code. Everyone on the team had to write tooling and, more importantly, quickly understand other people's code well enough to outguess the authors.
I don't accept the argument that we were hiring for an easier job than "programmer"; I think we were looking for a subset of the population that ordinary software development teams look for.
The bored and under-exercised VB programmer, by the way, helped found the NCC Cryptography practice, and moved on to one of the greatest crypto software development jobs in the industry. It's not my place to say exactly which job, but if you make a mental list of the 5 coolest crypto software development jobs that might exist, it's probably one of those five.
The problem is everyone else runs hiring processes that assume the bored VB programmers are just VB programmers. They are wrong. Joel Spolsky was also wrong about this (despite the other nice things he said about VB).
> I think we were looking for a subset of the population that ordinary software development teams look for.
I think that's actually why your experience might be less representative, but I'm open to being corrected.
Security is generally considered harder than regular development, at least to the extent that it would typically be hard to get a security job without security experience.
From what I understand, your model was to take programmers with no security experience and train them on security. The effectiveness of this doesn't surprise me at all, because it's fundamentally a different problem than taking someone who's bad at programming and teaching them to program better.
I have absolutely no problem with hiring someone who's a good VB programmer and teaching them to do web programming. What people generally dispute is whether you can hire someone who's a bad programmer in general and "train" them to be a good programmer.
> I have absolutely no problem with hiring someone who's a good VB programmer and teaching them to do web programming. What people generally dispute is whether you can hire someone who's a bad programmer in general and "train" them to be a good programmer.
How do you know if a programmer who is in a field you are not familiar with is good or not?
You can ask someone to show you some code they've written and teach you about it. Concepts transcend language and field: if you understand what you're doing and why you're doing it when writing a VB program, I have high confidence that with a bit of time you'll also learn to understand how and why to write other kinds of programs effectively as well.
Why does it have to be this complicated? Explain some of their existing code? Why not just give them a representative programming problem that your team has already solved, and ask them to code up their ideal solution? That's called "work sample hiring", and it's the gold standard for candidate evaluation.
Frankly, your statements are extremely conflicting. Pure work sample hiring is in direct contradiction with hiring trainable people.
I do not expect a VB programmer to be able to code up a single-page React app during an interview, even though building a React app would be a representative problem. Do you?
So which one is it? Hire exclusively through work samples, or hire trainable people? I mean this seriously: how do you reconcile these two? You're a strong proponent of work sample hiring but also of training—do you expect people to come in and do a security audit for their interview, even when one of your hiring goals is to hire people with no security experience?
I would personally much rather hire someone who is a strong overall programmer (but might very well not be able to code a JavaScript app in an interview) over someone who knows a little JavaScript (so they can do a simple problem) but has relatively shallow abilities.
> That's called "work sample hiring", and it's the gold standard for candidate evaluation.
Having a discussion about someone's existing work is, in fact, another gold standard of hiring and is quite similar to having someone do the work on the job. It's not quite as good as having someone execute work, but it's the next best thing—especially when you're trying to hire people who don't have direct domain experience.
I think you're neglecting to remind folks that Matasano would give people a crypto textbook to study from first.
So if a VB programmer were applying for a React job, you'd say, "here's a React book; we're going to have you code a React component during your interview. Let us know when you're ready to schedule."
Google does not hire with a work-sample test. tptacek's claimed process is therefore easy to distinguish from Google's. Maybe better, maybe worse.
Google does allocate non-trivial time on training, though, both on the candidate's time before the interview (as you note), and on paid time after hiring.
What a low effort reply. Honestly, I expected better from you. This is pure argument from authority without any attempt to confront the fact that there is in fact a very real contradiction between hiring through work samples and investing in training.
For the record, I have done work sample hiring. It's definitely my preferred strategy, but it's also far from a panacea.
But it's also equally true that if you give someone a work sample to build a React app and their entire experience is in backend programming, they will do not very well. Would you really be surprised if someone fails to produce good work in an environment, language, and domain completely foreign to them?
Taken to the extreme, some companies traditionally hired engineers who had absolutely no programming experience and trained them to program on the job. Would your advice to them also be to "hire through work samples (of programming)?" How would candidates who, by definition, need training to even do the work be able to produce a work sample?
Your whole "I know best, so I don't have to provide logic or evidence" schtick is really getting old.
There's no contradiction. Set the bar where you need it to be, but make the bar about ability and aptitude, not about people talking their way through an interview.
If your bar needs to be super hard, set the bar there. If you need people to understand in detail when and how to use shoudComponentUpdate and how to write a pure functional component, do that. I'm not arguing that React shops should hire people who suck at React.
I think you think I'm saying something I'm not saying.
> I'm not arguing that React shops should hire people who suck at React.
I guess I misinterpreted that you were a proponent of training people.
Yes, if you want to exclusively hire people who are already good at React then of course work samples are an effective technique. I personally think the majority of good hires are not already familiar with my particular stack.
> Set the bar where you need it to be, but make the bar about ability and aptitude, not about people talking their way through an interview.
I think you might have misinterpreted my position as well. When I ask people to talk their way through their existing projects, it means they literally bring some code with them and we spend the interview working through it and them teaching me about the decisions they made in building it. You should try it some time.
Also, it's easy enough for a VB programmer to get started with React, he/she can quickly teach himself/herself some js and then follow a tutorial online, and after some point build a toy application with React. And that can be the work sample. It won't be a production ready app, but it will be fine for a junior React guy.
Oh, I agree about VB; once upon a time, a long time ago, I too was a VB programmer (before I discovered Turbo Pascal and then became aware that I found the distinction between Let and Set disturbing; I ended up loving Pascal so much I spent 5 years at Borland on the Delphi compiler).
While at Borland, another engineer (Allen Bauer) shared his personal theory, that some engineers were great at reading code, more were great at writing code, and not so many were great at both. Sounds like your job required people that were very good at reading code. It intuitively feels very testable.
My latest hire (I hired them almost 1 year ago) was very green (no job experience, didn't study CS, autodidact programmer). But I saw enough drive, motivation & willingness to learn that I gave them a shot. It has proven a very advantageous hire for both parties. I invested a lot in them and the investment quickly bore fruit.
A previous person I hired (in a previous job, for a different company) had a lot more industry experience as well as appropriate education. They were quite capable but I had a slightly bad gut feeling, ended up hiring anyway cause I didn't want to discriminate against a seemingly capable candidate. Ended up being a poor fit: argumentative and not willing to accept that they do not always get to call the shots about how stuff is done. I think this was disadvantageous to both parties.
In the future I will definitely prefer hiring someone showing a lot of potential than someone skilled who I suspect may not be a "team player" (for lack of a better term).
I always took Joel's writing with a large pinch of (kosher) salt. He's a great writer in that he knows how to flatter his audience (us). But two things always niggled me: firstly that I didn't know a single person who actually used his products and secondly that it simply wasn't plausible that the top talent in the industry would be jumping through hoops for a chance to work on software for project managers.
I stopped seeing him as an unfailing source of truth after he okayed developing fogbugz with a private, in-house language, that (unsurprisingly) was a huge waste of resources.
It's not about being afraid of computer science, it's about being pragmatic and efficient about the problems that you choose to solve. By choosing to develop your own closed-source language, you now have two projects that need to be developed, the product itself and the language that it depends on. They retired the language (Wasabi) some years later specifically because it was so demanding to maintain, there was significant on-boarding for any new hires, and it constrained their developers by frequently being behind the current state of C# (which it compiled to). When you write your own language, you don't have an entire open source community updating it, fixing bugs, and maturing it with new features and libraries. That is now work that your team needs to take on, and in the vast majority of cases, the negatives far outweigh the positives.
I think the main advantage is that if you emit JSON then you know that someone else isn't going to write a bad parser for it. Given that we can't depend on people to do simple things like handling escape sequences correctly, that seems pretty important. (Also, the 'jq' command is nice.)
Fogbugz is (was?) writing a language for internal use only, so it's a better fit there.
> Given that we can't depend on people to do simple things like handling escape sequences correctly, that seems pretty important. (Also, the 'jq' command is nice.)
jq stores all numbers as doubles, which means it can't handle 64 bit ints (or larger integer numeric types).
It's otherwise a great tool and I wouldn't point out a negative such as this, but you did explicitly mention that you know JSON won't be fed to a bad parser.
That is what almost all JSON parsers do; even the spec says that you shouldn't rely on more precision than a double:
This specification allows implementations to set limits on the range and precision of numbers accepted. Since software that implements IEEE 754-2008 binary64 (double precision) numbers [IEEE754] is generally available and widely used, good interoperability can be achieved by implementations that expect no more precision or range than these provide, in the sense that implementations will approximate JSON numbers within the expected precision. A JSON number such as 1E400 or 3.141592653589793238462643383279 may indicate potential interoperability problems, since it suggests that the software that created it expects receiving software to have greater capabilities for numeric magnitude and precision than is widely available.
Good to know about the JSON spec. The only JSON parser I used before jq was the Python stdlib parser. Python JSON correctly handles big integers, which lead to my (out of spec) expectations for jq to do the right thing.
On the other hand, don't we always hear people say that it's a really bad idea to write your own crypto algorithm, and you should use something that has been extensively tested and vetted instead?
I would posit the same applies to writing your own programming language: it may be fun to do as a hobby, or when you are learning, but may not be a good idea to use it in production to rewrite your company's flagship software.
The most obvious reason is that it's much, much easier to design a new programming language --- especially the extremely simple kind of language that Wasabi was --- than it is to build a new cryptosystem even with vetted primitives.
The second is that the impact of any crypto error you make is very likely to be game-over, while most programming languages aren't (you can observe this empirically from MRI Ruby).
A third is that designing new programming languages, especially the simple kind that Wasabi, is a straightforward well-understood engineering task. Nobody with a CS degree should be incapable of doing it competently. You cannot say that about cryptography. In fact: many of the problems people attempt to solve in cryptography (take, for instance, multi-party secure messaging) don't even have well-understood best-practices solutions; they're still active topics of research. Not to do better, the way Haskell was an attempt to at innovating a better functional language, but to reliably do at all.
I could generate more reasons. This is just the top of my head. There is simply no comparison between the two problems. I implemented a new scripting language for building TCP/IP stacks in my first professional programming job ever --- in fact, it was the first programming assignment I got in that first dev job, and I had to do it in C. I handled it comfortably. 20 years later, and I still wouldn't be comfortable implementing most cryptosystems myself.
I'm not afraid of parsers - I like them so well that I have to be careful not to use them on problems a regex or two will much more maintainably solve.
But I would hesitate somewhat to join a team which used a language developed entirely in house. As enjoyable as such work would undoubtedly be, it also reeks of overengineering, unless the problem space is so unique that no extant language can effectively address it. Experience suggests that project management software is not such a space, and the maintainability risk of a bespoke language seems therefore very hard to justify.
On the other hand, I don't pretend to be a "top dev", by anyone's definition - top quartile, maybe, on a very good day. So perhaps I'm just not favorably enough placed on the capability curve to understand why it really is the great idea that it doesn't seem to be.
If you read some of their postmortem stuff on that whole situation(which is pretty much an engineering meme at this point) they are in no way willing to admit that as a mistake. Tump would have a run for his money on avoiding admittance of mistakes..
I don't think that was the OPs point but along those lines Stack Overflow doesn't use Fogbugz. I'd love for them to tell us why Fogbugz is not a fit for Stack Overflow
I don't know if you're being sarcastic, but I will choose to take your words literally because Excel has had an enormous productivity impact on the people who used it, and in many areas changed how business was done by introducing programming and automation (formulas, pivot tables, graphs etc.) to technical business users.
Edit: glad you were not being sarcastic :-) thanks for clarifying
I was not being sarcastic. As a person who builds statistical models of credit risk for a living, I truly consider Excel to be one of the finest software ever made. I generally consider it true for a lot of Microsoft products, though most people in this forum tend to disagree.
From what I've seen, the the spreadsheets themselves are great, but the lack of good version control, revision tracking, and regression testing makes for poor operational processes.
People e-mail one another Excel workbooks, there's 5 different versions in flight at once, and impossible to find when an error or mistake got introduced or who was responsible.
Computerised spreadsheets were inevitable, we've been using spreadsheets in some form for thousands of years. Visicalc is recognised as being the first, but Excel has been the dominant product for decades now, for all its warts it has had a massive impact on humanity.
Not the OP, but I think you misunderstood.
Excel was always a windows application that had the same functionality as lotus 123 that was a DOS application. So much so that the keyboard interface is still compatible.
Actually what I remember is that Lotus killed itself by not having a windows version on time.
Or a profession that so strongly assumes ability is innate and cannot be trained.
And that, by virtue of being plunked down into the interviewer's chair through whatever chain of random circumstance... you've suddenly become innately endowed with the ability to evaluate it in others.
Is this including the Joel Test? While that makes more sense for the land of native applications over the web, working with a company that is 0/12 is a vastly more terrible experience than 12/12. Granted a number score doesn't matter much when certain answers have more weight and you could argue someone would've come up with it eventually. When I first heard about it though, I immediately started working on getting better answers for the company I work for and continually do so. I can't speak to what you're talking about as I somehow glossed over that but maybe that's its own problem. It's easy to fanboy when something great comes along without understanding the years of opinion that went into it.
I think you being a too literal in your interpretation of the phrase. 'the best money can buy' is figurative - it means 'the best available, regardless of circumstances'. The 'money' part is figurative; it represents resources.
I think it's a little unfair on Joel Spolsky's team to suggest they might not be good at what they do based on a semantic argument around whether 'the best money can buy' can be interpreted as using resources or just cold hard cash. Considering the things they've built they're very evidently a highly accomplished group of developers. I don't see any need to argue about this; they're obviously using what they believe are the best tools for the job. You can tell that from looking at their results. Whether they're using free, open source things or they're buying tools isn't relevant, and certainly isn't a sign that "your development team is probably really bad". They're clearly not bad. They built Trello and StackOverflow.
I totally agree with your assessment of the wording. Money, to me at least, never equates to closed or open source. Fortunately, at least with stack overflow jobs, you can kind of self-assess this if they list tools like JIRA or Trello. You can also ask questions to see if they're actively using what they claim. If they aren't singing the praises of their toolsets and checked that answer off, you can generally assume they're lying.
If the test was updated for the web and native in a single set of data points, some companies would incorrectly score low because they focus on one or the other. I think it could use some kind of polish after 16 years but only to remove very narrow interpretations that derail discussions like this.
I'd like to back this up. I went from a ~6/12 company to a 0/12 company, and man is it painful. I knew going in it was going to get low marks, and saw it as a challenge to try to push it to 6/12 level if possible (a nice career highlight imho), but I drastically underestimated how taxing it would be.
The biggest factor I didn't consider: People who exist in a 0/12 system are at best willing to tolerate it and at worst have engineered it. Change within that population will be challenging, even if they all publicly claim things need to change. You end up dancing on a razor's edge of being a positive change agent and being made a pariah. All while trying to do actual work.
well even on hardware.
on my daily base I use a macbook pro late 2013. however we also built a workstation from ebay components. the workstation is as fast/faster than any computer you can buy at the moment, however money wasn't the problem, more the resources to get everything, resources would be the correct word, not money. not every resource is buyable.
and some stuff on the list also only applies to bigger companies.
The macbook pro 2013 is probably 10 time more powerful than the thing i use. And your workstation probably used 10 time more money than what my company allows as a budget.
I am not saying everything should be there but yes. There is totally a point to the test. Being really low means you are in a shitty place. Being high means nothing.
well our standard developer workstation is around 1000€-1600€ for 4-5 years. so my laptop will still need to be used one or two years, actually it's also over the budget, but basically if there is a need for it we buy it and some people are just way more productive with a mac since they knew it form day one, however most new hire's actually used linux/windows so they never want it or only want it cause others have it. it really depends on the needs. we are a java job and I even encourage everybody to use IntelliJ Ultimate, however some still prefer Eclipse and I let them use it, even if I dislike it, it's still their preference after all.
Oh totally i think we are talking of different things. I have to dev on a shitty netbook, on a 17" 4:3 15 years old external monitor and i can't use any external dependencies repository...
> Or a profession that so strongly assumes ability is innate and cannot be trained.
Like most things, it's a spectrum.
But if you have a knack, you'll enjoy it more.
Enjoy it more, you'll do it more.
Do it more, you'll get better at it.
This feedback loop has been suggested as one root of the (contentious) "xy,000 hours equals mastery" findings.
But it's only true up to a point.
We know that in fields subject to large-grained biological differences -- sport, in particular -- genetics swamps training effects. Most of what matters is throwing people at a sport until you find the person who is freakishly good at that sport. Which is why Australia is the best at Australian Rules Football, why the USA is the best at Gridiron, why China has come to dominate the lighter weight classes in Weightlifting and so on.
Actually, the established science in weightlifting and other sports is that only the top 1% have to play based on their genetics. For most people it's more a matter of having a decent training program and sticking to it come hell or high water.
I think if you look at software work you'll find the same kind of dependency on training rather than some innate gift.
I would add Google, Microsoft, et al to that list. Seen lot's of candidates come in for interview who have read books like "Cracking the coding interview" who have obviously memorized the white board solutions to complex problems who then can't implement 'boolean equals(Object)' correctly when asked to do so.
At least Google can say "we get so many applicants this is what we have to do!". Why do random web dev companies attempt to grill you with the same level of rigor as Google is beyond me.
Because they like to flatter themselves that the problems they solve require top talent, and they, the current employees are top talent. Usually neither is true, and they don't pay like Google either.
Then why do their recruiters reach out to candidates with extensive work history and slam them into the standard hiring pipeline(I'm not talking Google specifically, but the BigCos in general). It's not because they have too many people applying, it's because they have too many people complying.
While I can't speak for all Microsoft interviews, I will say that I was pleasantly surprised to find that my (successful) Redmond interview had zero focus on traditional "coding interview" questions and instead was 50% about my prior work and the rest about some interesting software dev questions focused on design (not whiteboarding, not algorithmy), culminating in this lovely networkingy question. This is true for the MS interviews of some acquaintances of mine too.
OTOH I have yet to find someone who has had a Google interview that did not have major focus on algorithmy questions which you can just memorize for. To be fair, most of the folks I know are students; Google may have different tactics for more experienced candidates.
I'm sure Microsoft does this too (and I know that Microsoft is where this attitude came from in the first place), but it seems like it does it much less (from my limited anecdotal view) these days.
Google does not seem to have a different tactic for experienced candidates. My onsite was only algorithm questions on the whiteboard with about 5 minutes of 'do you have any questions for me?' for each of the 5 one-on-one interviews I had (not even asking me about my prior experience).
Programming ability is of course not innate, but the ability to learn to be great at it does seem to be mostly innate. You can overcome a lack of innate ability with hundreds of hours of hard work - but you'll never be able to catch up to someone with that ability who has also put in hundreds of hours of work.
That aside, nothing you said actually provides any support for your criticisms. Your comment can be condensed down to the phrase "that's wrong" without losing any meaningful content.
By nature, if you post an article stating the truth of the matter - that truly good people are extremely rare and that most people tend to be mediocre and some serviceable - most people will be outraged. Because they're the "most people" being called mediocre to serviceable.
As the article points out, most jobs are mediocre. Good work is not appreciated, a company can't form a team that works normal hours and uses tests and version control, autonomy and learning is low, the work is some dull obscure business problem, IT and the company is dysfunctional and pay for the skillset is below market average. Yet all these companies want great developers as well.
Also, as he mentions in the article, sometimes a great developer does roll in but they get filtered out for some reason. In my experience it is usually due to age - a great developer who is 52 comes in, but management almost openly says they want someone in their 20s who they can push around more when they nix the person.
So the mediocrity goes both ways. When Oculus got going they seemed to have little trouble getting some of the best graphics programmers (Abrash, Carmack) to join them. If you want a great programmer you need to be a great company with a great position.
Exactly. 95+% of all developer jobs are not particularly novel nor do they require the top 1% of developer talent. However it seems like 95+% of all developer jobs believe themselves to be novel and requiring the top developer talent.
People keep saying this, but I don't think it's as easy as you make it sound. What about the candidates that talk so much that it seems like they are stalling and therefore don't get a reasonable and reasonably complete solution on the whiteboard in the alloted time, despite repeated prompting? What about the guys who don't explain much and take way longer than expected on simple problems, and when asked about it reveal that they are just blowing all this time internally debating the perfect solution?
I'm not in charge of setting our hiring bar so it doesn't really matter. Given my druthers I'd give a candidate a not particularly difficult multi-hour coding project just to show that they can build something and would like to have a conversation with them that shows both breadth and depth of knowledge.
Ok, but none of what you said addresses my concerns. And sadly, this is what always happens when I press people for better interviewing techniques.
If they can't finish squat in 60 minutes are they likely to finish something in double that time? If they are, I could just ask them something that should take 30 minutes to finish and give them double that time to finish it, and just pretend like everything's fine...
> and would like to have a conversation with them that shows both breadth and depth of knowledge.
Conversation is nice and all, but there are people who can do that but fall flat with the coding. And that is a significant part of the job.
It would help having some above average developers (or maybe architects is a better word) on the past two projects I have inherited. They clearly knew a lot of stuff, but elegant database and application design wasn't one of those things.
> Programming ability is of course not innate, but the ability to learn to be great at it does seem to be mostly innate.
It's no more innate than any skill. The only innate aspect to it is the desire to do well at it.
> that truly good people are extremely rare and that most people tend to be mediocre and some serviceable
The problem with this sentence is the word mediocre. The vast majority of developers are average, which is to be expected. The problem is that Silicon Valley is seen as the norm for development and not the exception. SV plays right into the personality culture we seemed to have built (thanks to social media), so people start thinking all development is like that, whereas most people just want to do their job and gohome to their family at night.
To play a devil's advocate, Spolsky's advice was provided at a different time. Perhaps then the requirements and thus necessary skills were different from today, and it might have made sense to rely on his quick and polarizing criterion. I do agree that his tone is brash, noninclusive and overall damaging to the industry as a whole. I would imagine some people would be discouraged from even trying to get into the industry after reading some of his articles.
You hit the nail right in the head, it was a different time. I remember back then how many people had completely fake and fraudulent resumes and a very large part of hiring was just trying to filter our the fraud. It was massive at some point. It seems to be better now but back then it was just incredible how much resume fraud there was :(
No doubt Joel Spolsky is a great software engineer. But sometimes when reading articles like the 'great developers', I feel like he's standing on the high ground and look down on us mere mortals.
Sure it's near impossible to find 'great' developers, but most companies don't need great developers, they need good competent developers and there are plenty of them on the markets at any time. I would say the positions that require a 'great' developer to work on are as rare as great developers themselves.
I've been in the industry for 10 years now and I've never seen this at all. I know a couple of people that applied to Google, and they reported that it was a fairly gruelling process, but apart that, I haven't even heard from friends about people going through anything approaching 8 hour interviews.
> I haven't even heard from friends about people going through anything approaching 8 hour interviews.
Is this a joke? "All-day" interviews are so common as to be the usual expectation.
And while they aren't always a full 8 hours, it's not unusual for them to be 5-7+ (including giving candidates a lunch, and interviewing them during it while they eat).
I wonder at what point this becomes self reinforcing. They need the 8 hour interviews because only the most incompetent will tolerate it or the ones with full time jobs already can't make the time for the interview.
I recently, in the past two years or so, interviewed for a (contract-to-hire!) position at a major airline. First I had a 30-minute phone screen. Not bad, did great on that. Then they had me out for a two-hour face-to-face onsite, which I had to take time off of my current job for. The feedback I got was positive, so they wanted me to come back AGAIN for another set of two two-hour face-to-face onsite interviews (which, again, I had to take time off for). My first face-to-face interview showed up 30 minutes late and kept me for two and a half hours, so I was late to my next interview, who kept me for another two hours.
I've done tons of interviewing and I'd say that 1 hour on the phone + 6 hours in person is the MINIMUM interview length I've ever seen. It goes up from there.
This does not seem to vary across company sizes, locations, job level, etc. Everybody copies this horrible process.
I still can't wrap my head around how Joel Spolsky, of all people, became such an influential voice in software, especially considering that every single thing he's ever written has been an opinion piece (and you know what they say about opinions...) He went to Yale and worked for Microsoft - both of which, in fairness, eclipse any of my own accomplishments - but there are a LOT of people who've done that and then some.
I agree. I think a motivated engineer is far better than a talented one. Some really talented/experienced engineers might find day-to-day programming tasks trivial/mundane and their biggest challenge is staying focused - It's good to have a few such people on your team (to help guide big technical decisions and encourage good practices - They are great supporting roles) but in terms of raw productivity, you'd get more out of a less talented/experienced engineer who feels more challenged by the work.
In my opinion, engineering talent is based on three things:
- The range of projects that the engineer has worked on during his/her career.
- The total number of hours spent coding in their career.
- Their attitude towards learning.
I think this 'innate' 10x developer idea is just bullcrap.
The best way to identify a great engineer is to check how many years of experience they have, how many companies they have worked for (more variety is better) and their attitude to learning. If a developer says "I like to be challenged by my work" - That's generally a good sign that they enjoy learning; combine this with their total years and range of experiences and you can infer how much they know today.
> I don't know of many other professions that have 8 hour oral exams that test the sum of all knowledge in the field with such a strong negative bias towards hiring.
Investment banking, management consulting, doctors, lawyers (probably) ... - seems like the traditional 'power jobs'
I asked my law school friends what their internship interviews were like and they aren't asked any technical questions about law. They just walk through your resume and ask you behavioral-type questions.
The interesting thing is that Google found that behavioral interviews better predict employee performance. I'm not sure why they didn't change their interviews after that internal study..
Because the people giving the interviewers were hired under the old system. Which they can't just turn on its head, all of the sudden, because that would... invalidate the exacting, methodical "high bar" which they had to pass in order to be hired (though proving their Great Developer status).
That is how they hire business majors, not engineers. High end business major job interviews usually has a ton of questions like "why are manhole covers round?", and google realized that such questions where worthless.
The technical interviews are totally different and are used because they actually work well, but you can't do something similar with business skills.
No, but there are many other places where they talk specifically about non-tech roles and I have never seen him comment on technical interviews. Example of article talking about non-tech roles:
Investment Banking interviews for entry level positions have usually very few technical questions (if at all). There's sometimes a standardized test (e.g. logical reasoning) before the main round of interviews. The interviews themselves are just behavioral.
This is factually false, unless there's some 'entry level' below analyst, and if you're excluding the bulge brackets (and oh man the boutiques) from consideration.
From my experience that is factually true (London). I know this for entry level positions and internships (that can often lead to an offer), i.e. candidates with no work experience. I know that this is the case for at least 3 large investment banks.
The situation is of course different for boutique firms, I should've said that. Small firms cannot afford training candidates internally, they'll want to have technical knowledge.
"I don't know of many other professions that have 8 hour oral exams that test the sum of all knowledge in the field with such a strong negative bias towards hiring. Or a profession that so strongly assumes ability is innate and cannot be trained."
I'm not following you here. I guess you are referring to a high selection bias for CS knowledge? How does that relate to Joel Spolsky?
Yep I'm a fan of Spolsky in general, but the idea he supported that you must be extremely skeptical, cannot trust anyone to be a good developer, and that a bad hire can destroy a company has done untold damage to the industry.
Though I'm a much better dev now than when I started in the 90's I had my choice of jobs back then. Now it is horrible death march for the privilege of slinging HTTP APIs, about the easiest thing a developer will ever face professionally.
It's the reason why developer interviews are such a shit show, and
a factor in the "engineer shortage." People who can't code with a gun to their head (ala swordfish) are excluded.
Not to mention those that don't "fit", such as minorities, women, and elders.
The author thinks that Joel is contradicting himself (since how can it be both easy and hard to tell if a developer is great?), but I don't think so.
In fact, it's hard to tell for sure how good a developer is before hiring, but easy after having worked with them for a while. This is similar to how it's hard (as in, expensive) to be sure if a car is a lemon before buying it but easy to tell after putting 10,000 miles on it. No contradiction.
Unrelatedly I agree anecdotally that from a developer point of view the market for workplaces looks more like a market for lemons (it's hard to tell if a workplace is crazy before joining it, easy afterwards, and a developer will stay a lot longer at a nice workplace than a crazy one, so most job openings are probably for places that have a high turnover for a _reason_).
Not necessarily. Many job openings will be for new positions in workplaces that are expanding. And if the best developers move more frequently between jobs, the workplaces with the best developers will have the highest turnover rates.
> Just for example, there’s someone
> I’ve worked with, let’s call him
> Joe, who’s saved two different projects
> by doing the grunt work necessary to
> keep the project from totally imploding.
> The projects were both declared successes,
> promotions went out, they did a big PR
> blitz which involves seeding articles
> in all the usual suspects, like Wired,
> and so on and so forth. That’s worked out
> great for the people who are good at
> taking credit for things, but it hasn’t
> worked out so well for Joe.
I have to agree with this, since many of the better engineers I have worked with frequently interview. Generally, they run out of opportunities at their current employment and need to find something new for them to grow. Also it's often easier for them to get a pay-rise with a new job.
However, I wouldn't say that there is a "market for lemons" for employees. Performance may well be difficult to evaluate during an interview process, but after several months of work within a company it is generally quite clear who is performing well.
I think the real issue is that:
- Employment opportunities are a "market for lemons", and even if a team or project is great to work within at first, it won't stay like this forever.
- If a company spots a great performer they generally don't wish to offer them preferential treatment (more autonomy, ability to learn something new, pay rises, etc) due to its perceived effects on their peers.
There are all sorts of lazy heuristics that people use, and "good people are never out of work" is one of them. Good people do sometimes go out of work, but it will generally be to "scratch an intellectual itch" or to give themselves time to be extremely picky about their next job.
I think the way forwards is to create more supportive development cultures which allow for more room at the top (with opportunities for self-direction and with pay improving alongside efficacy) and at the bottom (with mentoring and training). This isn't just something that might be solved by a great manager. It's also something that we I think we should hold ourselves accountable for.
> Moishe Lettvin has a talk I really like, where he talks about a time when he was on a hiring committee and they rejected every candidate that came up, only to find that the “candidates” were actually anonymized versions of their own interviews!
I worry about this a lot when I'm interviewing candidates.
The whole 10x great developer seems to be an attempt to build an elaborate mythology to con immature and young workers to work themselves to death trying to prove something that is vague, extremely subjective, illdefined and thus unattainble.
Let's spice it up with 10x HR people, 10X CXO's and 10X VPs and hell while we are at it why not throw in the 10x Barista to get Starbucks HR fired up.
Here is a better idea, forget the 10x developer. Show us the 10x code.
The famous 10x developers seem pretty easy to find. Carmack, Torvalds, etc. I don't know what "10x" code means, but you could certainly look to codebases from those two to learn. Similiarly with CEOs, with people like Musk or Jobs. Even in fields like writing you have outliers like Asimov or King. Even with your joke example of HR, while I can't think of any examples, you can imagine an HR manager that improves culture and hiring so much the effect is enormous. I don't know if people should bet their careers on becoming an outlier, and there aren't a ton, but these people exist.
By definition exceptional people are difficult to find or they would not be exceptional. Everyone is not a Torvalds or Carmack.
That recognition has come after decades of exceptional work and experience, not by solving test questions in an interview process.
How are you going to find Torvalds or Carmack in an interview process before they have had the opportunity to do all the decades of work and gain the recognition?
This 10x fantasy needs to stop or let's see some 10x code.
Anyone seeking a 10x engineer needs to ask themselves whether they can afford them and if the work on offer is exceptional enough to require that level of talent.
I guess I don't get what you're saying. It seems like your argument is that exceptional people are hard to find so we should give up trying? What on earth is 10x code, or the 10x fantasy? I already gave you easy examples of people that are probably 100x more productive than average in terms of impact, so it's not like someone 10x better than average is a unicorn. I'm not trying to be rude, but "10x code not 10x developers" sounds like a delusional platitude you'd hear from a faux populist politician or something. It means practically nothing.
It's very clear to me what the parent is saying. The people you give as example only got that recognition long after doing the work that established their career. In an interview process at the start of their careers this work had not been done and their talent could hardly have been recognized in an interview process. Actually, after reading Masters of Doom I am pretty sure that a 20 year old Carmack or Romero would not get hired at any company in the entire state of California that has an HR team. This due to personality traits, lacking educational pedigree and poor work history.
So this 10x bullshit you're talking about is about people being leaders. Higher up the ladder you are your power to increase productivity or hamper is multiplied.
Comparing impact of regular line developer with leader is comparing apples to oranges.
Becoming leader is a different thing - not everybody wants to or have what it takes to do it.
10x code is the code you didn't write because you knew how to solve a problem simply (usually by knowing about the existence of available tools and approaches, instead of building things from scratch),
Is 10X solely about quantity? I like Asimov, but his stuff is pretty simple. On the other hand, Tolkien didn't write a lot, but it's a lot deeper. Was Tolkien not 10X? Then again, what do you need? CRUD apps probably want an Asimov, but a site that needs high reliability or high scale probably wants a Tolkien.
I'll post to this thread to simplify a lot of our discussion, tptacek also has good insight here. Listen to him as well.
Hunter and Schmidt did a meta-study of 85 years of research on hiring criteria. [1] There are three attributes you need to select for to identify performing employees in intellectual fields.
- General mental ability (Are they generally smart)
Use WAIS or if there are artifacts of GMA(Complex work they've done themselves) available use them as proxies.
Using IQ is effectively illegal[2] in the US, so you'll have to find a test that acts as a good proxy.
- Work sample test. NOT HAZING! As close as possible to the actual work they'd be doing. Try to make it apples-to-apples comparison across candidates. Also, try and make accomidations for candidates not knowing your company shibboleth.
- Integrity. The first two won't matter if you hire dishonest people or politicians.
There are existing tests available for this, you can purchase for < $50 per use.
This alone will get you > 65% hit rate [1], and can be done inside of three hours.
There's no need for day long (or multi-day) gladiator style gauntlets. Apply this process to EVERYONE, including that elite cool kid. You don't want to exclude part of your sample population!
[2] Technically IQ tests aren't "illegal", but the bar courts have decided companies have to climb is so high it effectively means they are. I have spoken to a lawyer about this. You should speak with yours too, before you decide to try IQ testing.
Degrees and GPA are primarily a proxy for social status. You have to start by giving some thought to what your screens aren't telling you. A bad screen that rejects 90% of qualified candidates can easily look like a great screen so long as it's not passing through obvious bozos. That's the problem with screens! It's easy to reject most bozos, but hard to let through most solid candidates.
And of course Google and Facebook and the like don't really have a problem with rejecting 90% of qualified candidates, because "everyone" wants to work there and they have no shortage of qualified applicants. On the other hand, everyone that is imitating them has a rather big problem, because most potential candidates haven't even heard of their company.
If there are plenty of candidates applying that have degrees from accredited institutions, then they are SOL. It gets interesting when there aren't enough qualified candidates.
Wasn't my intention. I should have qualified qualified:
> between "qualified" candidates
I'm presenting from the point of view of the hiring institution. But still... If I were a law firm, I wouldn't hire a lawyer who hadn't gone to law school. Why would we behave differently with software engineers?
Largely because a lawyer who hasn't gone to law school won't be able to practice in most places, due to their guild preventing them.
That same guild has coordinated a test & accreditation process that largely spans their industry.
Whether or not this process has led to better lawyers or legal procedures is an open question, but the software industry has no such standardization, testing, or work embargo, so they are largely not comparable.
> Joel’s model assumes that “great” developers are sticky – that they stay at each job for a long time.
The author is missing a fundamental piece here. It's NOT that the "great" developers will stay at the same job for a long time or that the company is great at recognizing them. It's that their friends, colleagues, etc will recognize them and bring them along.
When you take a new job (at any level) at a company you like doing what you like, you will want to work with great people. Some will already be there but most likely you'll have the opportunity to refer people in.. and you'll go back to the people who you already know are "great" by whatever understanding you have.
If you make a compelling offer hitting the right points - money, flexibility, opportunity, etc, etc - then you'll get the person even though they were never "on the market" in the traditional sense and almost definitely didn't have to send a resume and "apply" in the normal sense of the word.
The premise of network hiring is that when one member of a strong team leaves, they'll bring the best of the team with them. Hiring managers seem to appreciate the aspect of this that means they can bring multiple good people on at once, without appreciating the obvious implication staring them in the face: when one of those people leaves THEIR team, they're going to strip a big chunk of the team out with them.
Network hiring creates brittle cultures. It's probably the most popular "alternative" to conventional hiring pipelines, and it's just as bad!
Networking hiring works great if your company is good and you treat your people well. On the flip side, if your culture is to burn people until they exit, you'll find one person quitting and taking six along with them... and it won't be the worst performers.
Funfact: We're in a thread talking about how terrible companies are at assessing candidates... and you say that companies have special tracks for elites candidates, even though they are not able to identify elites candidates in the first place. :D
"If you hire someone with a trendy background who’s good at traditional coding interviews and they don’t work out, who could blame you? And no one’s going to notice all the people you missed out on."
How is it that fear of false positives keeps coming up again and again in discussions of hiring practices?
Considering at-will employment (is that the correct term?) is the default here, you'd think it wouldn't be that big of a problem to get rid of an underperforming employee. I guess it's more of a cultural/social issue but I can't pretend to fully understand it.
People are not fungible, and depending on internal politics and procedures hiring probably only happens reactively instead of proactively. If you have to fire an under-performer, you're now short-staffed even worse until you can get another job posting approved and someone hired for it.
Lost productivity from being too picky is less visible than lost productivity from telling someone to go home.
Management is often seen as a career progression from non-management. This means a lot of managers - and especially the newer and therefore lower-level ones - are still figuring out wtf they're doing and aren't (yet) very good at it.
Yes, I understand that but obviously there's a trade-off here, the point being that by avoiding firing people at all costs you're missing out on some great developers.
Like I said, it's a cultural/social issue disproportionally tilting the cost effectiveness scale.
Firing someone isn't he problem. The sunk costs of bringing that person onboard, and the new costs of doing the same for a new hire, are the real killers.
There is a philosophical view that optimizing onboarding is equally (or more) important when compared to recruiting processes. A common blocker here is that onboarding isn't done by HR.
The only rational solution is to hire two people for every open position. I do that when I hire contractors. I think the same would work well for employees - for the same reasons.
> 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. Joel also posits that companies can recognize prospective “great” developers easily.
That's not what Joel's post said. Joel said that great developers don't apply for jobs much. A great developer could have as many jobs as an unqualified one, but they rarely, if ever, need to apply to places to be offered a job there. Think of any great dev - do you think they'd send their resume someplace? No, they'd just leave, another company would get wind of it and they'd be offered a job in a heartbeat.
It seems like that "great developers never apply for jobs" is taken as an axiom on HN, but it's implicitly assumed that every developer works in an area with a zillion of companies to choose from, has an extensive network of friends in all those companies etc.
Bay Area or London might definitely be like this, but there are many cases where this simply does not work like that:
- a geographical area with one strong, dominating company -> low employee mobility (not much choice), hence low inter-networking
- people who move to a new country/city and know no one there (or people whose friends tend leave to other countries, hence the networks are not that useful either)
There are only a handful of developer hubs in the world, many people work in other circumstances and might not have an extensive networks, which is neglected here.
I've known great developers that are terrible networkers.
They are able to get jobs through the resume/interview avenue when they want to leave but they still go through this channel. These developers are most likely to be underpaid. Real gems for those hiring.
It's hard to believe that really is a common thing, even for great developers. Any great developers here on HN want to speak up and tell us all how that went? If you've ever gotten a professional job without a single interview--no formal application, no phone screen, no on-site--just a job offer out of the blue sight unseen, based purely on your reputation, please reply here and tell us your story.
Not to mention that an extremely able developer will end up leading a company over time; switching to another company would almost always require having to climb the ladder again.
In a developer lemon market developers are hired at the lowest possible cost as their value can't be assessed in advance. Turning this thinking around in a employer lemon market employers are selected by offered salary as that is the only solid proof-able property that distinguishes them. Two strong diametrical forces are here in play focusing the discussion on salary to the detriment of considering the total package for both sides.
Lemon markets exist for one-time transactions between foreign parties. Public records of companies and potential employees change this to a degree. A big name company may be able to hire at lower cost as it is on record it is not a total disaster. A public record can help to put a floor under the salary one is being offered.
From a developer perspective one can
- market skills in a way to decrease hiring risk (affecting offered min salary)
- market skills that are truly needed (affecting considered max salary)
- research the company (allowing one to reduce demanded salary e.g. huge solid growth etc.)
As always the power in negotiation is with the party that can afford to say no.
"See? Joel Spolsky knows the secret to hiring Great Developers. Not only that, he knows how bad things can go when you hire the complement of the set of Great Developers, namely honkin' bad, can't-solve-a-brain-teaser about-pirates-and-blindfolds and-poisoned-bottles-and-buried-treasure to-save-their-life† Mediocre Developers. Therefore, you should buy consulting services and/or products from Fog Creek. Because you know Fog Creek only hires Great Developers."
Was the trojan horse message behind Joel's now-infamous Great Developers meme, which we are currently about midway through the second decade of. And that's really all people should have read it as -- part sincere opinion; but part pure and simple marketing shtick for Fog Creek.††
Yet it's taken on a life of it's own, as we know all too well by now -- with no endpoint in sight.
† Such brain teasers -- and the ability to solve them right there, on the spot, with strangers staring you, and your career hanging in the balance -- being, according to JS's unequivocal belief (until it finally became woefully unfashionable), if not absolutely necessary, at least fantastically useful and effective in telling Great Developers from Mediocre Ones.
†† A great, or at least an okay company, by all accounts (aside from this single, unintentedly onerous piece of marketing shtick from the early 2000s).
As a college student looking for a job, a lot of this is quite worrying. I don't really know where to start as a junior developer and I have seen quite a bit of this mentality that "we are looking for the best". Does anyone know how, from our corner, filter out companies that will do crazy stuff like make you barf up 30 sort algorithms?
And more importantly for my case, does anyone know where to look for companies that are willing to work around a college student's schedule?
The cards seem to be stacked against us in this one.
Its a candidate's markets. A few companies can afford to only hire top notch candidates. You've heard of them, and that's why. If you only try to apply for places you've heard of as being the best of the best, well, it will be harder because everyone is doing the same.
There's hundreds, thousands of companies who aren't the best, and aren't looking for the best either. Work there, get your experience up, jump around every few years (so you can eventually get a feel as to WHY those companies aren't the best), and you'll be good enough to go anywhere you want.
Or you can try to play the SV game, learn the 30 sort algorithms and learn how to speak "Big SaaS Company" speak right after college and skip that.
I personally wasn't good enough for that out of college, so I did it the hard way, and now I'm where I wanted to be all along. It took 10 years, but ::shrugs::, I made it.
True story... I've seen a lot of small places that are so desperate because noone wants to work for an insurance company or some other industry that needs software but isn't a "software industry"
A lot of the time they are desperate because the code is so bad they can't get anyone with half a brain willing to put up with it. And they don't have the corporate culture willing to fix it.
> Does anyone know how, from our corner, filter out companies that will do crazy stuff like make you barf up 30 sort algorithms?
There's no reliable way. You just apply to some more jobs, and some of the companies will be the crazy kind, other's won't.
> And more importantly for my case, does anyone know where to look for companies that are willing to work around a college student's schedule?
Look for medium to large companies, those often have some things they want done, but aren't really urgent.
I work for an ISP and IT outsourcing company, and we have low-priority projects like updating the internally used blog to a newer wordpress version, install some plugins to get some extra functionality, write a bit of customization code and themes. These are things where we're glad when we can offload them to a part-time developer, and we don't care up if they show up in the morning or in the afternoon.
> The cards seem to be stacked against us in this one.
Don't give up. If you can get some personal connections, finding a job won't be too hard. Go to some local meetups, like your local python/perl/ruby/java/.NET/whatever monthly gathering, and see if you can get talking to some folks. Going to meetups in your free time already puts you in the upper 10% in the perception of most people :-)
> Does anyone know how, from our corner, filter out companies that will do crazy stuff like make you barf up 30 sort algorithms?
All "good" tech companies. All the startups, no matter whether they are early stage or already raised 100M. All the big established tech companies (Google, Microsoft...).
To put it bluntly. ALL the cool places you know and want to work for. They are out of your league :D
If you want to start elsewhere. Look for old school NON tech companies. Things like insurance-health-government-defense. They've got real work to do, sometimes more interesting than the Google-Facebook-Mhatever. But they don't have the culture and they have easy interviews.
Don't worry so much about the "we're looking for the best" - as the author of this article points out, it's just an ego trip on the part of the interviewers. Everybody wants to think they're the top 10% but the truth is, half of all software developers are below average. Most interviewers (and candidates) don't really know what they are looking for or where they will fit in, so the process is pretty random. Just cover your bases (i.e. study for your interviews, have a referenceable public body of work, and work on your people skills) and interview a lot, you'll be fine.
Remember that the reason all of these blog posts you're reading exists is because the authors are growing their referenceable public body of work to the same end, not necessarily because they're trying to help you.
>As a college student looking for a job, a lot of this is quite worrying. I don't really know where to start as a junior developer and I have seen quite a bit of this mentality that "we are looking for the best". Does anyone know how, from our corner, filter out companies that will do crazy stuff like make you barf up 30 sort algorithms?
Don't sell yourself short. As a fresh college graduate, you have a totally clean slate. All companies, even the big 4, will give you a fair evaluation (or, at least in theory, try to) based on what you've been devoting your full time to studying for the last four years. I assure you that it becomes much, much harder to study anything or do much alter your career trajectory once you start working full time.
Yes, you can find companies with easy interviews but, as user5994461 and others have pointed out, they tend to be somewhat mediocre, to put it charitably, in environment and pay. Do you really want to deliberately aim for mediocrity before your career has even started?
If those are important concerns for you, just ask about their hiring / scheduling policies up front, before you invest too much time into them.
But also, try a few technical interviews. You might find they're not so bad, if you have the right background. I've been on both sides of the table in technical interviews, and on the hiring side I was working with an ex-Googler and our process was heavily influenced by Google practices. All the interviews I've done, on both sides, have been concerned with technical communication and the ability to develop a workable solution with a few hints, not with regurgitation of specific algorithms.
Joel's point is not neccasarily about "stickiness", just the need to apply. Great developers form a network of people who know them. When they want to switch jobs, they typically don't go " open on the market" and rather talk to a friend in a specific place, do an interview for formalities sake, and get hired. There was no "applying" or sending a resume to a hiring manager. Also, often companies go to them, not the other way around. Joel's point is that great developers don't need to put themselves on market at all in order to get a job.
Insofar as the generalization "Engineers like to gossip" goes, the difference is they gossip about problems, not their resume-bullet-point-achievements.
Plus, much of that gossip is going to be with co-workers, which doesn't do you as much good when it comes to finding a job with people at another company company.
> Plus, much of that gossip is going to be with co-workers, which doesn't do you as much good when it comes to finding a job with people at another company company.
Of course it does, because people don't work at the same company forever.
By far the biggest contributors to my network are former co-workers.
> No I haven't, but there's no need to be rude about it.
I didn't intend to be rude, though I did intend to be snippy.
> More importantly, I'm obviously talking about the average. On average, developers will change jobs every few years.
First off, I didn't think it was obvious you were talking about the average. Generally when I see comments like that they are presented as some sort of near-universal truth (which is why I reacted the way I did).
Second, I don't agree that developers change jobs every few years on average. I only think that is true of a subset of developers that are overrepresented on HN. My entire career so far has been in Dallas, and non-contract developers who turn over jobs that fast are not typical here.
> First off, I didn't think it was obvious you were talking about the average.
I certainly don't think it's universal. After all, I too know some people who have stayed in the same job for decades.
A useful principle for reading HN is the principal of charity.
> Second, I don't agree that developers change jobs every few years on average.
I couldn't find any hard numbers, but recruiters and HR people do tend to agree that the tech sector has a shorter average tenure. You're definitely right that this is more pronounced in the hubs though.
Last company I was at in France, the average stay was 6-7 years.
It's a decent company, nothing particularly great or notable.
The numbers are similar for other regional companies from what I've heard of. It's higher for a few big old companies (usually in embedded, defence or aerospace).
We can assume that the stays are way shorter in SV/NY/London but please keep in mind that they are not representative of the rest of the world.
Maybe something is wrong with me but I'm an engineer and I don't gossip, nor do I know other engineers who gossip. Managers gossip. Testers gossip. Designers sometimes gossip. But in my experience developers not so much.
"Great" developers may be that rare. But most coding jobs don't need "Great". Most coding jobs are CRUD apps with some business logic. Toss in some UX for flavor. "Good enough" will do just fine in most jobs.
This is my personal pet peeve. I've often applied for jobs at well known tech companies who's technology is fairly simple (one company was a plain mid-sized CRUD Rails app, another was three PhoneGap JS-frontend-heavy mobile apps + JSON API backend, fairly mundane things like that)
And yet they still interview you like they're pretending to be SpaceX or NASA or something. 5+ hours of programming brainteasers (which they swear are just 'simple programming exercises' that 'are just to give insight into process' -- but are actually brainteasers, and you are actually expected to solve on site).
Which makes the inevitable "we like you, but have to pass on you for technical merit" rejection sting pretty badly -- I have the technical capability to handle these jobs, because I already do this same work every day. But I get told my technical knowledge isn't strong enough to work on their apps, because of stumbling on some of the latest trick questions.
And then, their managers write a blog post on Medium and complain about the lack of tech talent, or how they are inundated with fake applicants who "can't code FizzBuzz"
sigh
Technical hiring is just totally screwed up, and no one seems remotely interested in fixing it.
One of the mottos painted on the company wall was "We don't want people here just for the money." The CEO put it up because they couldn't pay a competitive rate. The hiring manager insisted they paid well. A bunch of devs left claiming they were paid near the lower end. For example, one dev received only a $1k pay increase when she was promoted from SDE1 to SDE2.
How can perception be so different between CEO, managers, and developers?
> How can perception be so different between CEO, managers, and developers?
It's not perception, it's marketing.
The interviewer cannot tell: "We pay under market. If you go interview at almost any other company in town, you'll 20% more easily". People would just not work there.
What happens instead is, they either lie straight to their face or oversell the "culture".
In your example. The CEO going for "people don't work for the money" is classic bullshit meaning they have low wages but it's a good place (even though it is not). The manager saying they "pay well" is a straight lie.
People will believe it most of the time. They can keep employees around for a while. They do what they are supposed to do: Run the company, whatever it takes.
Because software guys just write software. They don't do anything else... until it blows up and your company loses that big client worth 100k/yr then writing software is a priority.
What it is that makes a developer great? They are expert at one technology? Multiple technologies? Fast learners? Problem solvers? Not rockstars but great team players?
I would argue that a lot of (if not most) companies won't even know how to gauge long-time greatness.
I've been working my way diligently through this very interesting and pertinent thread. But you're the first, I think, to mention this elephant in the room - we really have poor gauges for greatness in this profession. And here's one reason. In many professions - doctors, lawyers, accountants, stock brokers - you can measure success. Do most patients get better, did you win the case, did you beat an audit, did you make money.
I tell my students that if they want to do something where they can be gauged as individuals that they should not go into engineering unless you plan on also getting an MBA and working for a big, stable company with a long track record of nurturing talent.
I strongly disagree with that. Best developers switch many jobs - that's how they become great - by working on lots of different stuff and learning all the time - there are very few full time positions where you can continuously learn and actually do new things all the time and don't become a nuisance for your co-workers. They also start their own startups, fail, and go to job market again.
One thing I didn't see mentioned. What if the team simply lacks interesting work? If the team stamps out CRUD websites and the manager has somehow become convinced that the team needs "great" developers, he or she will have trouble hiring even if the pay is competitive.
Compensate with pay, and "boring" means paying more than "competitive." If it's just cranking stuff out like an assembly line, then maybe the developers should receive a commission structure.
Seems reasonable, but does anyone actually think like this? "Okay, we do fairly boring stuff here, so we must compensate with pay to attract good developers". Rather, the opposite rhetoric is prevalent: "Groundbreaking! Disruptive! We need passionate developers! Prepare to take a pay cut in exchange for a chance of changing the world."
If it's interesting then you will see a lot more people applying. If you find adequate developers you generally pick the cheapest one. Therefore more interesting work has a lower compensation relative to how much value you create for the company.
Where is the race equation in Joel's claim? I am a black and a great developer. Many years ago, I worked in one of the top five tech companies in North America. My second line manger called me 'a Slave' because I was working harder than my team and contributing across team. I complained about the incident, and left the company after there were no action from the top management.
I think the most important point here is that no place with more than a handful of employees will be perfect for everyone they hire, and the bigger the place, the bigger the internal environmental differences. I've worked at places where there was an awesome manager building a wonderful culture underneath, while another large team nearby had terrible management, considered very substandard people to be their very best, and was a nightmare to work for (and with). My idea of good people loved one team, and quit quickly when working on the other. The manager in charge of both managers never thought there was a difference, and thought both managers were great.
Managing one team is hard. Setting up an environment that is great for a diverse set of people (whether we are measuring that by race and gender of just by people with different values and ways of thinking) is even harder. Many people in those positions don't spend anywhere near enough time trying to make sure they are building the right thing and instead copy each other, leading to what Dan describes.
None of this will change until we make breakthroughs into people management, something that, sadly, only the largest companies have resources to really look at, and the largest companies are often the most dysfunctional.
> Moishe Lettvin has a talk I really like, where he talks about a time when he was on a hiring committee and they rejected every candidate that came up, only to find that the “candidates” were actually anonymized versions of their own interviews!
Steve Yegge I think has a similar post but from a different angle and he calls this problem the interview anti-loop. Depending on who ends up on your interview panel you might get high or low marks across the board and it won't be in any way correlated to your actual abilities.
Making good teams like Dan says is a hard problem mostly because recruiting is a hard problem and letting anyone other than the team handle the process is why things are broken. If you want to work with great people then you personally have to be actively involved in recruiting great people by going to conferences, going to meetups, writing blog posts like this one, etc. But that sounds very time consuming and most companies don't think recruiting is actually an engineer's job so they never properly budget for it in terms of training and other resources.
Management often believes that they understand hiring, and that their mechanisms for examining performance are good. If Joel believes that one of his employees is fantastic their requests will be heard, and they will be better compensated. Dan instead is seeing developers that he knows are awesome and can't find work because Dan can't hire them.
I for one think both are right in some fashion. People that management considers high performers stay long and are very well compensated. People who are not valued that way by management might still stay (if they are not valued in the market), but will jump ship after a few months otherwise. Willingness to stay depends on getting what you want out of a job REGARDLESS OF PROGRAMMER QUALITY!
I have worked at places where people with tremendous flaws were considered high performers, making the place shed great developers while keeping bad ones. Other places just look at a specific set of things that might make someone good, and end up with unbalanced talent sets. Imagine you hand tasks to single developers, and value getting them in production as soon as possible. Stability, readability, maintainability will go down the window, and eventually said company will either fail or have to hire a different kind of dev, and force those people to win a culture battle.
So ultimately, I think this is all about how difficult it is to evaluate programmers, and how people with one evaluation function look at a world that either shares their evaluation function, or differs significantly from it.
While the developer might not be happy per say, the amount of crap that you now have to go through in the interviewing process makes staying the least worse option on the table.
Interviewing of late is filled with randomness. One place I interviewed, the Recruiter told me to expect coding exercise. The call starts, and I am handed out a system design problem ! Never expected a positive outcome since I hadn't prepared. Randomly, I got selected for the next round. This time around I prepared for anything come what may. The call starts, I get asked a coding question. I solve it in about 20 minutes, and the remaining 25 minutes we have a good discussion about the company dev practices. Randomly, this time I am not selected !
Another company I interviewed with last year but didn't make it but kept in touch with the recruiter for re-applying after a 12 month cool-off period. Come the time to re-apply, the good recruiter left and now the current ones keep politely refusing my application.
Another interesting one wanted me to record a video of mine explaining what I know about the company and why I would be a good fit and send that video to them ! (this one is a mixed bag, I kinda liked the idea but didn't bother eventually)
Another one had me fly out internationaly-all-expenses-paid after three Skype rounds,on the day of flying back I left a courtesy email to the recruiter thanking for the opportunity to interview and asking about possible turn-around time for a feedback. Haven't heard back !
Overall I have begun to get the feeling that at I particularly am a Lemon (or atleast the Potato no one is buying).
No, you're not necessarily a lemon. It is true that the hiring process is a complete random mess. Companies and candidates would probably be better off if we all admitted from the start that it's a random lottery, and that you're being chosen among the hundreds of other candidates essentially at random out of a hat.
The biggest issue with this is that some developers tend to get 2-3 offers in a small period. It's totally normal for a developer to start and leave within 3-4 days because a better offer came along so these companies want enough time to see if their new hires are going to duck out before telling you you're not a match (just in case you are a match but the guy who just got hired in your place quit because the new place offer 5k more)
The two stances aren't exclusive. Good developers may become unhappy, but they likely have very little difficulty finding a new job so they are on the market for a very short period of time.
To follow the used car analogy, good cars do occasionally need to be sold, but when they do they get taken quickly by a friend or through word of mouth recommendations. The cars that sit on the lot for the public to peruse are not great deals.
If it’s so easy to identify prospective “great” developers, why not try to recruit them?
Because they are not on the market, and they're very picky as to where and most importantly, with whom they will work. Does someone out there honestly believe that a guy like Keith Wesolowski, Dan Price, Jerry Jelinek, or Jeff Bonwick will just shop themselves on the open market? If so, it's time to do some extensive research on the subject, because nothing could be further from the truth.
Steve Jobs once put it like so: A players hire A players; B players hire C players; and C players hire D players. It doesn't take long to get to Z players. This trickle-down effect causes bozo explosions in companies.
And boy was he right; I've seen good companies and good, interesting jobs go down the toilet so fast, my head is still spinning from it all, years later.
I know how that is first hand: I don't shop myself around on the open market, people call me, and by people I mean people I have closely worked with in the past, people which I know exactly what they're capable of, what they know, what they don't know, and if I accept, the whole interview process is nothing but an empty formality. It's truly eye opening just how much of a sham-theater the entire inteview games are. The key takeaway is, if you're good, you'll have a renomee, and you're unlikely to be on the open market - you come to people and people come to you. You get the job long before any would be competitors have even had a chance to apply ("we must satisfy human resources policies"). Dan Luu's question is, by experience, an unlikely occurrence in this particular industry.
I liked the article but I wish this guy spent a little more time making the articles readable. Wall to wall text at a small size is sort of hard to read.
Based on 20 years of participation in software development forums like this one, I'm pretty sure that 99% of developers definition of "great developer" is "is me".
For me everything boils down to: as an engineer, how well aware are you of your domain. If you are, then you know how to integrate tools and code together to produce the next invention. I've written a post for engineers on precisely that topic just last week:
https://my.caura.co/why-build-software-in-house-not-f3c9bc72...
My pool for drawing personal conclusions about hiring is not deep, but in my limited experience (both in hiring and being hired) there are two things that seem to matter above all others:
1) How personably the candidate is. Do you want to work with this person? Does he/she have basic social skills?
2) Do they have a coding-related passion project? It almost doesn't matter what it is, as long as they have one.
I am one of these Great Devs. Joel is correct that i will probably only apply to 4 jobs in my career. But the author is also correct and I am not sticky. I have switched jobs several times over the past 10 years. Companies will try to keep great people, but when you tell them you need a 40% raise, they will pass. I think Joel and the author understand this and actually agree.
The worst devs I've worked with are those that proclaimed themselves great. Some could sling code well, others were hopeless but they all were toxic for the team.
And yet, I've known more than a handful of developers who are really solid, great people to work with, and I'd like to work with again. None of them have ever blogged, podcasting, presented at conferences nor run a public repository on github. Yet by many definitions of 'great', they fit the bill, but not the sort of 'great' that would mean companies would just 'know' of their greatness, and go out of their way to hire/recruit them.