Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Tech Recruitment Process at Drivy

drivy.engineering

Post reply on HN
Print view View original

21–29 of 29 posts

Re: The Tech Recruitment Process at Drivy

#21

Post by marcgg »

CodeMage wrote: post #19
marcgg wrote: post #12

Earlier quoted context omitted.

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

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…

Sometimes we do discuss this code if the candidate prefers. But it's still a somewhat "fake" code made for the only purpose to apply at the company. Most people would find it more interesting to discuss code they spent weeks on.

Finally we are not looking for any specific profile, but so far almost every person found a piece of code to share from their career. We don't get thousands of applicants, so maybe we're not seeing the issue just yet. If it turns out to be a problem, we'll change the process :)

Re: The Tech Recruitment Process at Drivy

#22

Post by CodeMage »

marcgg wrote: post #20
hack_edu wrote: post #15

Earlier quoted context omitted.

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…

I never said our interview process was perfect, I mainly wanted to share it because I saw a lot of people complaining about whiteboard coding and so on... so I figured it could be interesting to some to see a less exhausting alternative.

Just a small observation: whiteboard coding is not inherently wrong. Bad experiences with whiteboard coding usually come from dealing with companies with broken hiring process, where simply eliminating whiteboard coding and replacing it with something else wouldn't help.

Re: The Tech Recruitment Process at Drivy

#23

Post by marcgg »

Bahamut wrote: post #18
marcgg wrote: post #10

Earlier quoted context omitted.

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.

A take home assignment alone is likely more than a work day, if not multiples - I'll take a 7 hour onsite interview gauntlet over that any day. The only side this process seems to be favorable for is the company interviewing. To give a flip side, I just finished interviewing with over 10 companies in a rigorous search. Of those, two did take home tests, and ultimately I didn't have the time to complete either, especi…

From experience we saw that for most people doing the coding test was only taking ~an evening which seems reasonable as it removes the need for more on site discussions.

I guess that it's true that the take home assignment is not optimal if you interviews with more than 10 companies and in this case we must be loosing some candidates.

Re: The Tech Recruitment Process at Drivy

#24

Post by marcgg »

_asummers wrote: post #16
marcgg wrote: post #12

Earlier quoted context omitted.

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

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…

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.

Re: The Tech Recruitment Process at Drivy

#25

Post by marcgg »

CodeMage wrote: post #22
marcgg wrote: post #20

Earlier quoted context omitted.

I never said our interview process was perfect, I mainly wanted to share it because I saw a lot of people complaining about whiteboard coding and so on... so I figured it could be interesting to some to see a less exhausting alternative.

Just a small observation: whiteboard coding is not inherently wrong. Bad experiences with whiteboard coding usually come from dealing with companies with broken hiring process, where simply eliminating whiteboard coding and replacing it with something else wouldn't help.

I completely agree, this was just an example of a common complain.

Re: The Tech Recruitment Process at Drivy

#26

Post by jcalabro »

marcgg wrote: post #21
CodeMage wrote: post #19

Earlier quoted context omitted.

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…

Sometimes we do discuss this code if the candidate prefers. But it's still a somewhat "fake" code made for the only purpose to apply at the company. Most people would find it more interesting to discuss code they spent weeks on. Finally we are not looking for any specific profile, but so far almost every person found a piece of code to share from their career. We don't get thousands of applicants, so maybe we're not…

>"We accept any kind of code, be it a kata made during a workshop or a side project"

>"But it's still a somewhat "fake" code made for the only purpose to apply at the company"

The code I write for side projects is not "production quality" because I do it for my own entertainment. I would never feel comfortable showing it off in an interview because it doesn't represent me professionally. All of my positions have been strictly closed-source.

Additionally, the code I write for side projects is usually unlike the work I'd be doing professionally. I'm a web developer but most of the side projects I work on are either dinky little video games or open source hardware.

I'll cede that I do find my side projects more interesting to talk about but I generally try and write "high-ish quality code" (not "fake") for the take home interview projects that I've had to do.

Re: The Tech Recruitment Process at Drivy

#27

Post by marcgg »

jcalabro wrote: post #26
marcgg wrote: post #21

Earlier quoted context omitted.

Sometimes we do discuss this code if the candidate prefers. But it's still a somewhat "fake" code made for the only purpose to apply at the company. Most people would find it more interesting to discuss code they spent weeks on. Finally we are not looking for any specific profile, but so far almost every person found a piece of code to share from their career. We don't get thousands of applicants, so maybe we're not…

>"We accept any kind of code, be it a kata made during a workshop or a side project" >"But it's still a somewhat "fake" code made for the only purpose to apply at the company" The code I write for side projects is not "production quality" because I do it for my own entertainment. I would never feel comfortable showing it off in an interview because it doesn't represent me professionally. All of my positions have been…

As I mentioned in the article, we don't expect the code presented to be "perfect" code. If you've managed to get a side project running very quickly thanks to tradeoffs you've made, it's also interesting. It's really just a way to have a place to discuss choices.

Re: The Tech Recruitment Process at Drivy

#28

Post by computereye »

marcgg wrote: post #23
Bahamut wrote: post #18

Earlier quoted context omitted.

A take home assignment alone is likely more than a work day, if not multiples - I'll take a 7 hour onsite interview gauntlet over that any day. The only side this process seems to be favorable for is the company interviewing. To give a flip side, I just finished interviewing with over 10 companies in a rigorous search. Of those, two did take home tests, and ultimately I didn't have the time to complete either, especi…

From experience we saw that for most people doing the coding test was only taking ~an evening which seems reasonable as it removes the need for more on site discussions. I guess that it's true that the take home assignment is not optimal if you interviews with more than 10 companies and in this case we must be loosing some candidates.

They lie. Most candidates will tell you the coding exercise took less than it actually did because 1) they want to appear efficient 2) you said it would take only 3 hours so if they say it took 8 hours it would look like a failure

Source: me, last week, for another company. Plus, programming is not just writing code, most technical interviewers will want to see the global design, unit tests, comments, etc... Which are not accounted for in the expected time

Re: The Tech Recruitment Process at Drivy

#29

Post by thesmallestcat »

JustSomeNobody wrote: post #13
dasmoth wrote: post #3

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?

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.

Not to mention that it's basic programmer ethics, the person who paid you owns the code.
Post reply on HN