back

by sixhobbits·9y ago·view on hn ↗
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.

4 comments
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.

I agree with some of what you say, but:

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

> If an elite candidate balks [something personally negative about them]

It could also be that your interview process is bad and you should change it.

Perhaps the elite candidate is a canary in a coal mine, and fixing your interview would help your less privileged interviewees, too?

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

Nobody is arguing that candidates shouldn't be evaluating employers, too.
Exactly. The premise of the article is wrong.

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

In what city do you live?
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.