4 ms·

Github projects, OSS contributions, and StackOverflow questions, are imperfect measurements and can be inaccessible to a large number of developers. Github is b

by tmpz22 6y ago

Github projects, OSS contributions, and StackOverflow questions, are imperfect measurements and can be inaccessible to a large number of developers. Github is banned in some countries, many OSS projects are english only, and stack overflow moderation needs no introduction, to name a few examples. Imagine if github became a ledger where you are now judged by the shitty code you wrote when you were 20. Remove older repos? You'll be scrutinized for having a "gap in your resume". The system is imperfect but is there actually a better alternative that fits the economic and cultural needs of our society? FWIW I'm on your side, interviewing gives me the worst anxiety in the world even though my career has progressed to the point where I can consistently get an on-site interview.

alexandercrohde 6y ago
Moreover, imagine for just one second that github became the defacto way to interview candidates. Now every candidate starts hacking their github full of all kinds of code, or even paying people to, or copying work to create a perfectly manicured "facebooked" version of what their work looks like (probably with fake timestamps too). Suddenly that signal becomes entirely worthless too. I think tech has one the best interviewing processes of all industries.
- dvt 6y ago
  > Now every candidate starts hacking their github full of all kinds of code, or even paying people to, or copying work to create a perfectly manicured "facebooked" version of what their work looks like (probably with fake timestamps too). I'm of the opinion that going over someone's GitHub code (asking about design decisions, language alternatives, testing, algorithm choices) during an interview is probably orders of magnitutde more valuable than having them implement a linked list. But to each their own.
  - battery_cowboy 6y ago
    Not everyone likes to work on code in their free time, though, and code from work is often not public. How do you suggest people like that get jobs then?
    - karatestomp 6y ago
      Shit 40 hours is already 35% of my waking hours in a week, including weekends. Factor in that a lot of places extend hours by 30-60min to account for lunch ("9-5" my ass) and then commute time for most folks, and tons of people are already giving half their waking hours to their job. How much more time am I supposed to spend clickety-clacking code into a computer while ruining my health? Zero. Zero should be the answer. Because 40 hours is already a hell of a lot.
  - jkaptur 6y ago
    I think you're comparing an idealized version of a GitHub-based interview to a, at best, mediocre version of a whiteboard coding interview.
dvt 6y ago
> Github projects, OSS contributions, and StackOverflow questions, are imperfect measurements and can be inaccessible to a large number of developers. I fundamentally reject this premise and your arguments are orthogonal (GitHub being banned in like Syria and most OSS projects being in English is just flimsy hand-waving).
- detaro 6y ago
  How do you intend to deal with developers that have little to no Github activity?
  - dvt 6y ago
    Take-homes, other OSS contributions, StackOverflow activity... GitHub isn't the only code outlet in the world. If I'd hire a writer, I'd like to see writing samples. If I hire a coder, I want to see coding samples.
    - devalgo 6y ago
      Excuse me sir, those writing samples are irrelevant. Could easily be plagiarized. I prefer to test my writers on arcane grammar in the languages they supposedly speak in high pressure situations.
      - karatestomp 6y ago
        "Well these novels all look fine, Mr. Stephen King, but you see there are just so many fakers out there and even though you can talk very well about the process of writing a book in a way that only someone who either actually did know how to write or who was so wonderfully skilled at faking it that they'd be able to make more money applying that skill directly to a job that called for it (have you met our CEO, incidentally?), but oh my, yes, there are so many fakers, yes I'm sure there are a lot, it must be that our bad hires have been fakers who tricked us and not that environment, process, team, and management quality significantly affect people's performance in various ways and that we're badly deficient in some of those areas—anyway, point is, next we're going to quiz you on obscure citation format details across three different citation styles, have you sentence-diagram and label all the parts of speech of every word in the first chapter of Moby Dick (should only take you 5 minutes or we'll start obviously betraying that we think you're an idiot), and then write out for us the subjunctive mood conjugation of a few irregular French verbs." "Uh, will I be doing much of that on the job?" "Oh god no. Where do you think you are? This is Buzzfeed. You'll be hammering together barely-coherent prose that's just shy of stolen and publishing it as fast as possible." ^ your average programming interview with whiteboard grilling.
nickdandakis 6y ago
Yes, there is. Extract a piece of work from the project the new hire will be working on. Set up scaffolding and any boilerplate so that only have to implement one new feature (or fix one bug). Give it to another employee or yourself and solve it while recording how long it took. If someone that's familiar with the project took 4 hours, simplify. If someone that's unfamiliar with the project took 1-2 hours to solve, send it out to candidates. If you can't do any of the above, you might have process issues that you need to solve prior to getting a new hire in the first place. Oh, and if the take-home exercise is expected to take 4+ hours, pay the candidates to do the exercise.
- renewiltord 6y ago
  How many hires have you made using this process? It is interesting in that the cost scales per person significantly. If I'm putting that much effort into the candidate, I think I've already determined I want him. I've definitely used a candidate's original work on Github to evaluate their skill but we still spoke about career objectives and culture. Honestly, I doubt that guy wouldn't have aced the technical interview anyway. It just saved us both time to not do it.
  - nickdandakis 6y ago
    I've hired a handful of people with this process, across two organizations. First time around, I identified and created the take-home exercise in one working day. Half of it was actually setting things up, the second half was solving it myself and tweaking it such that it takes the amount of time I was aiming for. Second time around it took a half day total. I'm not saying you shouldn't look at a Github profile or any code samples the candidate sends over. However, those metrics aren't good aptitude indicators. I feel the same way about algorithm-style coding tests that a lot of companies follow. Sure, let me find all the anagrams in a set of words only to land a job writing REST APIs... I don't see how the cost scales per person significantly. You create one take-home exercise per role you're hiring for. You send the same take-home exercise to any candidates that apply for the role. Worst-case scenario, it takes too much time to compile this take-home exercise, in which case you've hopefully spent the time to smooth out your processes which leads to an easier onboarding. Best-case scenario, you've compiled a take-home exercise in a reasonable amount of time, which verifies that onboarding will be smooth for the new hire. To your point, the take-home is for candidates in the 2nd or 3rd round of interviewing where you've verified their experience, you've verified their character/soft skills, and need to verify their aptitude/hard skills.

by tmpz22 6y ago

alexandercrohde 6y ago

Moreover, imagine for just one second that github became the defacto way to interview candidates. Now every candidate starts hacking their github full of all kinds of code, or even paying people to, or copying work to create a perfectly manicured "facebooked" version of what their work looks like (probably with fake timestamps too). Suddenly that signal becomes entirely worthless too. I think tech has one the best interviewing processes of all industries.

dvt 6y ago
> Now every candidate starts hacking their github full of all kinds of code, or even paying people to, or copying work to create a perfectly manicured "facebooked" version of what their work looks like (probably with fake timestamps too). I'm of the opinion that going over someone's GitHub code (asking about design decisions, language alternatives, testing, algorithm choices) during an interview is probably orders of magnitutde more valuable than having them implement a linked list. But to each their own.
- battery_cowboy 6y ago
  Not everyone likes to work on code in their free time, though, and code from work is often not public. How do you suggest people like that get jobs then?
  - karatestomp 6y ago
    Shit 40 hours is already 35% of my waking hours in a week, including weekends. Factor in that a lot of places extend hours by 30-60min to account for lunch ("9-5" my ass) and then commute time for most folks, and tons of people are already giving half their waking hours to their job. How much more time am I supposed to spend clickety-clacking code into a computer while ruining my health? Zero. Zero should be the answer. Because 40 hours is already a hell of a lot.
- jkaptur 6y ago
  I think you're comparing an idealized version of a GitHub-based interview to a, at best, mediocre version of a whiteboard coding interview.

dvt 6y ago

> Github projects, OSS contributions, and StackOverflow questions, are imperfect measurements and can be inaccessible to a large number of developers. I fundamentally reject this premise and your arguments are orthogonal (GitHub being banned in like Syria and most OSS projects being in English is just flimsy hand-waving).

detaro 6y ago
How do you intend to deal with developers that have little to no Github activity?
- dvt 6y ago
  Take-homes, other OSS contributions, StackOverflow activity... GitHub isn't the only code outlet in the world. If I'd hire a writer, I'd like to see writing samples. If I hire a coder, I want to see coding samples.
  - devalgo 6y ago
    Excuse me sir, those writing samples are irrelevant. Could easily be plagiarized. I prefer to test my writers on arcane grammar in the languages they supposedly speak in high pressure situations.
    - karatestomp 6y ago
      "Well these novels all look fine, Mr. Stephen King, but you see there are just so many fakers out there and even though you can talk very well about the process of writing a book in a way that only someone who either actually did know how to write or who was so wonderfully skilled at faking it that they'd be able to make more money applying that skill directly to a job that called for it (have you met our CEO, incidentally?), but oh my, yes, there are so many fakers, yes I'm sure there are a lot, it must be that our bad hires have been fakers who tricked us and not that environment, process, team, and management quality significantly affect people's performance in various ways and that we're badly deficient in some of those areas—anyway, point is, next we're going to quiz you on obscure citation format details across three different citation styles, have you sentence-diagram and label all the parts of speech of every word in the first chapter of Moby Dick (should only take you 5 minutes or we'll start obviously betraying that we think you're an idiot), and then write out for us the subjunctive mood conjugation of a few irregular French verbs." "Uh, will I be doing much of that on the job?" "Oh god no. Where do you think you are? This is Buzzfeed. You'll be hammering together barely-coherent prose that's just shy of stolen and publishing it as fast as possible." ^ your average programming interview with whiteboard grilling.

nickdandakis 6y ago

Yes, there is. Extract a piece of work from the project the new hire will be working on. Set up scaffolding and any boilerplate so that only have to implement one new feature (or fix one bug). Give it to another employee or yourself and solve it while recording how long it took. If someone that's familiar with the project took 4 hours, simplify. If someone that's unfamiliar with the project took 1-2 hours to solve, send it out to candidates. If you can't do any of the above, you might have process issues that you need to solve prior to getting a new hire in the first place. Oh, and if the take-home exercise is expected to take 4+ hours, pay the candidates to do the exercise.

renewiltord 6y ago
How many hires have you made using this process? It is interesting in that the cost scales per person significantly. If I'm putting that much effort into the candidate, I think I've already determined I want him. I've definitely used a candidate's original work on Github to evaluate their skill but we still spoke about career objectives and culture. Honestly, I doubt that guy wouldn't have aced the technical interview anyway. It just saved us both time to not do it.
- nickdandakis 6y ago
  I've hired a handful of people with this process, across two organizations. First time around, I identified and created the take-home exercise in one working day. Half of it was actually setting things up, the second half was solving it myself and tweaking it such that it takes the amount of time I was aiming for. Second time around it took a half day total. I'm not saying you shouldn't look at a Github profile or any code samples the candidate sends over. However, those metrics aren't good aptitude indicators. I feel the same way about algorithm-style coding tests that a lot of companies follow. Sure, let me find all the anagrams in a set of words only to land a job writing REST APIs... I don't see how the cost scales per person significantly. You create one take-home exercise per role you're hiring for. You send the same take-home exercise to any candidates that apply for the role. Worst-case scenario, it takes too much time to compile this take-home exercise, in which case you've hopefully spent the time to smooth out your processes which leads to an easier onboarding. Best-case scenario, you've compiled a take-home exercise in a reasonable amount of time, which verifies that onboarding will be smooth for the new hire. To your point, the take-home is for candidates in the 2nd or 3rd round of interviewing where you've verified their experience, you've verified their character/soft skills, and need to verify their aptitude/hard skills.