[latch]

I agree it's ridiculous to get to be turned down for that reason at that point. If that was their attitude, they could at least be efficient about it for their own sake and out candidates.

But, in general, I think you should consider the other side of the argument. The "problem" is that people without public profiles are competing with people with. And if you're looking at candidates and someone has code online that looks promising after a brief examination, I think it's reasonable to take that into account.

It's not that the other person is lazy or "doesn't love the web".

[sidlls]

If "It's not that the other person is lazy or "doesn't love the web"." then why is it "reasonable to take that into account?" Those two sentiments seem to contradict each other.

The real problem here is that there is now yet another terrible signal being used as a measure of acceptability in the vetting and interview process.

"Have some GitHub/GitLab/etc profiles" is in the same category as "give the most personable person in the office promotions and raises".

[gregmac]

> "Have some GitHub/GitLab/etc profiles" is in the same category as "give the most personable person in the office promotions and raises".

Sorry, it's not at all in the same category, because it's actual output of work. Being able to look at actual code written by the person you're considering hiring is a really great measure of acceptability.

I think we are all agreeing that it's not reasonable to reject someone due to lack of published code. Latch is trying to point out the reality of the situation:

> The "problem" is that people without public profiles are competing with people with.

If you are considering two candidates, who seem more or less equal on every level, but one has an extensive amount of published good quality code and the other does not, it's less risk to hire the one with code.

It's very hard to judge someone's work quality based on personality. I've hired people who seemed good when talking to them but turned out to be not very great developers. I've also hired people who seemed questionable when talking to them, but had decent code samples and/or published code and also turned out to be good or great developers.

I guess to be fair I've never hired anyone who seemed like they'd make a poor developer, had no code samples to prove otherwise, and did badly on coding tests, so maybe I'm missing some great developers who aren't very personable or good under pressure. Frankly I'm okay with that, because I am absolutely positive most of the people in that category are in fact poor developers.

[sidlls]

> Sorry, it's not at all in the same category, because it's actual output of work. Being able to look at actual code written by the person you're considering hiring is a really great measure of noacceptability.

Unless you have a way to verify the source of the code is the candidate with some level of confidence this isn't different from picking the office peacock for promotion.

> If you are considering two candidates, who seem more or less equal on every level, but one has an extensive amount of published good quality code and the other does not, it's less risk to hire the one with code.

How is it less risk, assuming one came to the "equal on every level" decision by some means that evaluates their proficiency reasonably well? The only thing having self-published code signals is a willingness and desire to have one's code public. I haven't seen an actual argument justifying your assertion regarding risk.

[gregmac]

> Unless you have a way to verify the source of the code is the candidate with some level of confidence this isn't different from picking the office peacock for promotion.

This is why I specifically said 'less risk' rather than saying something like 'would 100% be a great hire'. You have to vet everything a candidate says and shows you, including their credentials and past experience. Some people lie on their resumes, unfortunately.

In the worst case, they are a good enough liar to get through the hiring process and you find out later they can't write code or don't actually know the things they said they know, so you fire them (and hopefully you figure this out during a probationary period).

> The only thing having self-published code signals is a willingness and desire to have one's code public.

I was conflating 'public' with 'available to be seen by the interviewer' in my argument, but it doesn't change what I'm trying to get across. Having code public has an advantage before the interview, when the employer only has the resumes to judge by. During the interview a candidate may also be able to show non-public code, but just being able to show any code gives an edge over no code.

Many, many, many people have no code show to show at all, generally because they wrote it for their previous employer. That's fine, but it puts them at a disadvantage over someone who can show code they wrote (public or not).

It's less risk because it's easier to judge someone by code than no code. I don't know why that isn't obvious. Let me put it this way: if you ask 10 programmers what "good" code is, you'll get 10 overlapping but distinct answers, and I think most programmers applying for a job are going to claim their code is 'good'. The trick is really figuring out if your definition of 'good' overlaps enough with my definition of 'good' that we can work together. We could discuss this for an hour or two and I could be 75% certain, or I could look at your code for 5-10 minutes and be 90+% certain.

[softawre]

Is it less risk to hire the open source guy? What if he spent a bunch of time at his last employer working on un-sanctioned projects? Will he do that to you as well?

Just playing devil's advocate.

[evilduck]

I don't think it's reasonable at all unless you equally weigh other sources of evaluating coding ability. IMO it's the same as assuming all managerial applicants also have volunteer charity experience as a manager that they can document and show. Very few careers hinge on what you do in your spare time as long as that spare time isn't spent being a criminal.

edit: hell, it's also already a norm that you have to perform a pro-bono coding assignment as part of the interview process. It's ridiculous to expect an extensive spare-time open source effort plus 2-10 hours of free work for an interview.

[randomdata]

> It's ridiculous to expect an extensive spare-time open source effort plus 2-10 hours of free work for an interview.

It's a bit of a misnomer to think that businesses expect (or require, as some put it). In reality, they can only weigh their options. Of course, the more options they have, the more particular they can be. It is not unreasonable to think that they had many suitable candidates, and the one who had the most visible evidence of past work became the preferred choice of the group.

Mentioning to the OP what helped cinched the deal for what candidate did get the job may have just been meant as a point of information. Of course, it's difficult to say what really happened without being an observer to the events that took place.

[yannickt]

It's one thing to prioritize a candidate with a public profile over one without when determining the order in which to interview candidates.

But to reject a candidate, after he's interviewed by the CEO (so this would presumably be the last interview stage), because he doesn't have "enough" public projects and therefore doesn't "love the web" enough? I think that's stupid.

Edit: misread the parent, we are actually saying the same thing.

[latch]

which is what I said.

[st3v3r]

That argument makes absolutely no sense. The candidate had made it to the point where they're being interviewed by the CEO. Any consideration of that has long since passed.