3 ms·

> While he has written a ton of code at his work in the last year, he hasn't posted anything that can be viewed publicly: he has no public commits, he hasn't cr

> While he has written a ton of code at his work in the last year, he hasn't posted anything that can be viewed publicly: he has no public commits, he hasn't created any repositories of his own and he has an insignificant number of followers. Despite all that he's still the best developer I've ever had the pleasure of working with. This is more a problem for the developer, not the company. The company may have a smaller pool of candidates by evaluating based on GitHub profiles, but they will have more data to use in their evaluation. If they don't have the resources to pay for the premium of being selective, they may evaluate candidates from a wider pool (those without GitHub profiles/history). The candidates without GitHub profiles will receive the attention from those companies not willing to pay a premium for their services. This can be generalized in other ways beyond GitHub. GitHub, in this sense, serves as a marketing tool, similar to LinkedIn, a personal site, a blog, a resume, etc. Provided it's a free marketing tool, the developer has little to lose by investing their time into marketing theirself and a lot to gain by receiving more demand.

bleah1000 6y ago
Have you ever been able to look at someone's code and immediately figure out whether it's good or not? I think it can be easy to see if it's really bad, but sometimes it can be hard to tell if it's okay code, or really good code. The problem is that you might have extra information to make a hiring decision, but it requires orders of magnitude more time to evaluate. For example, if the whole project is done by a single person do you evaluate their design and code? What if it was just a one-off project that they didn't care about so it has copy-paste code in a few places. Is that bad? If you ask candidates to point out examples of good code, then is that really meaningful? What if a mediocre programmer can find a few places where they wrote some strong code. What if that code was made good through a strong review process? I think the problem is that it's too difficult to determine if open source contributions are actually representative of the way someone will code in a job.
- hombre_fatal 6y ago
  I don't think the most useful info you can get from someone's Github involves the sort of deep analysis you're attacking in your comment. Nobody is deep diving your code like this, btw. Looking at someone's code projects can tell you some things like how they might write a README, if there is one. It might present a concrete project they built that you can discuss in an interview; what was the hardest part of this project? It can tell you where they are roughly on the scale of "barely started programming" and "clearly are experienced" (an experienced developer can glean this very quickly from someone else's code—even what they choose to paste from Stack Overflow—it isn't as hard as you think). Reading the code line by line looking for "strong code" is something that beginners think employers will be doing, but they don't. Just like developers don't evaluate libraries like this, they do a more topical, holistic page-through. Of course it isn't going to tell you exactly how someone will perform on the job. That's not the goal post (the absence of Github usually means you have nothing to look at at all). It just has a few useful signals like looking at a chair that a carpenter has built. It seems like you are suggesting that the chair a carpenter built in his own time couldn't possibly give you any reliable signal about how the carpenter works, because what if the carpenter was in a rush? Well, let me point out that a rushed veteran and a rushed beginner will cut completely different corners. Kind of like how a skilled artist with only 10 seconds to draw something can still express a great deal of their expertise merely by how they attacked the problem.
  - bleah1000 6y ago
    Let's look at that chair analogy, you are presuming that someone can look at a finished chair and say it's a good chair, and the carpenter who built it is probably good. But in order to do that evaluation, you need to spend time examining the chair. And you don't have any guarantee that the chair was actually made by the person presenting it to you. Maybe someone else helped them build it, or they built it using step by step instructions they found online. My issue is that the evaluation can take a lot of time, and if you are not familiar with the project, it makes it really difficult to get anything useful. If your hiring process always requires github code, then the chance of people faking it, or presenting code that isn't theirs is going to increase. And if you are looking at it for a project a candidate can discuss, you can do the same thing by choosing something from their resume. In my opinion, it just doesn't add that much and will wind up taking up a lot of time. You would also need to decide when in the process you look at the projects. Doing a proper eval would still likely take hours for a small handful of candidates, so you wouldn't want to do it until a person was well down the interview path. And at that point is it really adding much more than you already know?

bleah1000 6y ago

Have you ever been able to look at someone's code and immediately figure out whether it's good or not? I think it can be easy to see if it's really bad, but sometimes it can be hard to tell if it's okay code, or really good code. The problem is that you might have extra information to make a hiring decision, but it requires orders of magnitude more time to evaluate. For example, if the whole project is done by a single person do you evaluate their design and code? What if it was just a one-off project that they didn't care about so it has copy-paste code in a few places. Is that bad? If you ask candidates to point out examples of good code, then is that really meaningful? What if a mediocre programmer can find a few places where they wrote some strong code. What if that code was made good through a strong review process? I think the problem is that it's too difficult to determine if open source contributions are actually representative of the way someone will code in a job.

hombre_fatal 6y ago
I don't think the most useful info you can get from someone's Github involves the sort of deep analysis you're attacking in your comment. Nobody is deep diving your code like this, btw. Looking at someone's code projects can tell you some things like how they might write a README, if there is one. It might present a concrete project they built that you can discuss in an interview; what was the hardest part of this project? It can tell you where they are roughly on the scale of "barely started programming" and "clearly are experienced" (an experienced developer can glean this very quickly from someone else's code—even what they choose to paste from Stack Overflow—it isn't as hard as you think). Reading the code line by line looking for "strong code" is something that beginners think employers will be doing, but they don't. Just like developers don't evaluate libraries like this, they do a more topical, holistic page-through. Of course it isn't going to tell you exactly how someone will perform on the job. That's not the goal post (the absence of Github usually means you have nothing to look at at all). It just has a few useful signals like looking at a chair that a carpenter has built. It seems like you are suggesting that the chair a carpenter built in his own time couldn't possibly give you any reliable signal about how the carpenter works, because what if the carpenter was in a rush? Well, let me point out that a rushed veteran and a rushed beginner will cut completely different corners. Kind of like how a skilled artist with only 10 seconds to draw something can still express a great deal of their expertise merely by how they attacked the problem.
- bleah1000 6y ago
  Let's look at that chair analogy, you are presuming that someone can look at a finished chair and say it's a good chair, and the carpenter who built it is probably good. But in order to do that evaluation, you need to spend time examining the chair. And you don't have any guarantee that the chair was actually made by the person presenting it to you. Maybe someone else helped them build it, or they built it using step by step instructions they found online. My issue is that the evaluation can take a lot of time, and if you are not familiar with the project, it makes it really difficult to get anything useful. If your hiring process always requires github code, then the chance of people faking it, or presenting code that isn't theirs is going to increase. And if you are looking at it for a project a candidate can discuss, you can do the same thing by choosing something from their resume. In my opinion, it just doesn't add that much and will wind up taking up a lot of time. You would also need to decide when in the process you look at the projects. Doing a proper eval would still likely take hours for a small handful of candidates, so you wouldn't want to do it until a person was well down the interview path. And at that point is it really adding much more than you already know?