Coding for 20 years | Working for startups for 10 years | Team leader and mentor | More information about me: https://thevaluable.dev/page/about/
Twitter: @Cneude_Matthieu
I would argue that you can see if a candidate "can spot a compile error" when the IDE turns to red by only asking question. I'm always mesmerized of the crazy answers I have to "what's an interface? What's the purpose of it"? It does already A LOT of sorting.
For the trial days, it depends on your on boarding. I know what you mean though; once, we invited a candidate for a trial day. Only running our project on his laptop took 4 hours. Not because trial days are terrible, but because our documentation was bad and our set up too complicated. We fixed that, and it was not a problem anymore. The good side of the experience: it showed us a big problem we had.
This is the only kind of on boarding you need, I think. You need to explain quickly the goal of the application as well, and then let he candidate implementing little stuff or fix small bugs. Some open source projects are very good at that, to have more contributors. I take the inspiration from them.
For the home tests, you can't guarantee that it will only be used in the frame of the recruitment. If you read it and learn something from it, your candidate already gave his knowledge against nothing. We are knowledge worker, our worth is (partly) our knowledge.
That being said, your process seems focusing on what's important, which bring me to the eternal conclusion that the tools themselves are not bad, but the way you use them can be bad. I saw too many recruiters / hiring managers being so picky on the way to do stuff (if it's not their way, it's the wrong way), or on the knowledge somebody should have on a precise framework, or not judging enough the soft skills, that I prefer not spending time on tests and such. Especially since, in my experience, they precede any form of discussion.
Another thing: the problem to me as well is that the interview process is often going in one way, judging the candidate. The candidate should have an idea about the company as well, the culture, how people like it. It's very difficult to have most of the time and it's essential, because if your candidate is not motivated to work in your company, everybody will regret it.
Tests don't really show you how the candidate will be in your team either, and it's very important too. If you look at the research done on the subject, it's even more important than the skills of a single developer. So why focusing on that?
These are just thoughts. It's an interesting subject, which is unfortunately too often "space vs tab" kind of discussion. I think your process is quite good, but I think as well there is always room to improvement.
Oh don't get me wrong, we have lots of room for improvement - and to a large degree, that's why I can't even think about trial periods at the moment. Though, we had 2 juniors start recently that were pointed at a repository and nothing more, and they had 3 of our 27 components running within a day, and a day later were confident enough to start estimating tickets. One of those juniors is fresh out of university, never worked as a developer.
Ultimately, I only really care for juniors "do you know the language, and how quickly will you tell me that you're stuck on a problem?" The latter being a very fine line, obviously. For seniors, all I care about is "can you learn quickly, and can you communicate well both up & down the ladder."
I get your point on giving free knowledge away, but really, we're talking about things that you could search online & find out. Case in point here, I spoke to a Senior candidate yesterday, and during his code-review stage, I mentioned he had a lot of getters & setters, so I asked if he'd used Lombok before (we are a Java "shop"), with a view to branching the discussion towards AOP vs readability. He made a quick note on some paper he had at the side, and admitted he hasn't. There were a number of times this happened, with various technologies - and he scored better with me because not only did he admitted his gaps quickly, he made a note and genuinely seemed interested to check it out regardless of the outcome of the interview. I don't know yet if I'll hire him or not, but if not, he's learnt some things for free and I really don't mind sharing them.
Tests don't really show you how the candidate will be in your team either
I know, which is why the tests that I give (other than "spot the missing semi-colon" stuff for juniors - which is done in an IDE and the IDE is screaming at you to tell you where it should be) - are geared towards discussion points. I'd rather try to work out how a candidate thinks rather than what they currently know/think.
the tools themselves are not bad, but the way you use them can be bad.
I couldn't agree more - I've seen my fair share of poor recruitment processes. Ours used to be horrendous, and I had to answer maybe 20 or so Java "riddles" using pen & paper for my interview here! So when I moved into a more managerial position, I immediately moved the process to one that I'd like to go through as a candidate. Juniors get one Skype call and a decision, Seniors get a take-home test, one Skype call, and a decision.
I highly doubt I have it right for every candidate, but I'll tweak as I go, and my whole point for reading all the comments on this article, was to see if others had better ideas that I could "steal" (and in some cases, there have been, and I have).
Coding for 20 years | Working for startups for 10 years | Team leader and mentor | More information about me: https://thevaluable.dev/page/about/
Twitter: @Cneude_Matthieu
I would argue that you can see if a candidate "can spot a compile error" when the IDE turns to red by only asking question. I'm always mesmerized of the crazy answers I have to "what's an interface? What's the purpose of it"? It does already A LOT of sorting.
For the trial days, it depends on your on boarding. I know what you mean though; once, we invited a candidate for a trial day. Only running our project on his laptop took 4 hours. Not because trial days are terrible, but because our documentation was bad and our set up too complicated. We fixed that, and it was not a problem anymore. The good side of the experience: it showed us a big problem we had.
This is the only kind of on boarding you need, I think. You need to explain quickly the goal of the application as well, and then let he candidate implementing little stuff or fix small bugs. Some open source projects are very good at that, to have more contributors. I take the inspiration from them.
For the home tests, you can't guarantee that it will only be used in the frame of the recruitment. If you read it and learn something from it, your candidate already gave his knowledge against nothing. We are knowledge worker, our worth is (partly) our knowledge.
That being said, your process seems focusing on what's important, which bring me to the eternal conclusion that the tools themselves are not bad, but the way you use them can be bad. I saw too many recruiters / hiring managers being so picky on the way to do stuff (if it's not their way, it's the wrong way), or on the knowledge somebody should have on a precise framework, or not judging enough the soft skills, that I prefer not spending time on tests and such. Especially since, in my experience, they precede any form of discussion.
Another thing: the problem to me as well is that the interview process is often going in one way, judging the candidate. The candidate should have an idea about the company as well, the culture, how people like it. It's very difficult to have most of the time and it's essential, because if your candidate is not motivated to work in your company, everybody will regret it.
Tests don't really show you how the candidate will be in your team either, and it's very important too. If you look at the research done on the subject, it's even more important than the skills of a single developer. So why focusing on that?
These are just thoughts. It's an interesting subject, which is unfortunately too often "space vs tab" kind of discussion. I think your process is quite good, but I think as well there is always room to improvement.
Oh don't get me wrong, we have lots of room for improvement - and to a large degree, that's why I can't even think about trial periods at the moment. Though, we had 2 juniors start recently that were pointed at a repository and nothing more, and they had 3 of our 27 components running within a day, and a day later were confident enough to start estimating tickets. One of those juniors is fresh out of university, never worked as a developer.
Ultimately, I only really care for juniors "do you know the language, and how quickly will you tell me that you're stuck on a problem?" The latter being a very fine line, obviously. For seniors, all I care about is "can you learn quickly, and can you communicate well both up & down the ladder."
I get your point on giving free knowledge away, but really, we're talking about things that you could search online & find out. Case in point here, I spoke to a Senior candidate yesterday, and during his code-review stage, I mentioned he had a lot of getters & setters, so I asked if he'd used Lombok before (we are a Java "shop"), with a view to branching the discussion towards AOP vs readability. He made a quick note on some paper he had at the side, and admitted he hasn't. There were a number of times this happened, with various technologies - and he scored better with me because not only did he admitted his gaps quickly, he made a note and genuinely seemed interested to check it out regardless of the outcome of the interview. I don't know yet if I'll hire him or not, but if not, he's learnt some things for free and I really don't mind sharing them.
I know, which is why the tests that I give (other than "spot the missing semi-colon" stuff for juniors - which is done in an IDE and the IDE is screaming at you to tell you where it should be) - are geared towards discussion points. I'd rather try to work out how a candidate thinks rather than what they currently know/think.
I couldn't agree more - I've seen my fair share of poor recruitment processes. Ours used to be horrendous, and I had to answer maybe 20 or so Java "riddles" using pen & paper for my interview here! So when I moved into a more managerial position, I immediately moved the process to one that I'd like to go through as a candidate. Juniors get one Skype call and a decision, Seniors get a take-home test, one Skype call, and a decision.
I highly doubt I have it right for every candidate, but I'll tweak as I go, and my whole point for reading all the comments on this article, was to see if others had better ideas that I could "steal" (and in some cases, there have been, and I have).
Interesting. I like your approach. Thanks for that!