[AvenueIngres]

Here is my take on hiring: an active Git repository with a decent amount of non-trivial code/projects generally gets applicants I have to evaluate to skip the whiteboard interview and instead grab lunch or coffee with me. We then discuss technology/software engineering. I find this approach to have yielded much more conclusive results, though it probably would not "scale" well. You can quickly tell whether someone is passionate and resourceful by talking with them, occasionally erring on research-ish stuff but always focusing on the implementation rather than the theory.

Plus I sometimes stumble on the occasional gem that is very knowledgeable and from whom I can learn.

Whiteboard interviews, coding challenges, take-home projects. All of those things are so time-consuming for both the company, the interviewer and, of course, the applicant. And all of that just in the hope that the company will accept them... maybe? Of course when nothing else is available then it is the usual drill: phone, skype, on-site 1, on-site 2. But if other signals are available then to the trash it goes.

[mancerayder]

If you start with github repositories for your candidates, aren't you filtering out people who do things other than work? Most of us work 40 to 60 hours a week, and sign paperwork that says that any code we write belongs to the company. But now we need to work Saturday and Sunday on open source projects so we're worthy of sharing a coffee with a hiring manager?

[sqeaky]

> says that any code we write belongs to the company.

I have turned down several jobs when they tried to hit me with that clause. I have negotiated a better clause that gave them the work I made for them, which just happens to line up with state law here

> But now we need to work Saturday and Sunday on open source projects so we're worthy of sharing a coffee with a hiring manager?

I wouldn't want to hire someone who didn't enjoy coding enough that they didn't have something on publicly visible repo.

[AvenueIngres]

>I wouldn't want to hire someone who didn't enjoy coding enough that they didn't have something on publicly visible repo.

There is lots of reason why competent developers would not actively participate to OSS or have public repos. I think you are holding applicant to an unreasonable standard that does not entails they are bad if not upheld. I have worked with some extremely talented people - far more than I ever could be - who had 0 contributions, 0 repos and publicly available code.

Why? Because they valued the time spent with their family and friends more. They got the job done which is ultimately what I pay them for. Which is all that matter really. Are they competent? Do they get work done? Can they potentially take-up bigger engineering challenges (i.e can they grow). Yes? Welcome at X co.

[sqeaky]

I agree that it is possible to be great developer with no public code.

Unfortunately their competence is not directly important, my ability to assess their competence is. I have no reliable way to evaluate a person without public code. They could be the greatest or the worst coder without public visibility.

[mancerayder]

You could ask them to e-mail you a code sample or complete an exercise.

[lj3]

> I wouldn't want to hire someone who didn't enjoy coding enough that they didn't have something on publicly visible repo.

Why? Those people sound like terrible employees. Those are the people who come into work to punch the clock and get paid while saving their energy and creativity for their side projects, which is what they'd really rather be working on.

[jghn]

Most of my coding output for my job ends up on a public github repo, which is the best of both worlds.

[lj3]

That would be nice. Are you a library or framework developer?

[jghn]

I work for a nonprofit. The downside is the pay isn't as great as it could be elsewhere. The upside is that the work is meaningful and I get to write OSS as part of my day job.

[sqeaky]

I worded my comment poorly, I had double negatives, or something.

I would prefer to hire people with publicly visible code.

[lj3]

Your comment was worded fine. My point is that most code written for most companies is not publicly accessible. Therefore, most code that is publicly accessible was created as a side project in their spare time.

I don't know about you, but after working an 8-10 hour day, anything I make in my off hours is a steaming pile of shit. Certainly nothing I'd be showing to potential employers. Do you know who can make jewels after 8-10 hours of work? People who punch the clock, do the bare minimum and save their creative energies for their side projects after they get home. That's not somebody I would hire.

Another scenario is the person really is just a coding machine and does so 12+ hours a day. Those people burn out, eventually.

[mancerayder]

I wouldn't want to hire someone who didn't enjoy coding enough that they didn't have something on publicly visible repo.

Shudder. Sounds like one chooses to work for you, or have a healthy life that involves non-coding/computer hobbies and relationships.

Maybe it's a good filter for us in the opposite direction.

[hfsktr]

I don't mind coding but I hate the other tasks that come with it (hardware, networking things, loads of setup). When it's part of my job sure but if I am programming instead of doing something else. I have not thought of a project that I can get so motivated about that I am willing to give up the little time I get to myself to work for free (obviously I am not going to strike it rich with my cheesy side project).

Also 99.9% of the tasks I wish to do are solved so it's not like I'm going to make my life easier by solving the task. For the few that I find that I want I understand they require extraordinary resources/programming skill that I just don't possess.

[AvenueIngres]

I am not filtering anyone. I use the signals that are available to me and which I can proof-check. Candidates who don't have public software forges (whether it is self-hosted Git, Gitlab, Github, or Bitbucket etc.) go through the usual (tedious) interview cycle.

Those who have don't because that would be redundant and a waste of time. This is simple.

[throw_away_777]

You definitely are filtering people, unless you accept everyone who goes through the usual (tedious) interview process. This interview process is quite noisy, so being able to skip it gives a clear advantage. Whether or not this is a good thing is another question, but don't claim you aren't discriminating against people who don't code in their free time.

[AvenueIngres]

This is a hard problem to which there are no easy solutions, only trade-offs to be made. Here I think that I strike a reasonable middle-ground providing I act in good faith.

[lj3]

If this was an easy problem to solve, there wouldn't be a post on the HN front page about it every single week.

[bmj]

Question for you: is your judgement of the applicant affected by whether or not they have an active GitHub repo?

[AvenueIngres]

Do you mean does it matter what version controlling tool they use or if they self-host? or if I would favour a candidate over another because of an active Github repository?

[bmj]

The latter. Are you pre-judging a candidate because you can look at an open source repo instead of spending your day trudging through a tech interview?

[AvenueIngres]

Mmh possibly, there might be a slight bias favoring them. The shorter the recruitment lifecycle and the quicker I can go back work on actual software engineering.

But then again, I hire lots of software engineers who have 0 OSS contributions but a shit-ton of industry experience. It does not matter if your last contribution was 4 years ago by the way. I am not looking for a full green activity graph (though it demonstrates consistency and discipline which are good) but rather for non-trivial, significant and well-crafted pieces of software so I can rest easy.

I don't go in trying to shoot down candidates. That's what whiteboard interviews are for. (:

[Lich]

What do you consider to be non-trivial? Seems subjective. Exaggerating here, but obviously a git hub project that runs fusion reactor software is certainly non-trivial, but what about a small project that does/looks simple, but really takes a fair amount of effort to make it work? Like a triple AAA game is non-trivial compared to a breakout clone, but a breakout clone is still somewhat non-trivial (graphics, sound, "simulated" physics, GUI, gameplay logic etc.).

[jghn]

Do you just look at their own projects or their public activity in general? I have a lot of the latter but very little of the former and the stuff I do have in the former category isn't particularly flattering.