|
|
|
|
|
|
by sidlls
3416 days ago
|
|
|
> 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. |
|
|
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.