3 ms·

The Tech Recruitment Process at Drivy

23 points by marcgg 9y ago

peteretep 9y ago
I'm elbow deep in all parts of the recruitment process, and the take-home test and "bring some sample code in" are much superior to anything algorithm-y or whiteboard-y, so +1
- marcgg 9y ago
  Thanks! So far it's been also very interesting on our end to discuss "real life" problems
dasmoth 9y ago
or the codebase from a previous position That was a little startling. Other than open source companies, how many employers would be happy to know their code is being shown off to potential future employers?
- forgottenacc57 9y ago
  Presumably this company is happy for you to take their codebase and walk your next potential employer through it. Probably their competition.
  - marcgg 9y ago
    I don't think that there much one can learn by looking at a couple of classes. On our end we let the candidate decide based on their previous company's policies.
- marcgg 9y ago
  Yes, some people prefer not to share this and it is totally fine by us. It's really up to the candidate to decide in accordance to the previous company's policies. Personally I wouldn't mind if a previous employee would like to demonstrate his/her work using the codebase - as long as they're not applying to a competing firm :) We also have a lot of people that created their own companies or interesting side projects that will present this.
- _asummers 9y ago
  That whole section needs an alternate. Enough people are NDA etc. bound that you're going to have qualified people who literally can't do this step. Many people don't have large software written in the public domain or do not have anything showable because they don't have access to the source anymore. It'd be awesome if everyone had enterprise level software on GitHub, but that seems an unfair requirement to show technical competency for closed software.
  - marcgg 9y ago
    We accept any kind of code, be it a kata made during a workshop or a side project... really we just want to talk about code that the candidate wrote previously. It doesn't need to be large to have interesting tradeoffs made
    - _asummers 9y ago
      That ignores the class of FOSS people I like to call the "fixers", the ones that will spelunk a code base because they have a problem, find the 10 line fix that fixes their issue and never come back to the project again. Those 10 lines were probably very useful but doesn't show any larger design ability, despite that being a thing the candidate may be very good at, or large enough to garner a gauge on how that person sees code. Also consider the people who have never contributed to open source because they leave their work at the door. This is all your prerogative on how you want to run this, but I was personally put off reading that section, despite having a good idea what you're looking for. out of it
      - marcgg 9y ago
        Yes it's true that it doesn't fit all use cases. However I would see looking at a few of the fixes you're talking about as an interesting technical interview.
    - CodeMage 9y ago
      Why? You already gave the candidate a "take home assignment". That assignment should involve interesting trade-offs. If it doesn't, tweak it until it does. Why not discuss that code? I'm the kind of guy who still likes to code on the side, at home, for fun, after all these years, but I'm also aware that not everyone is like that. Maybe that's one of your filters -- maybe you're looking for people who prefer coding to be 90% of their lives -- but that would be a big red flag in my book. I've seen too many companies who think that they are entitled to employees who will give them everything for next-to-nothing in return.
- JustSomeNobody 9y ago
  Yeah this caught me off guard. Had to read it again. I'm pretty sure I'm not legally allowed to possess the code from previous employment contracts.
  - thesmallestcat 9y ago
    Not to mention that it's basic programmer ethics, the person who paid you owns the code.
hack_edu 9y ago
To start, thanks for the self-submitted promo piece on your company. If you want publicity, earn it. You ought to make a statement about this fact in the comment section. Or, submit this using an official account. Here is basically how it goes: - Phone screening - Take home assignment - "Resume” interview - Technical interview - Product interview - Interview with another team - Finalizing the hire This might seem that there are a lot of steps… and maybe it’s true. However we feel that it’s good for both parties if they get a good look at what working together would be like. Are you kidding me? That is more time spent interviewing with you than the legal French work week. Who has time for that? I don't know about Paris, most candidates would laugh in the face of your recruiter. Those that don't are push-overs with nothing better to do. Put yourself in someone else's shoes and imagine going through 7 days of 1-4hr interviews, concurrently, with a half dozen other companies at the same time. What makes your company so elite? Prove it. Some some respect.
- deleted 9y ago
  [deleted]
- marcgg 9y ago
  If you sum it all up, it is less than a day. The phone screening is ~20 minutes, the assignment takes a couple of hours and so on. I think it's fair to expect that a candidate is willing to invest at least 5-6 hours in an interview process. Compared to what I've seen before (full day interviews, freelance period etc) this seems fair to me. But like you comment proves, it might not be for everybody.
  - hack_edu 9y ago
    If this is the case, you are merely writing a piece of "our interview process is entirely average." I don't know about you, but 5-6 hours is standard. What's the point of breaking out your day-of process into 4 bullet points if its just the same as your normal engineering interview? Fluff. Finally, realize that your candidates (just like your Eng org) spend much more time prepping for your interview than you quantify on paper. However much they choose to is up to them, but don't pretend you're doing them a favor.
forgottenacc57 9y ago
Why is this on the front page? There's nothing here but the standard steps in a recruiting process, more or less. Some clever upvoting by the team at drivy. Flag it out folks.

23 points by marcgg 9y ago

I'm elbow deep in all parts of the recruitment process, and the take-home test and "bring some sample code in" are much superior to anything algorithm-y or whiteboard-y, so +1

marcgg 9y ago
Thanks! So far it's been also very interesting on our end to discuss "real life" problems

dasmoth 9y ago

or the codebase from a previous position That was a little startling. Other than open source companies, how many employers would be happy to know their code is being shown off to potential future employers?

forgottenacc57 9y ago
Presumably this company is happy for you to take their codebase and walk your next potential employer through it. Probably their competition.
- marcgg 9y ago
  I don't think that there much one can learn by looking at a couple of classes. On our end we let the candidate decide based on their previous company's policies.
marcgg 9y ago
Yes, some people prefer not to share this and it is totally fine by us. It's really up to the candidate to decide in accordance to the previous company's policies. Personally I wouldn't mind if a previous employee would like to demonstrate his/her work using the codebase - as long as they're not applying to a competing firm :) We also have a lot of people that created their own companies or interesting side projects that will present this.
_asummers 9y ago
That whole section needs an alternate. Enough people are NDA etc. bound that you're going to have qualified people who literally can't do this step. Many people don't have large software written in the public domain or do not have anything showable because they don't have access to the source anymore. It'd be awesome if everyone had enterprise level software on GitHub, but that seems an unfair requirement to show technical competency for closed software.
- marcgg 9y ago
  We accept any kind of code, be it a kata made during a workshop or a side project... really we just want to talk about code that the candidate wrote previously. It doesn't need to be large to have interesting tradeoffs made
  - _asummers 9y ago
    That ignores the class of FOSS people I like to call the "fixers", the ones that will spelunk a code base because they have a problem, find the 10 line fix that fixes their issue and never come back to the project again. Those 10 lines were probably very useful but doesn't show any larger design ability, despite that being a thing the candidate may be very good at, or large enough to garner a gauge on how that person sees code. Also consider the people who have never contributed to open source because they leave their work at the door. This is all your prerogative on how you want to run this, but I was personally put off reading that section, despite having a good idea what you're looking for. out of it
    - marcgg 9y ago
      Yes it's true that it doesn't fit all use cases. However I would see looking at a few of the fixes you're talking about as an interesting technical interview.
  - CodeMage 9y ago
    Why? You already gave the candidate a "take home assignment". That assignment should involve interesting trade-offs. If it doesn't, tweak it until it does. Why not discuss that code? I'm the kind of guy who still likes to code on the side, at home, for fun, after all these years, but I'm also aware that not everyone is like that. Maybe that's one of your filters -- maybe you're looking for people who prefer coding to be 90% of their lives -- but that would be a big red flag in my book. I've seen too many companies who think that they are entitled to employees who will give them everything for next-to-nothing in return.
JustSomeNobody 9y ago
Yeah this caught me off guard. Had to read it again. I'm pretty sure I'm not legally allowed to possess the code from previous employment contracts.
- thesmallestcat 9y ago
  Not to mention that it's basic programmer ethics, the person who paid you owns the code.

hack_edu 9y ago

To start, thanks for the self-submitted promo piece on your company. If you want publicity, earn it. You ought to make a statement about this fact in the comment section. Or, submit this using an official account. Here is basically how it goes: - Phone screening - Take home assignment - "Resume” interview - Technical interview - Product interview - Interview with another team - Finalizing the hire This might seem that there are a lot of steps… and maybe it’s true. However we feel that it’s good for both parties if they get a good look at what working together would be like. Are you kidding me? That is more time spent interviewing with you than the legal French work week. Who has time for that? I don't know about Paris, most candidates would laugh in the face of your recruiter. Those that don't are push-overs with nothing better to do. Put yourself in someone else's shoes and imagine going through 7 days of 1-4hr interviews, concurrently, with a half dozen other companies at the same time. What makes your company so elite? Prove it. Some some respect.

deleted 9y ago
[deleted]
marcgg 9y ago
If you sum it all up, it is less than a day. The phone screening is ~20 minutes, the assignment takes a couple of hours and so on. I think it's fair to expect that a candidate is willing to invest at least 5-6 hours in an interview process. Compared to what I've seen before (full day interviews, freelance period etc) this seems fair to me. But like you comment proves, it might not be for everybody.
- hack_edu 9y ago
  If this is the case, you are merely writing a piece of "our interview process is entirely average." I don't know about you, but 5-6 hours is standard. What's the point of breaking out your day-of process into 4 bullet points if its just the same as your normal engineering interview? Fluff. Finally, realize that your candidates (just like your Eng org) spend much more time prepping for your interview than you quantify on paper. However much they choose to is up to them, but don't pretend you're doing them a favor.

forgottenacc57 9y ago

Why is this on the front page? There's nothing here but the standard steps in a recruiting process, more or less. Some clever upvoting by the team at drivy. Flag it out folks.