The GitHub Job Interview • Hacker News Board

Re: The GitHub Job Interview

#41

Post by rhizome » Sun, Jan 08, 2012, 10:12 PM UTC

teyc wrote: post #35

rhizome wrote: post #13

Earlier quoted context omitted.

Why go through all this complication? Use bugs that have actually occurred in your app , repurpose those into coding problems, and see how the prospect solves it. You might be surprised that they fix the bug better than your existing employees (or you).

Production code baes are never trivial enough for a quick test. They usually require a deep understanding of domain. Have you ever tried to fix an open bug on a GitHub project? It is non-trivial.

Well you don't give them the entire codebase, you package the bug-that-was-fixed into a tiny example app. I think it probably goes without saying to exclude changes in business rules.

Is this not closer to the actual job than Pascal's Triangle?

Re: The GitHub Job Interview

#42

Post by teyc » Mon, Jan 09, 2012, 12:32 AM UTC

rhizome wrote: post #41

teyc wrote: post #35

Earlier quoted context omitted.

Production code baes are never trivial enough for a quick test. They usually require a deep understanding of domain. Have you ever tried to fix an open bug on a GitHub project? It is non-trivial.

Well you don't give them the entire codebase, you package the bug-that-was-fixed into a tiny example app. I think it probably goes without saying to exclude changes in business rules. Is this not closer to the actual job than Pascal's Triangle?

oh I see. I agree with you entirely.

Re: The GitHub Job Interview

#43

Post by latchkey » Mon, Jan 09, 2012, 3:22 AM UTC

tzs wrote: post #38

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.

If I were being interviewed by you I'd have a question: "If you hire me, can you guarantee that either (1) I'll be contributing to open source as part of the job, or (2) the job will leave me with enough free time and energy that I will have both the time and desire to do programming outside of work on open source?". If your answer was "no", then my follow up question would be "so basically you wouldn't hire someone…

I think you are missing the point. This isn't about the job you are going to be doing, this is about getting me to even consider you for a job.

To answer your questions though:

(1) I'd expect you to continue doing open source, as both part of the job and on your own. I do it, so should you. Case in point, we just integrated our site with WePay. WePay didn't have Java API, so I wrote one (along with my business partner) and we made it open source [a]. This benefited my company, open source and WePay all in one shot. This isn't the only one, I can point at many more large projects [b], [c], [d] (for just a short list) that we've either open sourced ourselves or contributed to. I have a clear history of coding in multiple languages. Anyone who is going to hire me knows my skill set without having to give me silly brain teasers or even read a resume. Why would anyone want to hire someone without a clear record like that?

(2) How you spend your time is up to you. There is a certain amount of work that needs to get done as part of the job and I'd expect that to get done. As long as you are getting your work done, in a reasonable time and of a good quality, I'm fine with whatever you do with your time. If that 'policy' doesn't leave you with enough energy, then I'd suggest either learning how to do better time management or find another profession / company.

As I already said, I wouldn't hire someone without seeing their source code. The single best way to really see it is to see how they've contributed and worked with open source projects. Bonus points if you find a unique project to create yourself.

[a] https://github.com/lookfirst/WePay-Java-SDK [b] http://objectify-appengine.googlecode.com [c] http://batchfb.googlecode.com [d] https://github.com/lookfirst/bootstrap

Re: The GitHub Job Interview

#44

Post by assaf_lavie » Tue, Jan 10, 2012, 10:19 AM UTC

saldfiae3 wrote: post #23

assaf_lavie wrote: post #18

Earlier quoted context omitted.

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-sourc…

It's true that you'll have more impact by contributing to a well-known project, but on the other hand the range of activities you can take part in is limited. Well-established projects usually don't call for high-level design activities - the sort that a tech co-founder would need to do. They're more about contributing patches and perhaps a new feature (after you've learned the project, which is usually quite big). Ultimately I think you get the same amount of karma if you work on a pet project and not a well-established one. And there's absolutely no reason why the company's sandbox project can't fill a real need and become popular with time.