While I agree with many of your points, as I've said on now dozens of these posts, there's one problem you're overlooking: we have to be able to verify your skills!
Live coding is the only way we can get to know how you approach coding! It's not just about getting code running; it all comes down to how.
We owe it to all our employees, and to you if we hire you, to actually make sure all hirees can code. Believe it or not, there are applicants who are actually just clever disguised outsource brokers, and others who cannot code but apply for jobs whose minimum requirements are many miles beyond their abilities.
Rather, a good interview involves live coding something practical, and the interviewer should know how to account for nerves.
Personally, I like pairing the take-home and live coding together, for a few reasons.
I actually appreciate take-homes, even when I'm doing a lot of applying myself, because it gives me a taste of what that job's coding is like. I can self-eliminate myself in some cases; in the least, I learn something I can use later.
If the live coding builds on the take-home, it's less "surprising". The applicant knows the code; they wrote it. (And if the applicant outsourced the code, it becomes immediately apparent.)
A real job will have naturally occurring high-pressure situations, not by conspiracy of an evil boss, but because stuff happens. Prod goes down. The product is late. A bug has shipped. Whatever the situation, it's helpful to see if someone can still think critically if they're nervous. No, their performance won't be at its peak, but a good interviewer can account for that.
In eight years, I've learned that if someone's bravado is so strong, they can march into a final interview and go through the whole thing without any nerves, they've got an ego the size of Ontario, and will not be an asset to the team. Nerves tell me there's a real human there. (Seriously, I second-guessed this for years, only to discover it was entirely accurate.)
By the way, in the near decade I've been doing this, very few female applicants (maybe one in eight years) or minority applicants (less than a quarter, same as for white males) actually struggle with the live coding. There are plenty of candidates, in roughly equal proportions for the different demographics, who self-eliminated from the process, because the take-home made it clear to them they weren't ready for this yet, so it saved us both time.
But, all that aside, yes, nuke the whiteboarding and fizz-buzz. Take-homes and live coding are good, I'd even argue, utterly indispensable for hiring well, but only if they're based on an original, practical, job-related premise.
Unfortunately, if you were to tell developers to just walk out on any company that uses live coding, you can almost guarantee that the job they'll get will be with an unvetted team, which they will almost certainly wind up having to carry.
Thanks for the response. No offense but I call bullshit on some of these (for the lack of a better expression I could think of)
we have to be able to verify your skills!
There are multiple different ways to verify someone's skills. Some I could think of right now
Give them a small take home and ask to explain the approach and if you find issues in implementation discuss about that. It will tell you if the person did it or not (I guess you mention this above so I assume you agree).
See if the person has a GitHub account, most people do these days, look at what they have done.
Have a one on one discussion about the skills they say they have, talk about technology, architecture and so on, look for the ability to learn
Have a field day with them at the office, show them what you do, ask for their opinion. Have honest discussions
I agree there might be some people who can't code but they will be very easy to catch once you have a discussion with them. You don't have to put everyone through unnecessary stress or some bad actors
I agree with the take-home stuff but not with live coding. Even if live coding is built on top of take-home it still induces performance anxiety and you can't expect every interviewer to understand and evaluate accordingly. So this is not realistic or fair IMO
I'm talking about performance anxiety and imposter syndrome, the real-life high-pressure situations are quite different. any decent developer will be able to handle that. I have experienced such situations many times in my career (I once accidentally deleted a production DB on the night of a critical cutover for a huge airline, so imagine the pressure to restore and go live before morning) and was able to do my job quite well but I still suffer from performance anxiety. I also know a lot of developers with performance anxiety who have never broken down during a high-pressure work situation. So high-pressure != performance anxiety and I really don't believe you need to evaluate for that unless you are doing rocket launch and stuff like that maybe
I get your POV though, you are saying that even when you do live coding and such you are aware of the issue and you take them into consideration, but my experience is that not everyone does that. But still why put someone through that pressure. It's quite emotionally and psychologically nerve-wracking. The person applying for the job might already be having many issues (Jobless, desperate, family issues, money issues, and so on) why add more stress to that?
It's possible that your didn't encounter people who struggled or many of them did struggle but got through it without showing it (which also happens a lot) especially if the problem given was easier and the interviewer was very friendly but that doesn't mean the problem doesn't exist. Look at the research paper I linked chrisparnin.me/pdf/stress_FSE_20.pdf
I disagree with your last point about unvetted team, you are assuming live coding is the only way to evaluate. I have had 3 jobs in a decade and all three didn't involve any live coding and these were amazing teams I worked with and you can find 1000s of similar testimony. I have interviewed for some amazing companies with no live coding involved in the process, one of them was my dream team but unfortunately, I didn't make it
Well, we will definitely never agree on this point. You didn't "call B.S." on anything validly, but I understand your views are based on your personal experience.
Just please recognize that, as you (from what you've said) have little to no experience managing or hiring for a team, your ideas are based largely on conjecture and largely unevaluated theories. I'm speaking out of having done this for many years.
Just please be aware of where your expertise stops; it is all too easy to misguide young developers into making career-devastating decisions.
Yes lets agree to disagree. And I'm not expecting everyone to agree anyway. Btw I never said that I haven't done hiring or managed teams. I have done both. I was part of the company wide hiring team in 2 out of 3 companies I worked for and in a decade of being in IT I have been a project manager and team lead on multiple occasions so I'm not talking without experience here.
And I believe I'm not misguiding young developers here, I'm specifically asking people who have a say to speak up and others to honestly tell the interviews how they feel. We need to be more realistic and straightforward in this Industry. You are entitled to your opinion the same way I'm entitled to mine so lets stop accusing each other of anything. Cheers
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
You know, I'm stealing some of your approach - I actually did it be accident (before reading your comment).
I have a take home test, designed so that there is no wrong answer to it. The only way to fail it is to write a horrible mess that makes my brain hurt - but you'd never know that, because failing it doesn't necessarily mean a rejection.
The part I'm stealing, is adding requirements to it as live coding on Skype.
As an offer of exchange - I use whiteboard during the interview. But it's not really a test. It's a "draw me the architecture of the current system that you're employer has right now" followed by "ok, talk me through a problem you've had to solve with it."
I figure, if they can't do that, they've not been paying attention in their current role.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
While I agree with many of your points, as I've said on now dozens of these posts, there's one problem you're overlooking: we have to be able to verify your skills!
Live coding is the only way we can get to know how you approach coding! It's not just about getting code running; it all comes down to how.
We owe it to all our employees, and to you if we hire you, to actually make sure all hirees can code. Believe it or not, there are applicants who are actually just clever disguised outsource brokers, and others who cannot code but apply for jobs whose minimum requirements are many miles beyond their abilities.
Rather, a good interview involves live coding something practical, and the interviewer should know how to account for nerves.
Personally, I like pairing the take-home and live coding together, for a few reasons.
I actually appreciate take-homes, even when I'm doing a lot of applying myself, because it gives me a taste of what that job's coding is like. I can self-eliminate myself in some cases; in the least, I learn something I can use later.
If the live coding builds on the take-home, it's less "surprising". The applicant knows the code; they wrote it. (And if the applicant outsourced the code, it becomes immediately apparent.)
A real job will have naturally occurring high-pressure situations, not by conspiracy of an evil boss, but because stuff happens. Prod goes down. The product is late. A bug has shipped. Whatever the situation, it's helpful to see if someone can still think critically if they're nervous. No, their performance won't be at its peak, but a good interviewer can account for that.
In eight years, I've learned that if someone's bravado is so strong, they can march into a final interview and go through the whole thing without any nerves, they've got an ego the size of Ontario, and will not be an asset to the team. Nerves tell me there's a real human there. (Seriously, I second-guessed this for years, only to discover it was entirely accurate.)
By the way, in the near decade I've been doing this, very few female applicants (maybe one in eight years) or minority applicants (less than a quarter, same as for white males) actually struggle with the live coding. There are plenty of candidates, in roughly equal proportions for the different demographics, who self-eliminated from the process, because the take-home made it clear to them they weren't ready for this yet, so it saved us both time.
But, all that aside, yes, nuke the whiteboarding and fizz-buzz. Take-homes and live coding are good, I'd even argue, utterly indispensable for hiring well, but only if they're based on an original, practical, job-related premise.
Unfortunately, if you were to tell developers to just walk out on any company that uses live coding, you can almost guarantee that the job they'll get will be with an unvetted team, which they will almost certainly wind up having to carry.
Thanks for the response. No offense but I call bullshit on some of these (for the lack of a better expression I could think of)
There are multiple different ways to verify someone's skills. Some I could think of right now
I agree there might be some people who can't code but they will be very easy to catch once you have a discussion with them. You don't have to put everyone through unnecessary stress or some bad actors
I agree with the take-home stuff but not with live coding. Even if live coding is built on top of take-home it still induces performance anxiety and you can't expect every interviewer to understand and evaluate accordingly. So this is not realistic or fair IMO
I'm talking about performance anxiety and imposter syndrome, the real-life high-pressure situations are quite different. any decent developer will be able to handle that. I have experienced such situations many times in my career (I once accidentally deleted a production DB on the night of a critical cutover for a huge airline, so imagine the pressure to restore and go live before morning) and was able to do my job quite well but I still suffer from performance anxiety. I also know a lot of developers with performance anxiety who have never broken down during a high-pressure work situation. So high-pressure != performance anxiety and I really don't believe you need to evaluate for that unless you are doing rocket launch and stuff like that maybe
I get your POV though, you are saying that even when you do live coding and such you are aware of the issue and you take them into consideration, but my experience is that not everyone does that. But still why put someone through that pressure. It's quite emotionally and psychologically nerve-wracking. The person applying for the job might already be having many issues (Jobless, desperate, family issues, money issues, and so on) why add more stress to that?
It's possible that your didn't encounter people who struggled or many of them did struggle but got through it without showing it (which also happens a lot) especially if the problem given was easier and the interviewer was very friendly but that doesn't mean the problem doesn't exist. Look at the research paper I linked chrisparnin.me/pdf/stress_FSE_20.pdf
I disagree with your last point about unvetted team, you are assuming live coding is the only way to evaluate. I have had 3 jobs in a decade and all three didn't involve any live coding and these were amazing teams I worked with and you can find 1000s of similar testimony. I have interviewed for some amazing companies with no live coding involved in the process, one of them was my dream team but unfortunately, I didn't make it
Again thank you for sharing your POV
Well, we will definitely never agree on this point. You didn't "call B.S." on anything validly, but I understand your views are based on your personal experience.
Just please recognize that, as you (from what you've said) have little to no experience managing or hiring for a team, your ideas are based largely on conjecture and largely unevaluated theories. I'm speaking out of having done this for many years.
Just please be aware of where your expertise stops; it is all too easy to misguide young developers into making career-devastating decisions.
Yes lets agree to disagree. And I'm not expecting everyone to agree anyway. Btw I never said that I haven't done hiring or managed teams. I have done both. I was part of the company wide hiring team in 2 out of 3 companies I worked for and in a decade of being in IT I have been a project manager and team lead on multiple occasions so I'm not talking without experience here.
And I believe I'm not misguiding young developers here, I'm specifically asking people who have a say to speak up and others to honestly tell the interviews how they feel. We need to be more realistic and straightforward in this Industry. You are entitled to your opinion the same way I'm entitled to mine so lets stop accusing each other of anything. Cheers
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!
You know, I'm stealing some of your approach - I actually did it be accident (before reading your comment).
I have a take home test, designed so that there is no wrong answer to it. The only way to fail it is to write a horrible mess that makes my brain hurt - but you'd never know that, because failing it doesn't necessarily mean a rejection.
The part I'm stealing, is adding requirements to it as live coding on Skype.
As an offer of exchange - I use whiteboard during the interview. But it's not really a test. It's a "draw me the architecture of the current system that you're employer has right now" followed by "ok, talk me through a problem you've had to solve with it."
I figure, if they can't do that, they've not been paying attention in their current role.