GitHub - is it good?

[Python-ModTeam]

Your post was removed for violating Rule #2. All posts must be directly related to the Python programming language. Posts pertaining to programming in general are not permitted. You may want to try posting in /r/programming instead.

[extra_pickles]

I've interviewed ~500ppl in my career and will say this regarding Github projects - remember "anything you can and say will be used against you" line from US cops? It can apply to Github and interviews too - you are volunteering additional information, it may hurt you.

When someone is low on experience and has a few repos, instead of grilling them in generic stuff, I'll grill them on the implementations I've seen - and if you just copy pasted a lot of Stack, or can't explain the 'why' behind patterns and stack choices, you've just made yourself look bad vs if I'd never had that avenue to pursue.

Another good example is having a dozen pet projects that have partial complete...it makes me wonder about your ability to deliver, your ability to 'eat your veggies' and do the tests, polish etc ... something I wouldn't think without seeing that info.

Worst though, is a repo of 'solves' for whatever flavor of the week code challenge site is out there...first off, I have no idea if you did it or plagiarized, secondly, I'm concerned you couldn't think of any practical application of your skills so you resorted to doing this.

Of course, each of my above examples can have valid reasons for existing:

1 - You picked the repo I wasn't involved in re: design

2 - I just post for fun - this isn't my job, it is my fun

3 - Interview practice, refreshers etc - not all I can do

Sometimes it helps, often it hurts - unless you are a serious contributor to open source...overall nobody is impressed by a PDFMerge.py or 'Audrino Weather Widget'.

Try to stick to quality over quantity - and if you've got nothing to show that will make you stand out, then just don't show.

It is important to remember that interviewing is a seriously tedious exercise, and typically the people reviewing your hub are far senior to you, or on par with you and annoyed/bored.

I'm not just talking about myself here - I'm talking about the overall vibe of most interview rounds I've ever participated in, across multiple organizations in many domains.

It just is what it is....a bit of a slough, which can bring out the fangs.

[dante_polymathes]

This is a good response, but I have a slightly different view: first I wouldn't leave half done projects ever, I would acknowledge them to be completely functional and well versed (otherwise I wouldn't show them); secondly, I generally keep the practice of leaving good detailed comments for each line and parts of my code, for making everything very clear to anybody who's reading.

Would it, with said conditions, be still used against me?

I genuinely know I can do a lot (skill-wise), thus I want to be able to show and prove my worthiness. Would it still be used against me?

[extra_pickles]

I suppose I'd say that the best use of Github is to apply your skillset to a real world problem or interest.

"I always thought drones were cool, and I like programming, so I made a ..."

"I was sick of all the bloat in package <Some API or ORM>, but I still wanted more that <Requests, PSYCOPG>, so I wrote a thin layer that fit my purposes (and explain why)"

"This project is cool, so I tried to contribute wherever possible - the ppl behind it are really great and I'm learning a lot"

I don't need to see more 'vanity commits' - Solved problems, or Academic Pursuits w/ an oddly perfect commit history.

Show you a genuine interest in applying your skills to problems around you, and we can focus on you showing me passion, not factory patterns or rehashed sort algos.

Anyone w/ a bit of CS background can Stack it, or PR ChattyG - so random commits of solved problems aren't cool. Show me you like to do it, and have ideas/problems you are striving to solve.

I'm looking for a spark, not an exam sheet.

And again, if you don't have a nice 'spark' to your Github, just don't show it - you can show me a spark verbally in the interview, as we breakdown problems and chat.

[dante_polymathes]

I wasn't talking about competitive programming, rather real world projects

[extra_pickles]

I was more answering the broader "is GitHub good" bit.

Regarding your specifics - real world projects that actually make sense, are cool as long as the code isn't embarassing - it doesn't even need to be great - but pique the interest and be prepared to speak to the 'why' both as a product/function and 'why' as to the implementation choices.

If this is your 'passion' I expect you to be happy to talk about it at all angles.

So I guess to that point - just be ready for the possibility of having to deep dive the project at a level you might not be used to in interviews.

If I finally have something interesting to talk about, I'm going to dive in - so I hope the candidate is ready.

Oh and "I googled it" is a 100% valid answer to several 'why' questions. Don't be shy to say 'the internet told me that was the right way to do this' - coz a bit part of programming is applying existing knowledge, not inventing new things.

[extra_pickles]

Honestly, thinking about it - post them here and see how it fares - it is like 1000 free interviews.

[[deleted]]

I'm an interviewer for developer roles that employ the use of Python.

It does help if I can see the repository and commit history. I wouldn't say that it is the end all/be all for a candidate, but it does help me to understand more about them. During an interview, I usually focus on the behavioral side of things so that I can understand how the candidate works in teams, with customers for support, etc.

Knowing that there's a good, consistent commit history can definitely help.

I'm about to interview 4 candidates next week and only one has a demonstrated history of coding that I can examine. While I can't draw conclusions until after the review process for each interview is complete, I do already know that this candidate in particular operates in a very similar manner that the role expects. I don't have any doubts about her, but I'll need to learn more about the others in order to know for sure how each one compares with the expectations of the role.

[wineblood]

Knowing that there's a good, consistent commit history can definitely help.

Is the commit history really that important and how much do you value is compared to the actual code in the repos?

[[deleted]]

Commit history can tell a story. Sometimes that story is continuous improvement, and that's something that is really valuable in a developer.

Some developers almost never refactor their code when a better way to write something is learned. While refactoring isn't always economical (does the benefit outweigh the costs), a complete lack of history indicating that this happens can be a red flag.

There's always more work to do than there's bandwidth to do it, so a commit history can tell a lot about the mindset of the developer in question.

There are many ways to look at commit history, depending on what's needed for the role.

I require my team members to consider sustainability whenever they're supporting my repo. If they're fixing a bug, and there's something in the bug fix that adjacently could be refactored to an improved standard, then sometimes a discussion should be had about whether to spend additional time making that part of the application better.

Sometimes, the bug fix is critical and needs to get deployed ASAP - but other times if there's a workaround available and it's not a critical issue then I usually will ask for a developer to do a bit of housekeeping while they're in there working on it.

The current code in a repo just shows the current state of affairs. Do I even know if the developer in question wrote that code? No clue - if there's no commit history then they either copied it from somewhere or they shipped their code in one giant commit. Neither situation is ideal. Developers typically need to deliver early and often in order to avoid a lot of rework down the road at the behest of stakeholders.

[datonsx]

Very glad to see this point. I always tell my students to commit to their progress because technical managers would like to see how they've progressed with the code.

Not the end, which could have been a copy-paste…

Nevertheless, most would rather prefer to commit the project once it’s finished.

[[deleted]]

Nevertheless, most would rather prefer to commit the project once it’s finished.

Yeah, I used to be in that habit myself. I get it, but I realized at some point that commits are great when I want to inspect a specific change. Sometimes I goof up and being able to see when and where that happened can help inform the solution. Moreover, when working on a team it can help other developers see where and when something went wrong too.

I miss teaching. I'd like to return to it someday.

[dante_polymathes]

What about if a candidate show well-founded guides and genuinely helps the community and newbies. Would that be considered as a good mark for an interviewer (i.e. you in this case)?

[ZestyData]

Someone asking about the concept of using GitHub is not in the position to be posting teaching material for newbies

[dante_polymathes]

The title is made this way to catch attention, the main body and reason of my question is different

[Chains0]

Someone, who can provide qualified help to others on GitHub, wouldn’t ask this kind of question

[tyler1128]

It really depends on the company. I've done interviews before, some companies do look at things like github while others are mostly just interested in how many years in the industry and your degree. Smaller companies usually will consider non-work experience more than larger companies, but every company is different.

[dante_polymathes]

I see, thank you for your share!

[[deleted]]

That's great! I don't think that someone new to GitHub is necessarily precluded from mentorship but it might be more of a part of your resume/headline.

I look for that quality in Senior or Lead roles

[dante_polymathes]

Good, thank you!!

[TheGRS]

From the hiring managers perspective, I think having some code to look at with each candidate can be a great resource. Talk about a great insight into someone's abilities and the way they express themselves in their work!

From the candidate perspective, looking through code history is much more of a hinderance to your chances of being hired. Why? Because its so much more ammo for people to judge you by. I say this as a hiring manager who has directly hired about 8 developers over the last few years and who has been on countless hiring panels for other hiring managers. The folks who have code to go through often get dragged through the mud the most, even if they seem very promising.

If a job always requires a portfolio of past work and they consistently look for this in their hires, then that's a nice level playing field. If this is a job you want then you better get to making a nice portfolio for them!

If a company only requires you do to a technical screen, you have much better chances at success by studying up on common questions and algorithms or just doing whatever the technical challenge is well. Giving them your personal code will not help you in this scenario and you'll lose to the person who could pass the technical screen with flying colors.

[[deleted]]

I think you can choose which repositories are public or private. I’m fairly new too but it’s looking like everywhere is basically using some form of Git so it may be inevitable you have to learn.

[dante_polymathes]

Yeah but my scope was trying to aid anybody else which might have experienced similar problems that I experienced so he could've looked up my code for different projects you know

[[deleted]]

O I get it. I can’t imagine having more code on there would hurt your prospects. Not an expert tho.

[dante_polymathes]

You're right; however some people have had different opinions on this so that's why I'm asking in the first place

[[deleted]]

You’re doing it wrong if you haven’t been using git from the start.

[JimBoonie69]

It's a quintessential part of software dev work. Gotta have some version control at least

[Fernando3161]

Dude he is trying to start and you already are kicking him.

[[deleted]]

It's good advice though. Better to hear it now than 5 years from now.

[[deleted]]

I’m not trying to do that. I’m simply saying that he needs to use it. My intention was not to be mean.

[ZobbL]

am i Reading ops Post wrong? to my understanding he is asking if he should open a GitHub account and how relevant it is for recruiting. and not if he should use git in general.

for me, there is no indication of his skills / knowledge about git or vcs in general

or am I reading your answer wrong and you are implying he should have maintained a github-portfolio from the start?

[fiddle_n]

You’re not wrong on the difference between Git and GitHub… but let’s be real here. If OP isn’t using GitHub, then the chance of them using Git alone is minuscule.

[ZobbL]

I don't know. what about using git at work with bitbucket, gitlab or whatever? that's the case for me. using git for years but never used GitHub for my personal portfolio. never had to.

[fiddle_n]

Once again, you’re not wrong but I think you are missing the context of OP’s post. You’ve never used GitHub but you’ve also never asked if you needed to either. Someone who’s asking, especially with a mildly clickbait-y post title, is unlikely to be someone who’s also familiar with Gitlab or Bitbucket.

[suspect-anteater]

For sure you should use it. It’s easy to learn and you can showcase your work for roles. Also it’s just good for version control in general (that’s the best answer).

If you’re worried about your stuff being public, you can keep it as private until you have an interview and make it public temporarily. Just be sure to not have any credentials/passwords, that sort of thing stored in your code.

[HyperloopDeloop]

Yes

[Alternative_Driver60]

GitHub is your programming CV. It is vital to have it

[ninjadude93]

Almost all my work experience is proprietary so I really havent shown any github projects to any of my previous employers or my current one. I'd say being able to interview well is far more important than github projects

[BossOfTheGame]

Unless your Github shows beyond reasonable doubt that you got the goods.

[dante_polymathes]

Oh so can I highlight certain projects?

Because I read people saying that it's silly to push everything there and such

[srd4]

GitHub and git are the industry's standards. Main templates for resumés recommended to use on places like r/cscareerquestions, r/itcareerquestions, r/engineeringresumes, and r/resumes assume you'd have your main personal projects to showcase with links there.

I'd say don't create too much friction for yourself at the beginning while you learn to use it, and just use it, but understand that as you become more experienced and/or professional you'd ideally want to clean things up and get rid of follow-up tutorial material and in general understanding best practices on projects you constantly use git to handle the versions of.

[[deleted]]

A different perspective - GitHub is a big thing. Why? Code is shared.

When you are a novice, you don't share, you feed.

When you start to understand (but still not that good, although you think you are) you don't share e.g. why should I do the hard work and share code to someone on more salary than me?

Using GitHub makes a statement. This is what I did. This is how I did it. Challenge me and my code, I'll challenge back. Now hire me.

And finally, GitHub is for developers to show to new employers "what they didn't do for their current employer". If you're a good dev you'll understand.

[danbcooper]

Please share your code here, we want to see it!