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
No you don't. You need to be able to measure the interest somebody has in the job. You have to measure how your candidate can adapt. The knowledge of today will be different from the one tomorrow, so what the point to measure something which will change?
Another question: how do the candidate evaluate the company? 'cause you know, it doesn't only go in one sense.
Even if the candidate is a liar, as you say, you can still ask him some questions he won't be able to answer. Example: what's an interface, or whatever other construct in the language of your choice.
Even better: there is the trial period. Or a trial day. The candidate can see how the company work and see if he or she likes it; you can see how he or she adapts to your real work. Win win. You have to pay him or her, of course.
The go home stuff: I'm sick of them. Spending hours, not payed, on tests? Not my thing, thanks. Especially if, on the other hand, people who interview the candidate learn some stuff from his or her test. It's called working for free.
I'm not even going to take the time to respond to your points. While I will not make any assumptions or comments about you as a person or your intelligence, as to the ideas outlined here, there is nothing even approaching a rational proposal in your entire post. I would strongly encourage you to get some practical experience hiring; after a few years of seeing things from the other side of the table, you'll understand why your proposals are altogether irrational from any stance: practical, interpersonal, or logistical.
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
Well, I'm glad you've apparently been lucky to only ever get qualified, honest candidates and work for companies with boundless time and money, who can take on the significant costs and legal risks of "test hiring" all these candidates. Count your blessings; very few (if any) people in hiring get to work under such perfect circumstances.
Meanwhile, I've never gotten a complaint from anyone, including from the diverse set of employees who later got to participate in and give feedback ON the hiring process, nor from anyone in the career services departments of the universities I work with. Seeing as the way I'm doing things was developed over years, with exponentially more care, compassion, and attention to the interpersonal components than you imagine (read "accuse"), based on what worked and what profoundly did not, I'll stick to what actually works.
For everyone else reading: I urge everyone NOT to take Matthieu's advice about what is acceptable in hiring into account when job hunting. From someone who fights long and hard for compassion, communication, and diversity in tech, I assure you, the hypothesis he forth is based in utopic ideals, not the daily realities of business. Burning a bridge at one company can close many good doors elsewhere. Don't burn opportunities just because you don't want to put in a couple hours of unpaid effort into the process (the company is already spending a lot of time and money just to consider you), or because you're paranoid they'll "steal" your take-home work (baseless: we already have a solution long since written for it, and you're probably not Donald Knuth). It's reasonable to set boundaries for yourself, but the hard reality is skills must be verified somehow, out of respect for you AND the rest of the team!
Job searching is hard on both interviewers and interviewees. Hiring managers are not automatically malicious bad-actors. We don't know you from Adam. Expect to prove yourself, to the same degree you expect us to prove ourselves. That's how this works in any skills-based industry, and tech is no different.
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
For somebody who speaks about compassion, your post seems a bit... aggressive. I'm sorry if you misinterpreted my opinion, I was just saying what I was thinking.
Compassion doesn't mean that I'm not going to be passionate.
As someone who has been in charge of hiring for the same company for many years, I've seen some excellent candidates...as well as some absolutely horrific displays of behavior from some candidates. Both ends of the spectrum are only consistent with what other hiring managers I'm acquainted with have seen, I later learned.
I've also watched a pervasive attitude of sheer entitlement creep into the job-hunting process, whereby applicants are beginning to feel that they should never have to prove anything, should be paid for their time (not accounting for the money and time the employer already spends on the process), and should be somehow given a sort of "consolation prize" if they're not hired. And after venting that attitude freely, they can't figure out why no one, not even the gentlest interviewers, will give them a job.
So yes, I do get passionate about this topic. Job searching a difficult process on both parties. Typically, when people start representing employers who use, say, live coding and take-homes as somehow malicious bad actors, that's because they are failing to account for the reasons those things were introduced into the process in the first place.
You can say what you think to a point, but you absolutely must think about how a young developer is going to take it, and what the worst possible outcome is. Just venting your opinion in a public place where it will mislead someone with less experience than you is socially irresponsible at best.
To put it frankly, no one has ever died (or, I'd wager, even suffered long term harm) from live coding; I'd even defy anyone to provide a single provable instance of a reputable employer "stealing" the "free work" from a take-home assignment.
In the end, it's because of my compassion that I get angry about this. I'm thinking of all the people who may read your post and be misguided into a treacherous and career-stalling path because "that one guy says employers shouldn't be vetting my skills, so I guess I'll just walk if they do!"
P.S. I've learned that 98% of situations where an opinion was "misunderstood" or "misinterpreted", the correct word is actually "miscommunicated". This is precisely why I seldom use the former two words when I feel like my point isn't understood; I instead take responsibility to clarify. It's not my job to read your mind, it's your job to be clear.
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
You look very sure about yourself, and you conclude many things I've never said.
I'm not as sure to be right as you are, that's why I experimented a few things in the hiring process, and I will continue to do so if I have the occasion. Because if I stay convinced in a set of ideas and I'm ready to fight for it blindly, I will never experiment, learn and bring new knowledge to improve the situation.
If you think I'm dangerous, I'm sorry you feel that way.
I have experimented, too. As I've said before, the process I follow is based on years of trial-and-error, with a strong emphasis on compassion and communication. I've experimented extensively, and only adopted live coding and take-home assignments after discovering the necessity for them. I'm only more confident in my stance by nature of those years of experience, experimentation, and learning.
I'm sorry if you actually believe I meant "you are dangerous." I absolutely believe that how you stated your opinions is dangerous, but I can't find where I said you were. Just in case that separation between person and idea wasn't clear, I am only debating the validity and wisdom of your idea.
Yes, I need to know candidates skills - to the level of "do you know the core language?"
I don't care for most frameworks, they're transient, but if you can't spot a compile error glowing bright red at you in an IDE, please don't waste my time.
I agree with you that I have to measure how a candidate can adapt, but as the author of the article talks about performance anxiety - how do we measure adaptability without risking performance anxiety?
Trial periods, even a day, are terrible, in my opinion. I don't care about paying the candidate for it, I care about the costs to the rest of the team, starting onboarding for someone who simply may not be there tomorrow because they don't like it, or they had a better offer etc.
Your point on take home tests - I use one (for senior candidates). It's very clearly spelled out that we won't be using it for anything other than the recruitment process, and that a passable solution can be done in an hour, but feel free to take a week if you like.
Every submission of it that I've had, I've not even run a build against it - I literally don't care if it fulfills the requirements given, it's just too give talking points in the interview.
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
No you don't. You need to be able to measure the interest somebody has in the job. You have to measure how your candidate can adapt. The knowledge of today will be different from the one tomorrow, so what the point to measure something which will change?
Another question: how do the candidate evaluate the company? 'cause you know, it doesn't only go in one sense.
Even if the candidate is a liar, as you say, you can still ask him some questions he won't be able to answer. Example: what's an interface, or whatever other construct in the language of your choice.
Even better: there is the trial period. Or a trial day. The candidate can see how the company work and see if he or she likes it; you can see how he or she adapts to your real work. Win win. You have to pay him or her, of course.
The go home stuff: I'm sick of them. Spending hours, not payed, on tests? Not my thing, thanks. Especially if, on the other hand, people who interview the candidate learn some stuff from his or her test. It's called working for free.
I'm not even going to take the time to respond to your points. While I will not make any assumptions or comments about you as a person or your intelligence, as to the ideas outlined here, there is nothing even approaching a rational proposal in your entire post. I would strongly encourage you to get some practical experience hiring; after a few years of seeing things from the other side of the table, you'll understand why your proposals are altogether irrational from any stance: practical, interpersonal, or logistical.
I have some practical experience hiring, and it works quite well.
Well, I'm glad you've apparently been lucky to only ever get qualified, honest candidates and work for companies with boundless time and money, who can take on the significant costs and legal risks of "test hiring" all these candidates. Count your blessings; very few (if any) people in hiring get to work under such perfect circumstances.
Meanwhile, I've never gotten a complaint from anyone, including from the diverse set of employees who later got to participate in and give feedback ON the hiring process, nor from anyone in the career services departments of the universities I work with. Seeing as the way I'm doing things was developed over years, with exponentially more care, compassion, and attention to the interpersonal components than you imagine (read "accuse"), based on what worked and what profoundly did not, I'll stick to what actually works.
For everyone else reading: I urge everyone NOT to take Matthieu's advice about what is acceptable in hiring into account when job hunting. From someone who fights long and hard for compassion, communication, and diversity in tech, I assure you, the hypothesis he forth is based in utopic ideals, not the daily realities of business. Burning a bridge at one company can close many good doors elsewhere. Don't burn opportunities just because you don't want to put in a couple hours of unpaid effort into the process (the company is already spending a lot of time and money just to consider you), or because you're paranoid they'll "steal" your take-home work (baseless: we already have a solution long since written for it, and you're probably not Donald Knuth). It's reasonable to set boundaries for yourself, but the hard reality is skills must be verified somehow, out of respect for you AND the rest of the team!
Job searching is hard on both interviewers and interviewees. Hiring managers are not automatically malicious bad-actors. We don't know you from Adam. Expect to prove yourself, to the same degree you expect us to prove ourselves. That's how this works in any skills-based industry, and tech is no different.
For somebody who speaks about compassion, your post seems a bit... aggressive. I'm sorry if you misinterpreted my opinion, I was just saying what I was thinking.
I'm an idealist for sure, but, as John Lennon was saying, I'm not the only one..
Compassion doesn't mean that I'm not going to be passionate.
As someone who has been in charge of hiring for the same company for many years, I've seen some excellent candidates...as well as some absolutely horrific displays of behavior from some candidates. Both ends of the spectrum are only consistent with what other hiring managers I'm acquainted with have seen, I later learned.
I've also watched a pervasive attitude of sheer entitlement creep into the job-hunting process, whereby applicants are beginning to feel that they should never have to prove anything, should be paid for their time (not accounting for the money and time the employer already spends on the process), and should be somehow given a sort of "consolation prize" if they're not hired. And after venting that attitude freely, they can't figure out why no one, not even the gentlest interviewers, will give them a job.
So yes, I do get passionate about this topic. Job searching a difficult process on both parties. Typically, when people start representing employers who use, say, live coding and take-homes as somehow malicious bad actors, that's because they are failing to account for the reasons those things were introduced into the process in the first place.
You can say what you think to a point, but you absolutely must think about how a young developer is going to take it, and what the worst possible outcome is. Just venting your opinion in a public place where it will mislead someone with less experience than you is socially irresponsible at best.
To put it frankly, no one has ever died (or, I'd wager, even suffered long term harm) from live coding; I'd even defy anyone to provide a single provable instance of a reputable employer "stealing" the "free work" from a take-home assignment.
In the end, it's because of my compassion that I get angry about this. I'm thinking of all the people who may read your post and be misguided into a treacherous and career-stalling path because "that one guy says employers shouldn't be vetting my skills, so I guess I'll just walk if they do!"
P.S. I've learned that 98% of situations where an opinion was "misunderstood" or "misinterpreted", the correct word is actually "miscommunicated". This is precisely why I seldom use the former two words when I feel like my point isn't understood; I instead take responsibility to clarify. It's not my job to read your mind, it's your job to be clear.
You look very sure about yourself, and you conclude many things I've never said.
I'm not as sure to be right as you are, that's why I experimented a few things in the hiring process, and I will continue to do so if I have the occasion. Because if I stay convinced in a set of ideas and I'm ready to fight for it blindly, I will never experiment, learn and bring new knowledge to improve the situation.
If you think I'm dangerous, I'm sorry you feel that way.
I have experimented, too. As I've said before, the process I follow is based on years of trial-and-error, with a strong emphasis on compassion and communication. I've experimented extensively, and only adopted live coding and take-home assignments after discovering the necessity for them. I'm only more confident in my stance by nature of those years of experience, experimentation, and learning.
I'm sorry if you actually believe I meant "you are dangerous." I absolutely believe that how you stated your opinions is dangerous, but I can't find where I said you were. Just in case that separation between person and idea wasn't clear, I am only debating the validity and wisdom of your idea.
I'm a hiring manager.
Yes, I need to know candidates skills - to the level of "do you know the core language?"
I don't care for most frameworks, they're transient, but if you can't spot a compile error glowing bright red at you in an IDE, please don't waste my time.
I agree with you that I have to measure how a candidate can adapt, but as the author of the article talks about performance anxiety - how do we measure adaptability without risking performance anxiety?
Trial periods, even a day, are terrible, in my opinion. I don't care about paying the candidate for it, I care about the costs to the rest of the team, starting onboarding for someone who simply may not be there tomorrow because they don't like it, or they had a better offer etc.
Your point on take home tests - I use one (for senior candidates). It's very clearly spelled out that we won't be using it for anything other than the recruitment process, and that a passable solution can be done in an hour, but feel free to take a week if you like.
Every submission of it that I've had, I've not even run a build against it - I literally don't care if it fulfills the requirements given, it's just too give talking points in the interview.
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!