HN Explorer

Hackers, is publicly viewable code good or bad in terms of employment?

6 points by bigtea ↗ HN
Maybe somebody has written quite a few programs that work great, but they were just hacked together. The code may not be the prettiest, it may not have proper comments and it may not be robust capable of handling everything thrown at it. It may have a few known bugs, it may not even be fully complete. In such a case is it still good to put these products up in public view even though they are not of amazing quality(maybe not even your best work)? or is it better to keep them private? I ask because I see it both ways. Employers would likely want to know you have done something, but then once they see that they can read your code, see you didn't handle every exception to perfection and write you off as a lazy idiot.

11 comments

[ 3.1 ms ] story [ 36.1 ms ] thread
grandalf
I think as long as you contextualize what the goal of the project was, then it can only be a strength (it shows that you're not afraid to have some of your uglier code glimpsed by the world). We all write ugly code now and then.

My biggest fear when hiring someone is that they're so image conscious that every commit must look perfect... I know this ads about a 20% time overhead onto everything and not only is it extremely vane, is typically part of a quest to get job offers, etc. In general not things that are valuable to the current employer at all.

bigtea
Good points. I never thought about pedantic programmers being a waste of money.
jrallison
My first step when determining whether or not I want to talk to a candidate, is finding any code they've made available online. I'm much more willing to talk to someone who has published bad code online, than someone who hasn't published anything.

It's great if I'm impressed with their code, but bad code isn't necessarily a negative. I'm much more interested in why they wrote it a certain way then looking at their code with no context. Everyone out there has written bad code, it's understanding the decisions made behind the code that's interesting to me, in regards to whether or not a candidate will make a good employee.

bigtea
Well that certainly is good to know. I just worry though that compared to candidates who have no online code, those who do will have more to criticize. Maybe not by you but I am sure there are some managers who would be more willing to hire somebody with no online code than somebody who did have some online code who maybe made a few mistakes.
beaumartinez
As is often quoted, "real artists ship".

If you publish code, even if it is buggy, you have proof that you can code (which is pretty important). However, I'd ensure that it works. If you are aware of bugs, document them in the code.

Would you buy clothes at a store that didn't let you see them until you bought them?

bigtea
well probably not, but people do buy clothes online all the time.
stanleydrew
I can say from the perspective of hiring at Twilio that we often look first for a github or projects link in a cover letter or resume. Fairly often we decide to give someone an interview based on that. The opposite is often true as well. Without seeing code, a candidate who is on the fence may get passed over.

Ultimately we are looking for creative hackers, and public projects are crucial in determining the inquisitiveness of a potential candidate. Other employers may have different priorities, but I think most startups are looking for similar types.

beamso
I think it's good in terms of employment. I'm currently looking for work and some companies advertising positions / the recruitment firms advertising positions for some companies are now asking for github accounts along with cover letters and resumes.

(I've only seen this for Ruby jobs though... Java is tending towards 'Are you using these libraries in your current position? No? Thanks for your application but...'.)

exline
Its a huge plus. We are in the process right now of hiring and that is one of the first things we ask about. Do you have any open source code we can view? This tells us several things about the person

1) They are interested in coding. This was done on their own time, away from work. This means they actually like to code.

2) A lot of work is done to learn a new language/technology. This often shows desire to learn and the ability to at least hack together something that is new to them. This is important because we will be asking them to come up to speed quickly in our code base.

3) You can look at the code and get a feel for how they code. We are a small team and each developer will have the ability to have a big impact (for good or bad). Getting an idea of how they think, how they solve problems is a huge plus.

I don't think you need to have a lot of code available. Pick your favorite project, or 'best' project and make it available. I see very little downside.

ayers
This is good to know. I am currently in the process of leaving my current job and looking for work in a different country(UK). I have been hacking away at a side project that will help fill a particular need but mainly because:

a) I wanted to expand my skill set and work on a language and environment that I don't get to explore in my current job.

b) I want to have something to show potential employers to let them know that I am passionate about development and more than just a 9-5 programmer.

The issue I currently have is that the code is ugly and there are lots of things that I feel I could refactor and clean up. I might always feel this way as I am sure I will never have anything "perfect". I am wanting to get it live within the next few weeks and I think that I will have to accept that I just need to get it live and then focus on improving it after I have had feed back from users etc.