5 ms·

Hiring is hard. It's very difficult to figure out what combination of activities/questions will correlate to actual job performance, not to mention uncover some

by cal5k 8y ago

Hiring is hard. It's very difficult to figure out what combination of activities/questions will correlate to actual job performance, not to mention uncover someone's day-to-day personality when their guard is up. With that said, my interview process basically is: * 30 minute intro call to dive into the CV a bit and see if it's worth everyone's time to go further * 1.5-2 hour pair programming exercise using the actual language & framework they'd most likely be using for the job * If that goes well, 30-60 minutes to meet with the team and figure out if everyone will get along That's it. No whiteboarding, no FizzBuzz, no algorithms. If we make a mistake we try to recognize it within 6 weeks of the person starting in that position.

TulliusCicero 8y ago
> * 1.5-2 hour pair programming exercise using the actual language & framework they'd most likely be using for the job This advantages people who have actually used that language/framework for prior jobs. If that's a thing you want to optimize for, then that's fine. If you want to evaluate people as more generic software developers, it's not so great. That's why whiteboarding algorithm questions can be useful. They're sufficiently abstract to generalize to lots of different 'stacks' and experience levels. If you just want to get generally competent developers first and then figure out where to put them later, then this type of question can make a lot of sense, which is why Google, Facebook, et al. use them.
- taurath 8y ago
  Algorithm questions may be more “general” than doing something like the actual work being performed, but frankly most programmers aren’t writing optimized low level algorithms on a day to day basis. All you get is people who’ve memorized the algorithm tricks.
  - TulliusCicero 8y ago
    It's not as simple as just memorizing "algorithm tricks". There are too many possible questions to just memorize all the answers, you need reasonably strong CS fundamentals, and also to be fairly smart. I think that's part of why they're used: actual IQ tests are legally fraught, but giving someone what amounts to a programming IQ test is not. It's certainly true that studying these kinds of questions helps, but if you're not too bright, I don't think that would take you very far.
    - taurath 8y ago
      Strong CS fundamentals is understanding all the various patterns and tricks in algorithms and data structures, and how they could be applied to problems outside of where you originally learned them. That is it, outside of actual CS research work, when applied to an actual software job. Ask any self taught person how much they need “CS fundamentals” to blow the pants of any business need for an app and they’ll tell you probably very little. When you’re doing tools for programmers, it gets a lot more complicated. That is not most jobs.
- cal5k 8y ago
  Generally-speaking if we're hiring someone to work in React or, say, Kotlin for Android, they need to know at least a bit about the framework they're working with. The process would be different for co-op positions/new hires directly out of school, and obviously we'd tweak it for a clearly awesome developer who is in the process of retooling.
  - UncleMeat 8y ago
    Is that really true? Learning a framework or language isn't especially arduous. My team works in C++. I have zero C++ requirement for hiring on my team because in my experience every good hire can pick it up very fast. If I restricted myself to people who can sit down and run with C++ then I'm winnowing my pool of candidates.
- lacogubik 8y ago
  My process is pretty much same as above, with the difference that I let them choose whatever framework/language they feel most comfortable with (with obvious caveat that I might not be able to help them if they get stuck). If you are good dev, you will pick up any language/frameworks quite quickly if you want to (there are exceptions, like switching to completly different paradigm e.g. from JS to Haskell, but that is not our case).
anderber 8y ago
This seems like a reasonable process. However, for me personally, I have a big portfolio of side projects with open-source code. And it irks me if a company asks me to prove my programming skills by wasting my time doing some silly tests, where if they just read my code we would be able to skip it. From all the places I've worked, the companies with the better programmers were the ones where they actually looked at your past code and had hardly any exercise or test. I think the 6-week "probation" period is an excellent idea. Since most of the time you can recognize if they are a good fit or not.
- quasse 8y ago
  One problem I have with this is that tons of people like to push the "GitHub is my resume" thing, but 75% of the time they have 25+ "forked" copies of major open source projects with maybe one or two extra commits on top. It can be a real drag to try and suss out who actually has real contributions or real original work on their GitHub. Our approach for hiring is to actually have people cherry pick out one or two items they're really proud of and have them send a brief overview / sample. That approach is also nice, because it gives you a great interview starting point to dig into a technical item that they (should be) comfortable with and passionate about.
  - anderber 8y ago
    I think that's reasonable too. I wasn't try to say "github is my resume" because in my site I point out specifically projects that I made, and link them to the repo. Making the person pick out projects they are proud of is a great idea.
  - noobiemcfoob 8y ago
    Your cherry picking idea is fine, but your reasoning for it is bs. If someone wrote the code (or read it enough to grok it), asking them some questions on the internals will sift out who just copied some free repos.
- TulliusCicero 8y ago
  > the companies with the better programmers were the ones where they actually looked at your past code How common is it to actually be able to do this? I've worked at Google and Amazon and Goldman Sachs; I can't show any of that code. I've occasionally dabbled in coding little scripts or projects at home, but nothing terribly challenging or complicated.

by cal5k 8y ago

TulliusCicero 8y ago

> * 1.5-2 hour pair programming exercise using the actual language & framework they'd most likely be using for the job This advantages people who have actually used that language/framework for prior jobs. If that's a thing you want to optimize for, then that's fine. If you want to evaluate people as more generic software developers, it's not so great. That's why whiteboarding algorithm questions can be useful. They're sufficiently abstract to generalize to lots of different 'stacks' and experience levels. If you just want to get generally competent developers first and then figure out where to put them later, then this type of question can make a lot of sense, which is why Google, Facebook, et al. use them.

taurath 8y ago
Algorithm questions may be more “general” than doing something like the actual work being performed, but frankly most programmers aren’t writing optimized low level algorithms on a day to day basis. All you get is people who’ve memorized the algorithm tricks.
- TulliusCicero 8y ago
  It's not as simple as just memorizing "algorithm tricks". There are too many possible questions to just memorize all the answers, you need reasonably strong CS fundamentals, and also to be fairly smart. I think that's part of why they're used: actual IQ tests are legally fraught, but giving someone what amounts to a programming IQ test is not. It's certainly true that studying these kinds of questions helps, but if you're not too bright, I don't think that would take you very far.
  - taurath 8y ago
    Strong CS fundamentals is understanding all the various patterns and tricks in algorithms and data structures, and how they could be applied to problems outside of where you originally learned them. That is it, outside of actual CS research work, when applied to an actual software job. Ask any self taught person how much they need “CS fundamentals” to blow the pants of any business need for an app and they’ll tell you probably very little. When you’re doing tools for programmers, it gets a lot more complicated. That is not most jobs.
cal5k 8y ago
Generally-speaking if we're hiring someone to work in React or, say, Kotlin for Android, they need to know at least a bit about the framework they're working with. The process would be different for co-op positions/new hires directly out of school, and obviously we'd tweak it for a clearly awesome developer who is in the process of retooling.
- UncleMeat 8y ago
  Is that really true? Learning a framework or language isn't especially arduous. My team works in C++. I have zero C++ requirement for hiring on my team because in my experience every good hire can pick it up very fast. If I restricted myself to people who can sit down and run with C++ then I'm winnowing my pool of candidates.
lacogubik 8y ago
My process is pretty much same as above, with the difference that I let them choose whatever framework/language they feel most comfortable with (with obvious caveat that I might not be able to help them if they get stuck). If you are good dev, you will pick up any language/frameworks quite quickly if you want to (there are exceptions, like switching to completly different paradigm e.g. from JS to Haskell, but that is not our case).

anderber 8y ago

This seems like a reasonable process. However, for me personally, I have a big portfolio of side projects with open-source code. And it irks me if a company asks me to prove my programming skills by wasting my time doing some silly tests, where if they just read my code we would be able to skip it. From all the places I've worked, the companies with the better programmers were the ones where they actually looked at your past code and had hardly any exercise or test. I think the 6-week "probation" period is an excellent idea. Since most of the time you can recognize if they are a good fit or not.

quasse 8y ago
One problem I have with this is that tons of people like to push the "GitHub is my resume" thing, but 75% of the time they have 25+ "forked" copies of major open source projects with maybe one or two extra commits on top. It can be a real drag to try and suss out who actually has real contributions or real original work on their GitHub. Our approach for hiring is to actually have people cherry pick out one or two items they're really proud of and have them send a brief overview / sample. That approach is also nice, because it gives you a great interview starting point to dig into a technical item that they (should be) comfortable with and passionate about.
- anderber 8y ago
  I think that's reasonable too. I wasn't try to say "github is my resume" because in my site I point out specifically projects that I made, and link them to the repo. Making the person pick out projects they are proud of is a great idea.
- noobiemcfoob 8y ago
  Your cherry picking idea is fine, but your reasoning for it is bs. If someone wrote the code (or read it enough to grok it), asking them some questions on the internals will sift out who just copied some free repos.
TulliusCicero 8y ago
> the companies with the better programmers were the ones where they actually looked at your past code How common is it to actually be able to do this? I've worked at Google and Amazon and Goldman Sachs; I can't show any of that code. I've occasionally dabbled in coding little scripts or projects at home, but nothing terribly challenging or complicated.