Hacker News Reader

Comment by paulitex | Hacker News Reader

Github (and similar evidence of actual abilities) are already making questions like these extinct, thank god. Reading through a single project an applicant has written themselves is immensely more informative than these silly CS brain teasers: actual solutions to actual problems, style & documentation habits, testing practices, evidence of being able to code & ship, being a self starter, etc... Classic example of actions speak louder than words. Thankfully the technology is now in place so that resumes can be replaced with coding community profiles, and interviews can focus on filling in the blanks and assessing the compatibility of the applicant as a person.

View on HN

I definitely agree that for a startup team, Github is making CS interview questions extinct. Even github itself claims so: http://ozmm.org/posts/who_we_hire.html - "at GitHub we hire "The Girl or Guy Who Wrote X," where X is an awesome project we all use or admire."

However, it is a different question if you are running a company like Google or Facebook. For instance, recently there was a news that Google received > 75,000 applicants and is looking to grow by more than 5000 employees this year. http://goo.gl/9fpkt

If you want to scale at this level, you won't have time to look at Github or similar sites for every candidate in detail. There will also be great candidates who have never published their code (although they might be the minority). To maintain hiring standards in this kind of situation efficiently, asking very difficult algorithmic questions might be the only way to go - at least you will be able to maintain the same hiring standards for 75,000 applicants.

Public code repositories are the first place I go when I look at applicants.

Surprisingly, however, public code rarely tells you anything about a user's CS fundamentals. Can they tell me the time complexity of a method they just wrote? Do they know the difference between a depth first and breadth first search?

I've met individuals with good code who were unable to answer CS 101 level questions like that. It's not a deal breaker, but it needs to be given some weight and consideration in hiring. It's also a matter of seniority -- I would never offer a senior developer position to someone who didn't have CS fundamentals because I expect such a person to solve hard problems that fall outside of "hacking up a webapp".

i think you and i must have taken very different CS 101 courses. CS 101 where i came from was "learn you some control flow, for great mediocrity".

Possibly the difference between "Computer Science" and "Computer Studies"?

i don't think so. CompSci 101 is gonna be stuff like fizz-buzz. you're gonna learn the absolute basics: loops, conditionals, maybe even functions, depending on how the course is structured. but depth-vs.-breadth? calculating big O, or even what big O is? that's not intro level stuff. it's certainly important, and i agree that you should think long and hard before hiring someone for a senior role if they can't handle that kind of stuff. i just strongly disagree with categorizing it as introductory.

You're right, I didn't literally mean CS 101. In fact, at my university I believe the class was CS 1511.

What I mean is, "Things that a CS major probably should have been exposed to in his or her first year of college."

The University of Cambridge's computer science course includes big-O notation in the first term. It is introductory.

Look at it like any other subject: you spend a lot of time analysing and understanding existing work before you make new work. Why would it be different for computer science?

The introductory course syllabus is at http://www.cl.cam.ac.uk/teaching/1011/CST/node11.html if you're interested.

While I'd love to agree, reading someone's code does not tell you:

1) If they actually wrote all of it, or if it derivative of someone else's work. 2) Whether any particular function took them 10 minutes or 10 hours. 3) What options they considered when choosing how to architect a particular solution. 4) Why they made any particular choice in their solutions. 5) Whether or not they will fit on your team, take constructive criticism, etc.

The questions posed in the article don't give you those answers either, but the applicant's speed at answering, their confidence, they demeanor as you ask further questions and discuss answers... all that communication does answer most of the above questions.

http://github.com/raganwald

1. Do you look at my github and wonder whether I wrote it or copied it from elsewhere?

2. What do you care if anything I wrote took me ten minutes or ten hours? And with rewrite_rails, the answer is more like ten months. Is that a problem? Are you looking for LOC/hour or for a certain approach to thinking about programming?

3. A trivial coding problem will not answer this question any more than Github will, but you can always just ask: "Reg, I'm looking at Faux, and I wonder, what other approaches did you consider before settling on pushing application logic down into the browser?"

4. See above.

5. "Reg, #andand seriously sucks. This is pervasive nil checking dressed up in metaprogramming clothing with opening core classes as a third deadly sin. Before I consign your soul to the abyss, what do you have to say in your defense?"

I can say on #2 that clients I've worked with aren't specifically thinking of LOC/hour, but they do want people who are able to be reasonably productive. Everyone's definition of reasonable is different (obviously). Looking at, say, a 50 line block of code, I'd certainly prefer to know if it took someone a couple of days to arrive at that solution vs, oh, say, 18 months.

Not everyone works at the same speed, but for certain types of problems and industries, knowing that you can put out reasonable quality work in a reasonable amount of time helps people get an idea of how to plan out other parts of the project.

I'd rather know someone can do fizzbuzz in a few minutes vs 8 hours.

I find it very hard to look at anything non-trivial and figure out what is slow, about right, and fast. For example, #andand (I keep using this example because many people have heard of it, not because I'm foolish enough to think this is good work on my part).

I guess that after Benjamin Stein and I discussed the problem and one of us (I can't remember whom) said "I wish there was an and-and-dot operator in Ruby," there was a rough implementation written fairly soon after.

But the thing on my Github now probably has a hundred hours of work refactoring, dealing with edge cases, adding new functionality like .andand { |foo| ... } and so on. I wouldn't be surprised if the LOC/hr. has dropped below one at this point. And that's without considering the rewrite_rails version which uses AST rewriting.

So for that purpose, I agree that a fizzbuzz given on the spot is far superior to looking at someone's Github projects. Thanks for the valuable comment.

I guess we're thinking about somewhat different things. "I find it very hard to look at anything non-trivial" and in most cases the interviews I've been involved have tended to involved 'trivial' cases, where in some cases the interviewer wasn't sure of the right answer, they just knew some of the common 'wrong' ones to weed people out.

  > While I'd love to agree, reading someone's code does not
  > tell you:

Neither will asking about linked lists.

The false negative rate of the hiring strategy you advocate would be significantly higher that the traditional programming interviews. There certainly is a fraction of otherwise competent programmers who would fail to write the linked list code because of the interview conditions (stress, time pressure, whiteboard etc.). What is that fraction? 50%? 70%? I'm guessing no higher than that. Now, what is the fraction of competent programmers who haven't written any open-source code? I'm guessing 95%.

Also, the cost of inspecting carefully enough someone's open-source code is way higher than evaluating their answer to an interview question.

Also, at the risk of stating the obvious, if a significant fraction of employers started looking at the candidates' open-source contributions, all new grads would start producing open-source-spam projects, further decreasing the usefulness of this signal.

Are Github and open source projects turning programmers toward a portfolio based resume?

I've had success in interviews initially linking to my github repo and letting the interviewer view for themselves what I can accomplish. It has been a good diving board when you start talking in person.

Yeah except Interviewers assume by default that you don't know how to program and you somehow cheated and got someone else to write your open source project.

Reply on news.ycombinator.com