2 ms·

As a potential candidate, all of the standard complaints ring true - but once you're on the other side of the equation, and need to hire people... your ability

As a potential candidate, all of the standard complaints ring true - but once you're on the other side of the equation, and need to hire people... your ability to create new interviews is not nearly as wide or as clear as it would seem from the outside. 1) Take home test: OK for performance metrics, bad for "getting to know" the candidate, and terrible for selling the candidate on your company 2) Daylong interview: Expensive, requires interrupting our team, needs a fully planned and well executed itinerary - but is perfect for getting to know someone, getting the feel for their personality and interests, and is the best way to sell someone on the opportunity. 3) Work sample: we usually do this for interns[1] and pair it with a ~1 hour conversation (either before or after, doesn't really matter to us) on what the company is like and what they would be working on. Obviously, work samples suffer from the same deficiencies as a take home test for cultural fit and the like, but it's the best we can do for interns! [1] https://gastrograph.com/blogs/gastronexus/interviewing-data-science-interns.html https://gastrograph.com/blogs/gastronexus/interviewing-data-...

rm_-rf_slash 11y ago
I've said elsewhere on this thread, but my absolute favorite technical interview method is to set up a contract to pay the candidate to create a feature or fix a bug on your codebase, and have it merge and work as expected. It lets the candidate feel (literally) valued by your company, and you get to learn how they do the job you are hiring them to do.
- hire_charts 11y ago
  Agreed that this is a great approach, but the major downside is that you are limiting yourself to candidates who either: a) have the time to do real work outside of their day job and aren't on a restrictive contract preventing them from moonlighting, or... b) are currently unemployed
  - rm_-rf_slash 11y ago
    I was a college student at the time. I was long on money and short on cash. I was also far less experienced than I was so there were a lot of new things for me then, like those fascinating "callback" thingies I had to figure out. Nowadays if I were given roughly the same assignment it would have taken me about 3-5 hours at best, which, given my graduated-and-employed hourly rate, is actually quite in line with what I was paid. So it paid as much as I would have charged for a Saturday hack.

rm_-rf_slash 11y ago

I've said elsewhere on this thread, but my absolute favorite technical interview method is to set up a contract to pay the candidate to create a feature or fix a bug on your codebase, and have it merge and work as expected. It lets the candidate feel (literally) valued by your company, and you get to learn how they do the job you are hiring them to do.

hire_charts 11y ago
Agreed that this is a great approach, but the major downside is that you are limiting yourself to candidates who either: a) have the time to do real work outside of their day job and aren't on a restrictive contract preventing them from moonlighting, or... b) are currently unemployed
- rm_-rf_slash 11y ago
  I was a college student at the time. I was long on money and short on cash. I was also far less experienced than I was so there were a lot of new things for me then, like those fascinating "callback" thingies I had to figure out. Nowadays if I were given roughly the same assignment it would have taken me about 3-5 hours at best, which, given my graduated-and-employed hourly rate, is actually quite in line with what I was paid. So it paid as much as I would have charged for a Saturday hack.