Hacker News Reader

Comment by jon-wood | Hacker News Reader

When interviewing someone I will try to track down their GitHub profile, and having some decent code on their is probably going to make me more inclined to hire you since it gives me a data point on how you work. However for all the reasons listed in this article I’m just going to disregard the lack of a profile or a profile with limited content, I’m trying to hire a professional software developer to do work here, and whether or not your hobby is running a large open source project doesn’t really influence how good you are at your day job.

View on HN

I had an interesting interview a few months back, the interviewers said "Please pick a smallish repository and walk us through the design and implementation".

I talked for nearly an hour about one of my projects, first of all the broad design, then various interesting aspects of the implementation. (Most projects have lots of "dull"/"boring" code, but I certainly highlighted the areas I had the most fun/pleasure/difficulty implementing.)

Was a nice interview, although it was only possible because I've posted a whole bunch of projects online. I know other people keep their stuff private, or don't even write code in their spare times.

I've interviewed people who don't have public repositories so instead I'll ask them to bring some code with them that they can talk about. It could be a school project, it could be a single function or an entire system. For me, the exercise is mostly about evaluating communication skills.

I mean, I can't bring my work code with me, because NDA. I might not have side projects because life, and school was a long time ago --- actually, I don't know if I even have that code, most of it I archived on the school shell server and they kicked me off around 10 years after I graduated.

Also, my side project code is garbage, because only I am going to look at it, and so it only needs to make sense to me (and maybe, future me), and it's more fun to write awful things.

I'm sure this gets you good insights on some candidates, and probably is pretty decent for fresh grads (who should have something from school), but I can't imagine it working well for a lot of experienced candidates.

Hearing why your side project code is garbage is useful too. The code itself is rarely very interesting. It's all about hearing you describe what's interesting (for positive or negative reasons) and to see how you answer questions or challenges.

Same. For me, a great github profile with repos and contributions may add to someone’s prospects when it comes to getting a first round interview. An empty profile or half baked commits? I will completely ignore it.

However, if I see someone engaging in an issue or PR discussion in a way that would make me nervous about having that person in my team’s slack channel, I am much more likely to pass on them.

>whether or not your hobby is running a large open source project doesn’t really influence how good you are at your day job.

I got a ton of useful experience doing open source that aided me in my day job. Experience building abstractions and DSLs, building frameworks, and testing stuff really effectively are all examples.

There's a kind of common thread with all of these things in that in my day job I didn't really practice and hone my skills in these areas because of the constant churn of work that the business wanted done. The incentive structure of corporate development encourages a kind of frantic slap-dash "just get it good enough and get it out there" approach while open source is much more relaxed and pensive and thoughtful and elegance is valued much more highly (sometimes too much).

There is valuable experience to be gained from both environments - I wouldn't say either one is really ideal. Open source, for instance, doesn't put the same emphasis on customer feedback that business does and often takes too long to develop new stuff.

Do you actually scroll through and asses the code quality though? The only thing I can tell at a glance is "they bothered to clean this up and document it" which is one useful sign.

The more useful signal for me is GitHub as a portfolio piece, if they got some concrete relevant work done that I can ask them about in the interview but I don't need to see the source code for that.

I give it a quick skim, unless it’s something that interests me on a deeper level than “this is just some code”. It’s essentially a somewhat deeper fizzbuzz test, if someone has half decent code which shows baseline knowledge I’ll skip doing a screening test.

Reply on news.ycombinator.com