Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The GitHub Job Interview

blog.gigantt.com

Post reply on HN
Print view View original

21–30 of 44 posts

Re: The GitHub Job Interview

#21

Post by assaf_lavie »

dangrossman wrote: post #6

> Being rejected after two weeks of work doesn't look good on anyone's CV Why would someone put this on their CV?

In some countries this information turns up when you do your taxes for the end of the year. And not all job markets are as huge and "anonymous" as the U.S. job market - some (like Israel) are relatively small (a few 10ks of programmers probably) and word gets around. Besides, if you get asked on an interview about what you've done in the recent past in terms of looking for work you're basically lying if you're not mentioning a brief period of employment. Not a huge deal, but still it's not honest and some people would rather not.

Re: The GitHub Job Interview

#22

Post by assaf_lavie »

hkarthik wrote: post #9
baddox wrote: post #7

How is this any better than just looking for candidates who have created or contributed to other open source projects? I suppose there would be some good candidates that came from bigger companies and maybe don't have much of a GitHub portfolio, but surely the vast majority of people that would be considered by tech startups would already have some work online.

It's all about context. While a candidate might have some code online, you save a lot of time by having some code that you're more familiar with and can utilize to see how they think about a problem. Also it's good to see how someone reacts to digging around in an unfamiliar code base and see how they familiarize themselves.

Context is true. It's totally different to see someone work _with you_ on a project than to rummage around their commits to project you don't really know. The point is to see how it is to collaborate with someone, and that has to be a first-person experience (or take the word of someone you really value, but that's not what you get form random GitHub projects). And also there are tons of developers who never really contributed much to open source. e.g. in the Microsoft world this is not so rare, and you'll miss these people if you _require_ a GitHub reference...

Re: The GitHub Job Interview

#23

Post by saldfiae3 »

assaf_lavie wrote: post #18
saldfiae3 wrote: post #14

Really, this is no different from the offline coding test, except that since the code is open source it might be useful to someone later. I'd never do this Github interview for an open source project that was not very widely used, for the same reasons I'd never work on the company's closed source for an interview: exploitation. In that sense, working on a toy problem is a big feature to me in an interview process, I…

That's why it should be a cool, fun project. It's hard for me to see how one might get exploited by contributing as much time as he wants to an open-source project. Remember, the prospective employee uses the same experience to gauge what it's like to work with his prospective employer.

Assuming this company has fun work to do (you'd hope so), there's nothing stopping them just giving you their work.

It doesn't matter that it's open source if you're not going to use it and no-one else apart from them is (a very real possibility).

In essence, I'd happily agree with the article after changing this:

> "You come up with a cool idea of an open-source project"

with this:

> "You find a _popular_ open-source project"

Now you can be certain (not just optimistic) that the wider community will benefit from your work.

(edit: I'm thinking along the lines of jQuery, backbone.js, nodejs, django, memcached, sqlite, Nginx, Hadoop, Linux, ..., not some dev's/company's lonely github project)

Re: The GitHub Job Interview

#24

Post by tolitius »

writing code during an interview is great, but almost a 180 degree experience to writing code in real life. there are a couple of factors:

* psych pressure

* unrealistic timeline

* googling is usually not allowed, whereas EVERYBODY uses it writing code in real life

* editor/environment is usually not "yours"

* etc..

hence the _way_ you choose to conduct a code test will, in most cases, matter a lot less than the actual _problem_ you choose that needs to be solved. the more applicable this problem is to what your business does every day the better. e.g. sometimes a "red-black tree" is crucial, other times things like a simple mobile CRUD app with a REST web service OR a thin, high throughput TCP/IP based protocol could be a lot more relevant.

of course you can't realistically expect a 100% bug free or even complete code from candidates, especially if you ask for things like an "app" or a new "protocol" => what really matters is _how_ people "get to it".

github or not, I hired several exceptional people not that long ago using a piece of paper and a white board. If it is not a face to face interview, skype and/or google docs are also effective.

Re: The GitHub Job Interview

#25

Post by plunchete »

zalew wrote: post #11
plunchete wrote: post #2

Seing code is the way to go in job interviews, and in my opinion can't be compared to solve puzzles, etc. Thanks to Open Source right now there are tons of public code from people, that's why we have created masterbranch.com a service to aggregate, analyze, and list all you OS but also with the option of include non-open source code (the code is not visible if the project is not open source). Also, the idea of open s…

Hi. The idea is great, but I ran into some issues. - it took me quite a long time to find the 'Claim all your identities' - it should be in the same place I edit my profile. - after I claim one account I don't have a link to go back and claim other accounts - something is wrong with handling bitbucket projects, it sees only 2 of my projects - if I go to 'Claim all your identities' for the second time, I don't see a l…

Thanks for your feedback. I'm going to add it to our backlog.

- About the bitbucket projects, maybe the crawler didn't get all the links, you can send us projects to add going to "Missing projects? Add a project"

- About the link to go to your profile, there is a tab named "go to your profile" on the main nav-bar

- The progress bar needs explanations and also some work because is not working properly right now.

- The chart is ordered by the number of files. Probably we should order it using the number of files, commits, and the time but right now this's the order and maybe this is why is confusing to you.

Again, thanks for your feedback, appreciated.

Re: The GitHub Job Interview

#26

Post by joncooper »

I've had some success by asking a late-stage candidate to take a day off of work, then to come and pair program for a half-day with each of two developers. I paid them the appropriate consulting day rate.

Re: The GitHub Job Interview

#27

Post by latchkey »

"Not all developers have existing online projects they can point to when you're interviewing them."

After 15+ years of doing open source and being in Sr. Software Engineer positions where I've been responsible for interviewing hundreds of people, I'm convinced now that I would never hire anyone who doesn't have some sort of public online project. I don't care what it is, you must have some code to show.

Re: The GitHub Job Interview

#28

Post by geoffschmidt »

dangrossman wrote: post #6

> Being rejected after two weeks of work doesn't look good on anyone's CV Why would someone put this on their CV?

Yeah, this is a non-issue. The safest way to do it is to make them contractors for the two-week period. Nothing looks bad about a two-week consulting contract.

Some trickier issues with trial periods are:

- If they currently have a job, they will typically need to quit the other job before they can do any work for you, even if it is on nights and weekends, and even if it is unpaid. Otherwise there are serious legal issues around IP. So it's no good for poaching.

- A good candidate will have several offers. Even for a two-week trial period, they will probably need to turn down those other offers. That sucks for the candidate because it will really muddy the water with those other companies if in two weeks they want a job again. They could always get offers from other companies, but if the candidate actually wanted to work at those other companies, why didn't she interview there the first time around?

Both of these are surmountable if you are a genuinely desirable employer. For one thing you have the flexibility to talk only to awesome candidates, and awesome candidates are less likely to have problems accepting offers that they previously rejected. (Perhaps even on better terms -- it's very powerful to walk away from a negotiation while you have the upper hand.)

Re: The GitHub Job Interview

#29

Post by cunac »

latchkey wrote: post #27

"Not all developers have existing online projects they can point to when you're interviewing them." After 15+ years of doing open source and being in Sr. Software Engineer positions where I've been responsible for interviewing hundreds of people, I'm convinced now that I would never hire anyone who doesn't have some sort of public online project. I don't care what it is, you must have some code to show.

I am pretty sure that majority of people doesn't have public repository. I don't have problem showing my code but it is not public.

Re: The GitHub Job Interview

#30

Post by lucisferre »

cunac wrote: post #29
latchkey wrote: post #27

"Not all developers have existing online projects they can point to when you're interviewing them." After 15+ years of doing open source and being in Sr. Software Engineer positions where I've been responsible for interviewing hundreds of people, I'm convinced now that I would never hire anyone who doesn't have some sort of public online project. I don't care what it is, you must have some code to show.

I am pretty sure that majority of people doesn't have public repository. I don't have problem showing my code but it is not public.

Out of all the devs I respect and admire as mentors, the majority of them do have publicly contributed code and are involved in some open source project. Not to say there are not a few who don't, but I think the point is that the majority of really talented developers out there seem to have something.
Post reply on HN