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
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!