
The Tech Recruitment Process at Drivy - marcgg
https://drivy.engineering/tech-recruitment-process/
======
hack_edu
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.

~~~
marcgg
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.

~~~
Bahamut
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, especially since the requirements were
written in a way where candidates were encouraged to dump a lot of time into
them. My schedule was filled with many high stakes interviews, which was
mentally exhausting. It simply is not in my interest to do a take home
project, as it reduces the number of companies I can simultaneously interview
at.

~~~
marcgg
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.

~~~
computereye
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

------
dasmoth
_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?

~~~
_asummers
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
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

~~~
CodeMage
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.

~~~
marcgg
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 :)

~~~
jcalabro
>"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.

~~~
marcgg
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.

------
forgottenacc57
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.

------
peteretep
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
Thanks! So far it's been also very interesting on our end to discuss "real
life" problems

