[camhenlin]

I've held various roles over the years and personally believe that public contributions and innovative open source projects will often impress potential employers. Despite not coding much professionally anymore, I engage in fun personal open-source coding to maintain my skills. This strategy even played a part in securing my latest, predominantly non-coding role.

After reading your post, I reviewed your GitHub profile. You're certainly on the right track, but there's room for improvement. Here are my personal observations and opinions:

- You have numerous small projects, but they lack detailed descriptions and the README files don't tell me much about their purpose. Why are you building these? How can they be run? What functionality do they offer?

- Many projects have minimal activity, suggesting they might be incomplete or abandoned.

- There are several boilerplate projects like "calculator", "todo", and "tutorial".

- Your commit messages in most repos are quite short, often just one or two words. This practice might not be accepted in a professional team setting. I've been guilty of this with my personal projects at times too.

- Your project https://github.com/prakhar897/workaround-gpt shows promise in terms of community interest and the start of what could be a well-constructed README. Perhaps you should consider continuing with this project or developing a similar, well-structured project. Just a thought.

[nsxwolf]

So, it sounds like having a Github could be a net negative. I don't treat personal projects like I treat production code at work. I experiment, don't write a lot of unit tests, use bad practices because they're easier, and I get bored and abandon things because after all, it's not like I'm being paid for any of this.

If that's going to be seen as a red flag, then I'm not going to share any of that.

[camhenlin]

I certainly didn't mean to suggest that having a GitHub profile could be a negative. My point isn't about identifying red flags, but about pointing out areas that could be improved to make one's profile stand out - especially in the case of the person I was responding to. As someone who reviews numerous resumes, I'm providing insight into what I typically look for when I peruse a candidate's GitHub account, based on my personal experience. I don't disqualify someone based on their GitHub activity, but I do use it as an additional datapoint to help identify those who might stand out from their peers.

[berkes]

Just communicate clearly why it is how it is.

I've some GH repos whose quality I'm ashamed of today. But it's clear they were developed by a person with 12 years less experience than me today. It's clear it was just a hobby-project or clear that it wasn't ever meant to be continued this long. A line like "The code in X is a mess and needs a refactoring" is enough.

It is to me, when I researched candidates. When a ticket, todo or note shows that the author is clearly aware of the problems, and shows she/he can weigh off why (not) to fix that today, it tells -me- they are good in what they do.

A dev who shows to make decisions about quality, effort, workflows, based on experience and reasoning, to me, is worth a hundred devs that blindly follow The Sacrosanct Rule Of The Latest Cargo Cult Religion™. A dev who shows she/he grew over time, by showing "terrible" code in the past, to me, is worth a hundred devs that have been doing the exact same rituals for years or decades.

So, yes: by all means, show your worst stuff. But be sure it's clear that you know its "bad" and why.