It doesn't matter, you should still contact someone technical about it, especially if she actualy said "more stars on their git". Put that quote in your message!
They might be glad to know she's filtering candidates based on that, because they can talk to her about it. It could lead to you getting an interview.
Having worked at very big successful companies and being heavily involved in the hiring process: We know recruiters don't always get it right.
We need them, because creating and maintaining hiring pipelines is a full-time job, but we know (and the recruiters should also know!) that they're working on a best-understanding of the job they're recruiting for, and that best-understanding is not a complete understanding, since they don't do that job. It might have been a miss on their understanding of an explanation, it might have been a miss on whoever communicated the job requirements to them. But if you have a contact outside of the recruiter, you should 100% reach out.
...or perhaps let's take care of the patients while we develop a cure? If it is a fact that recruiters look at github presence, ignoring that fact is harmful for people only sharing work on gitlab, which in turn hurts gitlab.
Much like the value of the US dollar, what you're saying is only real if enough people choose to believe it.
Buying into and supporting this behavior is just digging an increasingly deep hole. If you don't want github commits (and an agreement to the github terms of use) to be a mandatory part of all developers lives and CVs, then simply continue being an excellent developer without making github commits that you don't want to make.
We're in an important stage of github adoption at the moment. Some recruiters think it's a critical signaling mechanism. If we buy into that, they will seem to be correct, and the companies they recruit for will allow them to continue with their methodology. Soon, they will become correct because all career-oriented developers will feel compelled to work on github based open source projects to the exclusion of other open source projects, even if they don't actually give a shit about the projects they are working on.
However, if the companies they recruit for see high quality developers going to the competition because their recruiters are dismissing people out of hand for not being on github, those companies will eventually tell their recruiters to pull their fingers out and do some proper legwork.
The correct approach is to starve out this behavior while the cost of doing so is relatively low, not buy into it.
>The cost is pretty high to bobsam, who didn't have a chance to interview for his dream job.
As I said to him in my directly reply to his post, acquiring an interview for ones dream job is a task best not left to others.
In relation to our specific discussion, ultimately one developers loss of their dream job is not a huge cost. We are looking down the barrel of a future where github can pick and choose who is employable and who is not, and therefore who makes key technical decisions at major vendors and who does not, by banning github accounts for political reasons. That has knock on effects for things like key standards decisions, and that's when the costs of refusing to conform start mounting. I basically don't trust companies with that kind of power.
Its not gunk. Stars is the first thing I check for social proof before using a project in my work. Higher stars is almost a guarantee of better quality and momentum.
>I've never seen a project with high start and low momentum, I don't mean dead projects ,obviously.
"I've never seen this thing, except in this obvious and common case where it happens all the time, but other than that, literally never".
Mate :/
In general, my first step in deciding whether projects are good is to google "<project name> review", and see what other developers and sysadmins have experienced with it.
I have often found that a 5 stars system contains inadequate information density to provide me with guidance on the suitability of one project over another with respect to integrating it into my companies tech stack, although I appreciate that's a personal standpoint and that you may disagree.
Have you actually logged a feature request for this?
*Edit: Thanks for the downvote, but seriously - have you? If you haven't - It's more constructive to do that so civilised production direction and development discussion may take place in the official centralised forum rather than having outbursts on HN.
If I were interviewing you I would care a lot more about the job you were hired to do than about any side-projects that are not part of your job.
I'm not a fan of recruiters incentivizing "required" side-work. That's the time you dedicate to all other important things in your life (which could be a side project, but it is not in most cases)
The were two posts on Reddit about placing fakes ad for a job to see how the competition was. They were both blown away with the quality of the applications, in particular people working on a lot of important side projects.
I can only assume recruiters very much consider this when they don't know anything else about you.
All things being equal if all you know is their side projects that makes sense. Normally you would have their resume which includes work done at their job. I get how it's so tempting to look at people's side projects as a measure of proficiency. I just don't think it's fair to judge people by their ability to spend hours working outside of work.
I love Gitlab. One day I expect them to effortlessly make an OS with an IDE preinstalled with plugins for each a and every languages, which integrates with Gitlab and Twitch to stream your work.
Burndown charts, really? Fine, but that seems like a bit of feature creep to have features for manager-types in what I've always seen, overall, as a dev tool.
Those manager-types are the ones that tend to get a final say on what the devs use (rightly or wrongly), and if they feel they need those features, they are going to want to use a different tool.
I don't think people fully realize how truly difficult it is produce next generation dev tools. What GitLab is doing makes perfect business sense, since it's an order of a magnitude easier to create business focused solutions, compared to dev related solutions.
Creating next generation issue trackers, search, build solutions, etc. requires significant R&D and I really don't think GitLab is focused on this type of skunk work. I personally think Microsoft has the best chance to disrupt the software development lifecycle in the future, due to their R&D budget and talent pool.
GitLab in a lot of ways, is sitting in a perfect business position. All they have to do is look at what Atlassian, Microsoft, GitHub, etc. are doing and copy what can be copied. There really is no shame in this, as this only makes business sense.
Git has created an opening into the software development market that has never existed before. In the past, you had to spend a lot of time and money to create a version control system, which you could use as a beachhead for Enterprise sales. However with Git, you no longer require significant time and money to compete.
With Git, the really hard stuff is being worked on for free, by some of the smartest people around the world. And because of that, you can focus on solving the not so difficult problems, but still problems people would pay for.
Git has created a massive opening for who can compete in Enterprise, but as the easier problems get solved and turn into commodity features; focus should shift again, to the not so easy problems. If GitLab invests properly, they should be able to compete in the long run with Microsoft and others. The challenge I guess, is knowing when to start focusing on the harder problems.
I suspect the next big thing will be to incorporate machine learning into the software development life cycle.
- Issue comments that are no longer relevant, should be collapsed by default.
- You should be able to get a "too long; did not read" for issue comments.
- Searches should be context aware. Matches should take into consideration the user, time, branch (is this a release branch, developer branch, shared development branch, etc.) and so on.
- Build logs should include a "too long; did not read"
- Builds should be context aware to prevent wasting of resources.
I guess what ever can save time, money and speed development would be next generation features.
I'm not sure what GitLab's sales engagement looks like, but if you are not, you should be asking to speak with a company's internal, tools dev team, if you can. Large companies spend an insane amount of money and time, creating/maintaining bespoked dev tools for internal use. Companies like Google, Facebook, Twitter, etc. spend millions in labour cost annually, to build and maintain their internal solutions.
GitLab's goal, should be to see if they can create comparable solutions, that can be managed by small startups and mid size companies. Having worked in tools dev for Enterprise, I knew being able to search and analzye anything, is a time saver, but I also knew, it would be cost prohibitive for many smaller companies to provide such a solution internally.
This was why I set out to develop a solution that could be maintained by companies of all sizes and this should be the thought process for GitLab, in my opinion. If GitLab wants to work on solving the harder problems, it should understand what companies are spending internal resources on creating/maintaining and see if they can't make it available for the masses.
What you learn could lead to more intelligent code review solutions among other things. In a lot of ways, you are trying to capture somebodies skill set/knowledge, which isn't all that trivial.
I'd like to use Enterprise premium features, but I may have only say, 5 users who need those features. My other potential 50-100 users don't need Enterprise features. Anyway to work the pricing?
We are in the same boat. Our team of 6 people (and 7 or so projects) could benefit from the enterprise features and we would like to pay for them.
Unfortunately, because gitlab is so awesome, all the technical users in the company (100+ people) use it as a really basic scm for the tools they write. Some of them use issues, others just use it as a place to keep and share their code that isn't their home drive.
Paying for 100+ user licenses is out of the question, especially if under 10 of them would use the features.
It see your dilemma, paying $2k+ per month for something only 6 people will use doesn't make sense.
We looked at increasing the granularity of the licensed userbase (have some CE users, some EES users, and some EEP users on the same installation). This is something established players like Salesforce and Zendesk don't do, probably for a good reason. We now have to make this granularity for GitLab.com (which is running GitLab EE). But we're very afraid of selling this since it will likely greatly complicate the sales process.
We also looked at increasing the granularity of the licenses. You used to be able to pay per feature instead of having to make a bigger jump. This didn't work since it increased the complexity too much.
For larger customers we can spend time to figure out what the value is and discount if that is appropriate. Your team is on the smaller side but feel free to reach out to sales@gitlab.com to see what we can do (please consider including a link to this comment).
Obviously a great thing would be to have the other users in the company also benefit from Enterprise Edition features so the value is higher than the cost. But your comment indicates that chance is low.
Atlassian has the same pricing structure all users have to pay for all installed plugins.
If gitlab could figure out a way to be more granular without customers having to go through hoops of talking to sales team, gitlab would probably benefit greatly by converting more sale opportunities.
I can see many teams, rather than grabbing a hand-full of EE licenses would just stick with CE or maybe even just slap/integrate something on top to get what they want.
We did look at both of these before designing these features. Burndown charts are common, service desk functionality less so. We look forward to replacing our use of Zendesk with this.
54 comments
[ 2.6 ms ] story [ 98.6 ms ] threadA recruiter just toss out my application to my dream job since other applicants had "more stars on their git".
And the company is not your average IT sweatshop (big very sucessful company, names starts with an A).
They might be glad to know she's filtering candidates based on that, because they can talk to her about it. It could lead to you getting an interview.
What's the worst that could happen?
We need them, because creating and maintaining hiring pipelines is a full-time job, but we know (and the recruiters should also know!) that they're working on a best-understanding of the job they're recruiting for, and that best-understanding is not a complete understanding, since they don't do that job. It might have been a miss on their understanding of an explanation, it might have been a miss on whoever communicated the job requirements to them. But if you have a contact outside of the recruiter, you should 100% reach out.
Buying into and supporting this behavior is just digging an increasingly deep hole. If you don't want github commits (and an agreement to the github terms of use) to be a mandatory part of all developers lives and CVs, then simply continue being an excellent developer without making github commits that you don't want to make.
We're in an important stage of github adoption at the moment. Some recruiters think it's a critical signaling mechanism. If we buy into that, they will seem to be correct, and the companies they recruit for will allow them to continue with their methodology. Soon, they will become correct because all career-oriented developers will feel compelled to work on github based open source projects to the exclusion of other open source projects, even if they don't actually give a shit about the projects they are working on.
However, if the companies they recruit for see high quality developers going to the competition because their recruiters are dismissing people out of hand for not being on github, those companies will eventually tell their recruiters to pull their fingers out and do some proper legwork.
The correct approach is to starve out this behavior while the cost of doing so is relatively low, not buy into it.
The cost is pretty high to bobsam, who didn't have a chance to interview for his dream job.
Not "playing the game" only works if all good developers stop using GitHub, no?
As I said to him in my directly reply to his post, acquiring an interview for ones dream job is a task best not left to others.
In relation to our specific discussion, ultimately one developers loss of their dream job is not a huge cost. We are looking down the barrel of a future where github can pick and choose who is employable and who is not, and therefore who makes key technical decisions at major vendors and who does not, by banning github accounts for political reasons. That has knock on effects for things like key standards decisions, and that's when the costs of refusing to conform start mounting. I basically don't trust companies with that kind of power.
As a side note, recruiters are not on your side, they're on their own side. Don't rely on them for anything, least of all securing your dream job.
"I've never seen this thing, except in this obvious and common case where it happens all the time, but other than that, literally never".
Mate :/
In general, my first step in deciding whether projects are good is to google "<project name> review", and see what other developers and sysadmins have experienced with it.
I have often found that a 5 stars system contains inadequate information density to provide me with guidance on the suitability of one project over another with respect to integrating it into my companies tech stack, although I appreciate that's a personal standpoint and that you may disagree.
A project with lots of stars and rare commits is almost never better than one with a less stars but low-grade continuous activity.
"Date of last commit" is probably FAR higher than any "social" bullshit in terms of quality.
That's the first thing I look at when I arrive on a github page, always.
*Edit: Thanks for the downvote, but seriously - have you? If you haven't - It's more constructive to do that so civilised production direction and development discussion may take place in the official centralised forum rather than having outbursts on HN.
Maybe some of these are already implemented and we mostly need to get the devs to use them more frequently?
I'm not a fan of recruiters incentivizing "required" side-work. That's the time you dedicate to all other important things in your life (which could be a side project, but it is not in most cases)
I can only assume recruiters very much consider this when they don't know anything else about you.
They could whip something together just from their server-side analytics so it was more honest rather than a popularity contest.
For free...
Creating next generation issue trackers, search, build solutions, etc. requires significant R&D and I really don't think GitLab is focused on this type of skunk work. I personally think Microsoft has the best chance to disrupt the software development lifecycle in the future, due to their R&D budget and talent pool.
GitLab in a lot of ways, is sitting in a perfect business position. All they have to do is look at what Atlassian, Microsoft, GitHub, etc. are doing and copy what can be copied. There really is no shame in this, as this only makes business sense.
Git has created an opening into the software development market that has never existed before. In the past, you had to spend a lot of time and money to create a version control system, which you could use as a beachhead for Enterprise sales. However with Git, you no longer require significant time and money to compete.
With Git, the really hard stuff is being worked on for free, by some of the smartest people around the world. And because of that, you can focus on solving the not so difficult problems, but still problems people would pay for.
Git has created a massive opening for who can compete in Enterprise, but as the easier problems get solved and turn into commodity features; focus should shift again, to the not so easy problems. If GitLab invests properly, they should be able to compete in the long run with Microsoft and others. The challenge I guess, is knowing when to start focusing on the harder problems.
I'm not sure what GitLab's sales engagement looks like, but if you are not, you should be asking to speak with a company's internal, tools dev team, if you can. Large companies spend an insane amount of money and time, creating/maintaining bespoked dev tools for internal use. Companies like Google, Facebook, Twitter, etc. spend millions in labour cost annually, to build and maintain their internal solutions.
GitLab's goal, should be to see if they can create comparable solutions, that can be managed by small startups and mid size companies. Having worked in tools dev for Enterprise, I knew being able to search and analzye anything, is a time saver, but I also knew, it would be cost prohibitive for many smaller companies to provide such a solution internally.
This was why I set out to develop a solution that could be maintained by companies of all sizes and this should be the thought process for GitLab, in my opinion. If GitLab wants to work on solving the harder problems, it should understand what companies are spending internal resources on creating/maintaining and see if they can't make it available for the masses.
What you learn could lead to more intelligent code review solutions among other things. In a lot of ways, you are trying to capture somebodies skill set/knowledge, which isn't all that trivial.
Unfortunately, because gitlab is so awesome, all the technical users in the company (100+ people) use it as a really basic scm for the tools they write. Some of them use issues, others just use it as a place to keep and share their code that isn't their home drive.
Paying for 100+ user licenses is out of the question, especially if under 10 of them would use the features.
We looked at increasing the granularity of the licensed userbase (have some CE users, some EES users, and some EEP users on the same installation). This is something established players like Salesforce and Zendesk don't do, probably for a good reason. We now have to make this granularity for GitLab.com (which is running GitLab EE). But we're very afraid of selling this since it will likely greatly complicate the sales process.
We also looked at increasing the granularity of the licenses. You used to be able to pay per feature instead of having to make a bigger jump. This didn't work since it increased the complexity too much.
For larger customers we can spend time to figure out what the value is and discount if that is appropriate. Your team is on the smaller side but feel free to reach out to sales@gitlab.com to see what we can do (please consider including a link to this comment).
Obviously a great thing would be to have the other users in the company also benefit from Enterprise Edition features so the value is higher than the cost. But your comment indicates that chance is low.
I'm sorry that I don't have a solution.
If gitlab could figure out a way to be more granular without customers having to go through hoops of talking to sales team, gitlab would probably benefit greatly by converting more sale opportunities.
I can see many teams, rather than grabbing a hand-full of EE licenses would just stick with CE or maybe even just slap/integrate something on top to get what they want.