This is true about a majority of small/medium (and sometimes even big) startups.
If you have enough experience for a recruiter to respond at all, none of that extracurricular stuff matters
You don’t?
Anyway, there is no reason to spend the time looking at what people have done on GitHub. Once you make the final five or ten candidates, we could honestly use sheer chance to decide and end up just fine. The only reason we don’t do that, is because it would be disrespectful to the applicants, but the interviews are as much an opportunity for them to figure out if they want to work with us once they’ve met us, as it is for us to do the same.
Hiring people once you move past a certain skill level is much more about finding a common fit, so that you can continue having the good culture that you have already established.
It’s not that I think you are wrong to look at github though. It’s just that I don’t feel it’s really ever worth the resources you need to allocate to get a proper picture. I feel the same way about the coding interview, it’s just a waste or everyone’s time. I mean, how can you tell if their GitHub profiles aren’t doctored? If it was too clean or too good, I’d personally be suspicious why they’d work for us.
It's just a little attitude thing that makes so much difference. The way salaries work, they probably don't get 5x salary so they are extremely valuable for the company and to find in general.
If you just look at general performance, resumes and things like that you might just get "rest and vest" types.
Really? Because that’s not what our data shows on it. It shows specifically that regardless of what we submit applicants to won’t matter. Maybe we’re just bad at hiring, but with 25 years of data from a very broad range of job types (public sector) we can at least be comfortable with the knowledge that everyone else sucks as much as us.
I get your point though. Some engineers are more valuable than others, but the thing is, that it’s not a constant and there are no real way to make sure you both attract and keep them.
We employ an engineer who just might be the countries leading techie on ADFS and how it plays into our national and EU vases strategies for NSIS certifiably authentication. With a background as a bouncer, I’m not sure how many places would have guess that when he was first hired.
I’m another such story though in a different manner. I used to be real rockstar developer, and a real workhorse. This was way before I got into management and long before I had children. Because when I did have children it turned out that may undiagnosed ADHD could no longer fit into the responsibilities of adult life and I worked myself into first a nice range of stress, then anxiety and then a depression. Now I never work more than 37 hours a week unless there is a big event, like elections, and when there is, I make sure to not-work the extra hours after wards. If you had hired me the year before my first daughter was born, you would have gotten the workhorse with a very high degree of both creativity and getting things to actually do something useful for the business end. A year later you would have been sitting with a depression stricken employee who was on partial sick-leave for 9 months.
I understand the dream of course, but unless you can show me some data on someone who figured out how to actually purposefully hire the dream employee, I’m personally going to consider it a dream. An unhealthy one even, because almost nobody is ever really irreplaceable in an enterprise organisation. Sure the loss of some employees are felt harder than others, but the truth is that IBM could stop selling consumer PCs and still trundle on. So in my opinion it’s much better to create a team of people who work well together and who have a good culture, because that means it’s also easier when someone moves on to other things. It also means that you’re not as effected by the life changes of your employees.
Ask yourself this when hiring: you genuinely have a series of actually-actionable tasks ready to go for the new hire? Do you have the right resources on hand who understand that a part of their job is to answer questions about those projects from the new hire (and it will probably be a whole lot of stuff)?
The answer is going to be that you probably don't, and so whoever you hire, no matter how good they are, your company will just never know.
In my experience, it's pretty simple. Pay them lots of $$$. My circle of friends is in their 40s now, and the ones we all generally consider really good make boatloads. It's hard for them to switch jobs because most places aren't willing to pay a "regular developer" nearly as much.
I never send my GitHub links either. If I am coding a side project and I think it has business potential I am unlikely to start with open source and if it doesn't have business potential, I wouldn't bother. Also if I am building something on the side, code is likely to be rushed and seemingly horrible.
I have no idea what in GitHub was written by the owner itself, what was copied, how long it took them etc.
Now I get some people don't have time for open-source after work but it's way way easier to ace an interview when it can be based on something you build yourself, can show and can talk about the ins, the outs and the design constraints and your architecture choices.
Also, the vast majority of developers don't have open source contributions or projects worth pointing to. Further, it strikes me that the ones that do have such projects can be much more selective about which company they work for than companies can be about them.
Furthermore you're making an assumption that anyone who has code on their github produced it for no compensation, as if that was their sole motivation.
Maybe it was a previous project, maybe they open sourced a side project that at one point made income, or maybe it was something they did as an experiment or for purely personal reasons and compensation had zero relevant bearing.
If you were at five places for 9-18 months at a time with several six month gaps interspersed? Not evidence of absence, but that’s absence of evidence to me. (Immediately, I’m assuming several of those gaps might be flameouts.)
I'm curious, what about this situation but no gaps?
None of these are signals that I rely on as binary go/no-go gates; the main point was “just because you got other employers to pay you for a short while, that’s not standalone evidence that you can deliver business value through working software”.
I don’t believe in jobs-for-life, “putting in your time”, “paying your dues”, “never quit before 2 years”, or other nonsense advice, but if you’ve never had a long stint at a place, at minimum you’ve never seen the pain from your decisions 24 months prior play out and the maximum negative case is far worse.
For most of the folks I've worked with, it's the case that if they take a job and they're not learning something, they're not going to stay long. And if they take a job and the choices are "stay here, even if they enjoy it" and "take a 15% compensation bump that will ripple through the rest of their career", it would be foolish not to go for the latter.
The places that understand that retaining people takes effort are less rare than they used to be, but they don't grow on trees. If you want to hire someone longer term, I hope you're putting the money, and the investment in that worker, on the table.
To be clear, I'm talking about a persistent pattern. Even those of us with fairly long-term employment (~10 year stints) in general often have one or two short stints for various reasons. E.g. dot-bomb in my case although the job wasn't a great fit anyway.
But that “extracurricular stuff” is exactly what op has been spending their time doing for the past years.
But yeah they won't care about the crappy products since all the companies you interview with are doing the same, honestly the real followup question would be what do you do about references