Ask HN: Why are hiring processes flawed and testing random standards?
69 comments
In a nutshell: they aren't.
The economics of it are that in many places in the world, it is extremely difficult to fire an employee. Getting rid of an underperformer can take time, effort, and exposes the company to liability if the termination can be construed as relating to the employee being in a protected class (e.g. can't fire someone because she's a woman). Let's assume that it's a SF startup willing to play a little fast and loose and they aren't concerned with severance packages or the legal issues. They still put time and effort into training a new engineer. That's months of work that is potentially wasted.
All of that means that companies are incredibly risk-averse when it comes to hiring, and will pass on someone who looks even slightly wrong to them. It also means that the process is inherently random as a company will pass on someone they aren't sure of _even if they would have been a good hire_ just because they aren't certain. However, this also means that a lot of companies rely on self-selection in their hiring pool. Look for people they already know, from the same backgrounds, or are willing to pass through a series of arbitrary tests.
In short, it's like democracy. It's the worst form of government, except for all the others we've tried.
The economics of it are that in many places in the world, it is extremely difficult to fire an employee. Getting rid of an underperformer can take time, effort, and exposes the company to liability if the termination can be construed as relating to the employee being in a protected class (e.g. can't fire someone because she's a woman). Let's assume that it's a SF startup willing to play a little fast and loose and they aren't concerned with severance packages or the legal issues. They still put time and effort into training a new engineer. That's months of work that is potentially wasted.
All of that means that companies are incredibly risk-averse when it comes to hiring, and will pass on someone who looks even slightly wrong to them. It also means that the process is inherently random as a company will pass on someone they aren't sure of _even if they would have been a good hire_ just because they aren't certain. However, this also means that a lot of companies rely on self-selection in their hiring pool. Look for people they already know, from the same backgrounds, or are willing to pass through a series of arbitrary tests.
In short, it's like democracy. It's the worst form of government, except for all the others we've tried.
Don't know where you live but in most of Europe firing someone is pretty trivial.
For a newly hired, you have a probation period, before your contract becomes permanent, usually between a month and a year, where you can be fired on the spot. After that, your contract becomes permanent and you can get fired, no questions asked, with a notice period of usually between one and 3 months.
In theory, before letting you go, the company has to set up a performance improvement plan for you but companies never bother as it's considered wasted effort to invest in under performers so they just warn you at your performance review that your performance is lacking and that this is strike one. After 3 months of performance monitoring you are let go because your performance hasn't improved so that was strike two and you're out.
Sure, you can sue them if you know you've been wronged, and win a few thousand euros, but nobody's gonna hire you knowing you're in a lawsuit with your ex-employer so nobody bothers to sue and prefers to just find another job instead.
So unless you're a protected category, usually over 50 years old, woman or not, doesn't matter or part of some big-corp with strong unions, the hard-to-fire is not an argument that holds water here.
For a newly hired, you have a probation period, before your contract becomes permanent, usually between a month and a year, where you can be fired on the spot. After that, your contract becomes permanent and you can get fired, no questions asked, with a notice period of usually between one and 3 months.
In theory, before letting you go, the company has to set up a performance improvement plan for you but companies never bother as it's considered wasted effort to invest in under performers so they just warn you at your performance review that your performance is lacking and that this is strike one. After 3 months of performance monitoring you are let go because your performance hasn't improved so that was strike two and you're out.
Sure, you can sue them if you know you've been wronged, and win a few thousand euros, but nobody's gonna hire you knowing you're in a lawsuit with your ex-employer so nobody bothers to sue and prefers to just find another job instead.
So unless you're a protected category, usually over 50 years old, woman or not, doesn't matter or part of some big-corp with strong unions, the hard-to-fire is not an argument that holds water here.
In the under-performing scenario, wouldn't the company have to pay part of the unemployment benefits (up to ~50% of the salary) for a year or so?
No, you and your employer pay monthly contributions to the social security system, as part of your income taxes, and in case you get laid off, your unemployment benefits come from that pool.
1 to 3 months is far from trivial...
I've been in this business for a very long time, and I have heard this my entire career from everyone except HR professionals and lawyers.
First, in jurisdictions like Ontario, there is a probation period during which a new employee can be fired for no reason at all. They can be a top performer and still get fired, and they have no recourse.
There are Ontario Human Rights exceptions to this, you can’t have a “Cowboys and Squaws Dress Day” and then fire the newly hired First Nations person who objects.
But I have been to a number of management training programs put on by HR consulting firms, and zero of them have said, “Be 100% certain about your new hired, because firing them is difficult and expensive if they don't work out.”
It’s true that after they’ve been around for a while, firing someone without cause entails some costs. But here in Ontario, they are surprisingly low. It’s possible to get sued, and win or lose that costs money and time, so most employers either go through a PIP process before letting someone go, or write a decent but not outrageously large cheque in exchange for agreement.
On the whole, “Avoid all but the most insanely qualified candidate because firing people is hard” is not anything I’ve heard from a professional. At least, not in my jurisdiction.
——-
The above is my recounting my factual experience. And now to my conjectures:
What I have heard from fellow managers has more to do with team morale. Hiring and firing people on a regular basis destabilizes the teams they join.
Hiring people without ensuring they're a decent fit sends a message that the company doesn't value competence.
When such things were in vogue, using bullshit a-hair-to-the-right-of-astrology tests like “How many weights do you need to use a balancing scale to...” acted as a signal to existing employees that they are super smart elite braniacs, and the company values that.
I suspect that a lot of risk-aversion with hiring is a combination of “apocraphyl stories going around the intrnet, but nobody is quoting actual research and case law,” combined with cultural signalling.
At my current employer, there are lots of people who don’t pass our interview system, but when we review a candidate, we are often less concerned with how capable they are today than with our estimate of how amenable they are to growing on the job.
That obviously applies a lot more to people coming in at a lower level, but I assure you that we value great people, but we aren’t insanely risk-averse. Being too risk-averse with hiring is a failure mode, just as being too risk-averse with engineering and product development.
First, in jurisdictions like Ontario, there is a probation period during which a new employee can be fired for no reason at all. They can be a top performer and still get fired, and they have no recourse.
There are Ontario Human Rights exceptions to this, you can’t have a “Cowboys and Squaws Dress Day” and then fire the newly hired First Nations person who objects.
But I have been to a number of management training programs put on by HR consulting firms, and zero of them have said, “Be 100% certain about your new hired, because firing them is difficult and expensive if they don't work out.”
It’s true that after they’ve been around for a while, firing someone without cause entails some costs. But here in Ontario, they are surprisingly low. It’s possible to get sued, and win or lose that costs money and time, so most employers either go through a PIP process before letting someone go, or write a decent but not outrageously large cheque in exchange for agreement.
On the whole, “Avoid all but the most insanely qualified candidate because firing people is hard” is not anything I’ve heard from a professional. At least, not in my jurisdiction.
——-
The above is my recounting my factual experience. And now to my conjectures:
What I have heard from fellow managers has more to do with team morale. Hiring and firing people on a regular basis destabilizes the teams they join.
Hiring people without ensuring they're a decent fit sends a message that the company doesn't value competence.
When such things were in vogue, using bullshit a-hair-to-the-right-of-astrology tests like “How many weights do you need to use a balancing scale to...” acted as a signal to existing employees that they are super smart elite braniacs, and the company values that.
I suspect that a lot of risk-aversion with hiring is a combination of “apocraphyl stories going around the intrnet, but nobody is quoting actual research and case law,” combined with cultural signalling.
At my current employer, there are lots of people who don’t pass our interview system, but when we review a candidate, we are often less concerned with how capable they are today than with our estimate of how amenable they are to growing on the job.
That obviously applies a lot more to people coming in at a lower level, but I assure you that we value great people, but we aren’t insanely risk-averse. Being too risk-averse with hiring is a failure mode, just as being too risk-averse with engineering and product development.
> When such things were in vogue, using bullshit a-hair-to-the-right-of-astrology tests like “How many weights do you need to use a balancing scale to...”
Ah, you're lucky to be living in such an enlightened society. In Switzerland you can still find employers who require handwritten applications because they have them evaluated by professional graphologists!
Ah, you're lucky to be living in such an enlightened society. In Switzerland you can still find employers who require handwritten applications because they have them evaluated by professional graphologists!
That kind of thing leaves me scratching my head.
BTW, don’t scratch your head. It throws off the phrenological screen.
BTW, don’t scratch your head. It throws off the phrenological screen.
How many people have you hired with you as their direct manager? How many of those have you had to fire?
I've only had to fire one person, but it was as a part time homework checker. I've only been personally responsible for 3 FTE hires in my career (beyond CV screen). I'm not the most qualified person to talk about actual hard data points on the importance of success in the hiring/firing process.
However, I do screen CVs and I've seen several thousand of those so we can imply some data from other companies experiences. I'd say maybe 5% pop out as truly problematic people who jump jobs more than once a year. There's another 10% who have been at their current job for less than a year. The overwhelming majority of those 10% are leaving because the role isn't what they were told it would be (they are pure backend dev's being forced into a frontend role, different tech stack, QA job advertised as devops, etc). The next 60% work at each job between 2 to 4 years and leave because they got bored, or weren't allowed to grow, or they were asked to work harder than they feel they should have to. The rest leave because the business closed or similar circumstances. While some of these people may be lying about the reason they're leaving, I don't think they'd lie about the amount of time they worked somewhere.
So what makes someone a bad hire? The obvious ones you can easily filter for in your hiring process. The ones that cause the conventional wisdom of "firing is hard" are the ones who just barely scrape by, draining the team with extra training, extra work, extra bugfixes, extra "oops" moments for the longest time. They're the ones who go on a PIP and improve enough that it's difficult to justify firing them with cause. The reason "firing someone is hard" isn't because the process itself is hard. It's because the ones you need to fire, the ones you're warned against, they're just a bad fit. They take up an extra desk and shorten your runway (or budget) while providing just barely more than what they cost. It's the opportunity cost of hiring someone who's not great but not horrible. The actual cost of firing an underperfomer is 2 or 3 months salary equivalent depending on contract/jurisdiction.
So we're stuck with "a-hair-to-the-right-of-astrology" because it's really difficult to filter reliably, and an amazing worker on the right team could be "meh" on the wrong one (for him/her). It may be bullshit but at least it's bullshit the entire team believes in.
I've only had to fire one person, but it was as a part time homework checker. I've only been personally responsible for 3 FTE hires in my career (beyond CV screen). I'm not the most qualified person to talk about actual hard data points on the importance of success in the hiring/firing process.
However, I do screen CVs and I've seen several thousand of those so we can imply some data from other companies experiences. I'd say maybe 5% pop out as truly problematic people who jump jobs more than once a year. There's another 10% who have been at their current job for less than a year. The overwhelming majority of those 10% are leaving because the role isn't what they were told it would be (they are pure backend dev's being forced into a frontend role, different tech stack, QA job advertised as devops, etc). The next 60% work at each job between 2 to 4 years and leave because they got bored, or weren't allowed to grow, or they were asked to work harder than they feel they should have to. The rest leave because the business closed or similar circumstances. While some of these people may be lying about the reason they're leaving, I don't think they'd lie about the amount of time they worked somewhere.
So what makes someone a bad hire? The obvious ones you can easily filter for in your hiring process. The ones that cause the conventional wisdom of "firing is hard" are the ones who just barely scrape by, draining the team with extra training, extra work, extra bugfixes, extra "oops" moments for the longest time. They're the ones who go on a PIP and improve enough that it's difficult to justify firing them with cause. The reason "firing someone is hard" isn't because the process itself is hard. It's because the ones you need to fire, the ones you're warned against, they're just a bad fit. They take up an extra desk and shorten your runway (or budget) while providing just barely more than what they cost. It's the opportunity cost of hiring someone who's not great but not horrible. The actual cost of firing an underperfomer is 2 or 3 months salary equivalent depending on contract/jurisdiction.
So we're stuck with "a-hair-to-the-right-of-astrology" because it's really difficult to filter reliably, and an amazing worker on the right team could be "meh" on the wrong one (for him/her). It may be bullshit but at least it's bullshit the entire team believes in.
Your entire argument smells to me like The Politician’s Fallacy:
Something must be done.
This is something.
Therefore we must do it.
There’s lots of that in business: Long explanation for why something must be done, then a short explanation for what “this” is, and we just have to take it on faith that “this” will do anything to fix the problem that makes us feel like something must be done.
But as long as “everyone else is doing it,” we all believe in this something that we must do, and as long as we all believe it, we’ll all back “this something” we must do.
Whether it works, doesn’t work, or even makes it worse.
e.g. If you ask people how many golf balls fit in an airplane, word gets around and the next thing you know, people who can game PIPs to not get fired will game your interview to get hired in the first place.
And by hiring them, you don’t hire someone else who can actually do the job but doesn’t solve recreational puzzles for a hobby, nor do they spend any time learning how to game interviews.
This is the thinking that also brought us, “Nobody ever got fired for buying IBM,” and so forth: An emphasis on doing the thing people believe must be done, rather than looking for something that works whether it’s popular or not.
Something must be done.
This is something.
Therefore we must do it.
There’s lots of that in business: Long explanation for why something must be done, then a short explanation for what “this” is, and we just have to take it on faith that “this” will do anything to fix the problem that makes us feel like something must be done.
But as long as “everyone else is doing it,” we all believe in this something that we must do, and as long as we all believe it, we’ll all back “this something” we must do.
Whether it works, doesn’t work, or even makes it worse.
e.g. If you ask people how many golf balls fit in an airplane, word gets around and the next thing you know, people who can game PIPs to not get fired will game your interview to get hired in the first place.
And by hiring them, you don’t hire someone else who can actually do the job but doesn’t solve recreational puzzles for a hobby, nor do they spend any time learning how to game interviews.
This is the thinking that also brought us, “Nobody ever got fired for buying IBM,” and so forth: An emphasis on doing the thing people believe must be done, rather than looking for something that works whether it’s popular or not.
Other fields seem to get along just fine with the same set of constraints. Yes, some of those have professional licensure but not always, and those licenses aren't always required depending on the field. In the latter circumstances, the license unlocks higher level positions, it'd be like saying you couldn't be a Director of Engineering at a software shop w/o one.
Do they get along just fine?
My experience of quite a lot of jobs has been that people, even managers, struggle to articulate what exactly they do, let alone what is required to do it well. If you can't clearly articulate that it's pretty meaningless to have any sort of rigorous hiring process to begin with.
Maybe that sounds over cynical, but I've watched as people from outside the tech industry encountered the concept of asking people to actually do a work sample in an interview for the first time. They thought it was the most crazy demanding and professional thing they ever heard of and immediately came to regard the team that was hired through that process as incredibly elite. Very few professions really challenge candidates in any meaningful way.
My experience of quite a lot of jobs has been that people, even managers, struggle to articulate what exactly they do, let alone what is required to do it well. If you can't clearly articulate that it's pretty meaningless to have any sort of rigorous hiring process to begin with.
Maybe that sounds over cynical, but I've watched as people from outside the tech industry encountered the concept of asking people to actually do a work sample in an interview for the first time. They thought it was the most crazy demanding and professional thing they ever heard of and immediately came to regard the team that was hired through that process as incredibly elite. Very few professions really challenge candidates in any meaningful way.
Not democracy, politics. When there are too many for what we know how to do, we just pick what we know and like. Which in most instances is people like us. After enough cultural repetition it just becomes the way to do it. And they end up looking for themselves, but they don't know how to do the work so nobody like them is a good choice.
for startup the hiring is US is tough, thought about hiring from Europe (remote) then got scared away by the labor law there.
checking at Asia now, not because they're slightly cheaper(they still are, though to a less degree), but at least the labor law seems more reasonable, so yes, outsourcing not for just saving some money but mainly because of the employment rules are more reasonable for both sides.
checking at Asia now, not because they're slightly cheaper(they still are, though to a less degree), but at least the labor law seems more reasonable, so yes, outsourcing not for just saving some money but mainly because of the employment rules are more reasonable for both sides.
Wouldn't you just offer a contract to anyone outside of the US? Treat it as a b2b contract?
no you can hire a group of them, rent an office and designate a tech leader, then do some simple paperwork and set up payment flow and you're ready to go. You don't need consider age/gender/affirmative-action/minority/LGBT-rights and worry about being sued somehow for whatever strange reason, you just hire whoever from the market that wants to do the job, and pay them on time with best intention and follow the common sense rules.
What I find funny is how little time and effort is put in writing the job description. The interview process is mostly very generic and the questions hardly in alignment to the role. As a profession we try hard to be correct about creating clear specs that can be translated to unambiguous steps for a machine to execute, but when it comes to hiring - we write ambiguous specs, toss it over to recruiters who are poorly equipped.
Here are some thoughts: - When the new position opens, the team (say the scrum team) collaboratively writes a job description based on the current backlog. Let's not leave it to a manager or recruiter who is writing the job description. Use the company/team's mission and values as guidance to see who an ideal candidate would be. This is like writing your stories.
- Then write the filtering criteria based on the typical day to day skills - what are must haves, what are good to have, what is ok to not have. This is like write your test cases.
- What are the areas where the team is lacking. Try to get skills/qualities that will, for lack of a better expression, raise the bar of the team. This is like your retrospectives - and if you have notes from your recent retrospectives, they should help you identify what you are looking for.
- This better spec should help the recruiters, and also give the candidates an honest look into the team.
- For the interview, go back to your previous sprints etc. and build questions that are simplified models of what a typical story would look like. Instead of asking to invert a tree, may be it would be better to talk about how a particular problem you solved and see the approach the candidate would take. Give the candidate all the tools - their favorite editor/ide or whiteboard, whatever they prefer.
Here are some thoughts: - When the new position opens, the team (say the scrum team) collaboratively writes a job description based on the current backlog. Let's not leave it to a manager or recruiter who is writing the job description. Use the company/team's mission and values as guidance to see who an ideal candidate would be. This is like writing your stories.
- Then write the filtering criteria based on the typical day to day skills - what are must haves, what are good to have, what is ok to not have. This is like write your test cases.
- What are the areas where the team is lacking. Try to get skills/qualities that will, for lack of a better expression, raise the bar of the team. This is like your retrospectives - and if you have notes from your recent retrospectives, they should help you identify what you are looking for.
- This better spec should help the recruiters, and also give the candidates an honest look into the team.
- For the interview, go back to your previous sprints etc. and build questions that are simplified models of what a typical story would look like. Instead of asking to invert a tree, may be it would be better to talk about how a particular problem you solved and see the approach the candidate would take. Give the candidate all the tools - their favorite editor/ide or whiteboard, whatever they prefer.
I'm actually assisting with a startup in building a solution for things like this, so your comment really struck home!
And as somebody with a past in technical recruiting, I really like your thinking. Indeed you're right: many recruiters are poorly equipped to actually understand the roles. We have non-coders as the first or second tier gatekeepers for development roles, which does not seem ideal.
Sometimes I'd get different signals from the job descriptions than the senior recruiters or hiring managers, which was frustrating. Other times, the requirements in descriptions were way too broad: like the team had an idea of what they wanted, but couldn't get it down on paper in a concise way.
Resumes can be a challenge, too: many engineers don't always give full details of their work. Perhaps because they're tired of getting recruiters reaching out for irrelevant roles (that happen to have a keyword match somewhere). Perhaps they don't have the time to always be updating and polishing.
A two-front solution could be really great. We need developers to write their best resumes, and we need employers to write their best job descriptions. Having them 'speak the same language' on concise accomplishments, metrics, technologies will make more automated matching a lot (a lot) easier.
And then, of course - build the interview process around the shared skills / technologies / etc.
Hopefully I'll have something to share here soon, or perhaps do an ask HN to chat more about making hiring developers easier for everyone
And as somebody with a past in technical recruiting, I really like your thinking. Indeed you're right: many recruiters are poorly equipped to actually understand the roles. We have non-coders as the first or second tier gatekeepers for development roles, which does not seem ideal.
Sometimes I'd get different signals from the job descriptions than the senior recruiters or hiring managers, which was frustrating. Other times, the requirements in descriptions were way too broad: like the team had an idea of what they wanted, but couldn't get it down on paper in a concise way.
Resumes can be a challenge, too: many engineers don't always give full details of their work. Perhaps because they're tired of getting recruiters reaching out for irrelevant roles (that happen to have a keyword match somewhere). Perhaps they don't have the time to always be updating and polishing.
A two-front solution could be really great. We need developers to write their best resumes, and we need employers to write their best job descriptions. Having them 'speak the same language' on concise accomplishments, metrics, technologies will make more automated matching a lot (a lot) easier.
And then, of course - build the interview process around the shared skills / technologies / etc.
Hopefully I'll have something to share here soon, or perhaps do an ask HN to chat more about making hiring developers easier for everyone
That is just great to hear.
"A two-front solution could be really great. We need developers to write their best resumes, and we need employers to write their best job descriptions. Having them 'speak the same language' on concise accomplishments, metrics, technologies will make more automated matching a lot (a lot) easier." - 100%! This is the market place that Linkedin has been trying to create - but hasn't worked very well, right? They have largely solved the problem of structuring the resume data - which is definitely useful, but I don't see much of that on the job description side. The matching algorithms can only rise up to the level of quality of the input data - the resume data, and the job description.
There are similar problems in the dating industry, but mostly you can be sure both parties are putting their best efforts for creating better input.
I think honesty is also a critical part of the equation. And if the Linkedin or indeed could encourage both sides to reveal what they value deeply - that would things more useful. May be a few why questions rather than just checkboxes and drop downs that can be filled quickly. Candidate: Why is remote working important for you? Job poster: Why is a self-starter important for you? That would help bring out the uniqueness for the candidates and helped the matching algorithms.
Will look forward to seeing your product on Show HN - best wishes!
"A two-front solution could be really great. We need developers to write their best resumes, and we need employers to write their best job descriptions. Having them 'speak the same language' on concise accomplishments, metrics, technologies will make more automated matching a lot (a lot) easier." - 100%! This is the market place that Linkedin has been trying to create - but hasn't worked very well, right? They have largely solved the problem of structuring the resume data - which is definitely useful, but I don't see much of that on the job description side. The matching algorithms can only rise up to the level of quality of the input data - the resume data, and the job description.
There are similar problems in the dating industry, but mostly you can be sure both parties are putting their best efforts for creating better input.
I think honesty is also a critical part of the equation. And if the Linkedin or indeed could encourage both sides to reveal what they value deeply - that would things more useful. May be a few why questions rather than just checkboxes and drop downs that can be filled quickly. Candidate: Why is remote working important for you? Job poster: Why is a self-starter important for you? That would help bring out the uniqueness for the candidates and helped the matching algorithms.
Will look forward to seeing your product on Show HN - best wishes!
Thank you so much - and we can't wait to share!
For anyone who may be interested, https://www.rocketship.jobs/
If it can help even one person land a job, we'll be happy with having built something new and different!
For anyone who may be interested, https://www.rocketship.jobs/
If it can help even one person land a job, we'll be happy with having built something new and different!
I have no answer to your question, but I can at least offer some sympathy and confirmation. I've been looking for a remote position for months and have been eliminated from consideration many times because I didn't have "X" months experience with specific technology "Y" - which could be easily learned by _any_ experienced developer. It's baffling ... and deflating.
Did you get explicit feedback stating those reasons?
Usually when a job candidate is not selected they aren't given any information about why.
Usually when a job candidate is not selected they aren't given any information about why.
To defend some of this:
1) Why pay someone to learn? In both terms of money and other devs time being sunk into helping you learn.
2) If you do know "tool X" and its a primary tool then its a lot easier to quickly evaluate whether or not standards will align.
Personally I don't mind hiring Jr Developers that cost less, are mold-able, and are willing to put in extra effort. Could any experienced dev lean it? Sure... but its more costly and often ends up in a "I have now studied X for Y weeks, we do X wrong I refuse to do X your way."
1) Why pay someone to learn? In both terms of money and other devs time being sunk into helping you learn.
2) If you do know "tool X" and its a primary tool then its a lot easier to quickly evaluate whether or not standards will align.
Personally I don't mind hiring Jr Developers that cost less, are mold-able, and are willing to put in extra effort. Could any experienced dev lean it? Sure... but its more costly and often ends up in a "I have now studied X for Y weeks, we do X wrong I refuse to do X your way."
I have had great success hiring junior developers and molding them as described above. This turns the interview process into learning about the person and their goals and what drives them instead of what do you already know. Because let’s be honest, most development work can be learned fairly quickly for 95% of the work out there that needs to be done. For the other 5%, hirer a senior person who has that specific experience. Not necessarily experience in that tech, just experience solving the need you have. Performance, scaling, complex math, etc.
Do you work with such an extremely static stack that it requires no further learning?
I would say that one of the most important qualities a developer can have is the ability to learn.
Perhaps, you expect all the learning to be done outside of work?
I would say that one of the most important qualities a developer can have is the ability to learn.
Perhaps, you expect all the learning to be done outside of work?
I lead product and engineering orgs in startups, so yes I make sure our -core- tools remain static as possible.
I never claimed learning is not important, if anything I supported that in my comment in hiring eager jr's.
My point being is if I am hiring someone "experienced" I need someone who can mentor others, own projects, and help drive our current products forward. If that person will need to come in and learn the job... I might as well hire a JR and train them up instead or hold our the X months the "experienced" person will need to learn to bypass that whole ordeal.
I never claimed learning is not important, if anything I supported that in my comment in hiring eager jr's.
My point being is if I am hiring someone "experienced" I need someone who can mentor others, own projects, and help drive our current products forward. If that person will need to come in and learn the job... I might as well hire a JR and train them up instead or hold our the X months the "experienced" person will need to learn to bypass that whole ordeal.
I hear you. There are so many kinds of senior developers. Wrote a blog post about it:
http://www.mooreds.com/wordpress/archives/2812
http://www.mooreds.com/wordpress/archives/2812
You can look at this another way — a poorly managed company self selected themselves out from your consideration. Would you really want to work at such a company? Better that the company failed-fast and saved everyone the trouble of you having to endure a rigid environment.
I asked an HR rep about this and she told me there is a massive influx of new grads demanding very high salaries. You and I might be from a generation where a CS degree was not an obvious choice and the supply was not as high for organizations. Unfortunately years of experience don’t count for much in this industry, especially with how fast technologies change.
Also, startup hiring usually means joining an already close knit team. If you have to interview with 5 people, have a fifty-fifty chance with each and anyone can veto your hire that gives you a 3% chance of getting an offer. Competency will get your foot in the door, but ultimately it comes down to the social psychology of social comparison and propinquity.
If you are a senior/staff with some success at previous startups, you are likely to get vetoed by developers who see you as a threat in the promotions tournament.
If you are a senior/staff with some success at previous startups, you are likely to get vetoed by developers who see you as a threat in the promotions tournament.
The process is aimed at fulfilling a business need that they are experiencing. Unless you know everything going on internally, it is difficult to judge whether the hiring process is bad, or simply not matched to your expectations. As to why it seems fearful, there is a huge price to pay if you make a bad hire in any company, but it is exaggerated when you make a bad remote hire, even more so if they have never worked remote before, and you need to bring them up to speed on how it works. There may be fear, but again, it is business-driven.
Your comment is chock full of flawed and patently false ideas. Firstly, I have yet to encounter a company with a hiring process that is actually, provably, repeatedly tied to any of that company’s business needs. Designing a working hiring process is harder than the software work that the hiring is for. It’s no surprise that results usually seem arbitrary and ineffective.
Secondly, and following up on my first critique, an ineffective hiring process usually leads to the hiring of candidates who are good at interviewing, not at the actual work. These are the literal “bad hires” that should have been sifted out by the hiring process.
Secondly, and following up on my first critique, an ineffective hiring process usually leads to the hiring of candidates who are good at interviewing, not at the actual work. These are the literal “bad hires” that should have been sifted out by the hiring process.
Having just gone through the interview process with a very well known tech company, as someone who is honestly pretty terrible at interviewing, I think some companies actually get it. It's really a matter of the interviewer at play. Two of the phases I went through really aligned with the company's needs. I was interviewing for a SRE position, and in one phase they gave me a broken EC2 instance that had been manually configured and asked me to get it back up and running. That's a legit task that I've had to do in daily work for years, because there's ALWAYS going to be someone that does a quick hack to get something working and forgets to productionize it. It was a completely contrived box that didn't actually serve customers, but still a good exercise. In another phase, they had me completely blind fire design some infrastructure (without a complete picture of what the current state of the application is) to lead toward a scalable solution for a real problem they're facing. While, yes, that's basically them getting me to do unpaid work, since I didn't put hands on a keyboard during it and really just talked it through with them, I feel like that was a great exercise in seeing how I thought and could work with a member of the team.
There's no truly bulletproof solution to interviewing, because the needs of every org are different, and the skills of interviewers are rarely nurtured to the point of usefulness. Sometimes you just have to luck out and get a good interview.
There's no truly bulletproof solution to interviewing, because the needs of every org are different, and the skills of interviewers are rarely nurtured to the point of usefulness. Sometimes you just have to luck out and get a good interview.
> Your comment is chock full of flawed and patently false ideas.
Whoa, what triggered and justified that response? I don’t know if the parent was edited, but it seems pretty reasonable to me.
> Firstly, I have yet to encounter a company with a hiring process that is actually, provably, repeatedly tied to any of that company’s business needs.
What do you mean? Why do companies hire then?
> an ineffective hiring process usually leads to the hiring of candidates who are good at interviewing, not at the actual work. These are the literal “bad hires”
This hasn’t been true in my experience. Why would someone who’s good at the work not tend to be good at interviews?
I’ve interviewed hundreds of people and hired dozens. The number one reason for a candidate not getting a position is that there was another better candidate. More often than not, it has nothing to do with how good the candidate is, nor does it have anything to do with how good the company’s interview process is. After that, there is usually a large number of candidates that are young and shooting above their weight, hoping to get in somewhere with almost enough qualification. Occasionally, that works. I haven’t bumped into anyone yet that was great at interviewing but not good at the work, but like many companies, I’m using the interviews to try and find out if they’ll fit it, and if they’re truly interested, and if they’re good at work.
Whoa, what triggered and justified that response? I don’t know if the parent was edited, but it seems pretty reasonable to me.
> Firstly, I have yet to encounter a company with a hiring process that is actually, provably, repeatedly tied to any of that company’s business needs.
What do you mean? Why do companies hire then?
> an ineffective hiring process usually leads to the hiring of candidates who are good at interviewing, not at the actual work. These are the literal “bad hires”
This hasn’t been true in my experience. Why would someone who’s good at the work not tend to be good at interviews?
I’ve interviewed hundreds of people and hired dozens. The number one reason for a candidate not getting a position is that there was another better candidate. More often than not, it has nothing to do with how good the candidate is, nor does it have anything to do with how good the company’s interview process is. After that, there is usually a large number of candidates that are young and shooting above their weight, hoping to get in somewhere with almost enough qualification. Occasionally, that works. I haven’t bumped into anyone yet that was great at interviewing but not good at the work, but like many companies, I’m using the interviews to try and find out if they’ll fit it, and if they’re truly interested, and if they’re good at work.
>> > Firstly, I have yet to encounter a company with a hiring process that is actually, provably, repeatedly tied to any of that company’s business needs.
>> What do you mean? Why do companies hire then?
Sadly this is very common -- the bigger and more profitable the company the more common it is. Companies often hire for non-business related reasons for several major reasons:
1. Bench strength -- Hire top talent before you need it so you are ready to fire when you have a strategic project. Ideally, hire away talent your competitors might hire. In many ways, this is a good thing.
2. "Burn the Budget" - Divisions will often lose budget if they dont spend it, and they may lose it in future years when they need it ("well you got it last year and you didnt use it, so this year you dont get it...") -- so many divisions will hire to burn the budget and use it just so they dont lose budget when they really really need it.
3. HR - It is common for HR to institute Crazy-8s policies or some variant of it -- where you only get promoted if you have 8 (or N) people working for you. Naturally all sorts of non business related tasks suddenly pop up and people hire just enough to get promoted. This is very common in organizations where promotion and pay is linked to non business metrics (how much budget you control, how many people report to you) rather than business metrics (revenue delivered, revenue enabled, churn reduced, traffic increased, etc.) Often your boss themselves wants to be promoted and needs 8 middle-managers 8 under them to get promoted. And so on up the chain. Almost half the HR departments in my ~20yr career institute such a policy, whether it is internally known or not. It is of course more common in organizations which are not metrics driven.
>> What do you mean? Why do companies hire then?
Sadly this is very common -- the bigger and more profitable the company the more common it is. Companies often hire for non-business related reasons for several major reasons:
1. Bench strength -- Hire top talent before you need it so you are ready to fire when you have a strategic project. Ideally, hire away talent your competitors might hire. In many ways, this is a good thing.
2. "Burn the Budget" - Divisions will often lose budget if they dont spend it, and they may lose it in future years when they need it ("well you got it last year and you didnt use it, so this year you dont get it...") -- so many divisions will hire to burn the budget and use it just so they dont lose budget when they really really need it.
3. HR - It is common for HR to institute Crazy-8s policies or some variant of it -- where you only get promoted if you have 8 (or N) people working for you. Naturally all sorts of non business related tasks suddenly pop up and people hire just enough to get promoted. This is very common in organizations where promotion and pay is linked to non business metrics (how much budget you control, how many people report to you) rather than business metrics (revenue delivered, revenue enabled, churn reduced, traffic increased, etc.) Often your boss themselves wants to be promoted and needs 8 middle-managers 8 under them to get promoted. And so on up the chain. Almost half the HR departments in my ~20yr career institute such a policy, whether it is internally known or not. It is of course more common in organizations which are not metrics driven.
Aren’t those all “business needs” in a general sense?
#1 is a business need.
#2 is a gray area.
#3 is business burn -- when an organization "needs" to hire loads of people to work on useless projects just to align to rigid HR rules, the business has stopped to drive operations and instead operations are driving the business.
#2 is a gray area.
#3 is business burn -- when an organization "needs" to hire loads of people to work on useless projects just to align to rigid HR rules, the business has stopped to drive operations and instead operations are driving the business.
> I don’t know if the parent was edited
Nope, no edits. I'm not sure where the bitterness is coming from either, aside from the obvious that they aren't pleased with how recent interviews have gone.
Nope, no edits. I'm not sure where the bitterness is coming from either, aside from the obvious that they aren't pleased with how recent interviews have gone.
Two thoughts.
First, most companies will look for a remote person only after exhausting their local labor pool. If someone remote has to devote their initial months to learning with no advantage over someone local learning the same content, why not go with the added benefit of hiring someone local.
Second, many companies have a fallback person in place who can almost meet the need - maybe they have x amount of years in a language, right attitude, etc. This process is only to see if you are better than their fallback option. The distressing answer sounds to be rarely.
First, most companies will look for a remote person only after exhausting their local labor pool. If someone remote has to devote their initial months to learning with no advantage over someone local learning the same content, why not go with the added benefit of hiring someone local.
Second, many companies have a fallback person in place who can almost meet the need - maybe they have x amount of years in a language, right attitude, etc. This process is only to see if you are better than their fallback option. The distressing answer sounds to be rarely.
A few (incomplete) thoughts:
1. We haven't yet figured out a way to get enough signal from two hours or so of work.
2. There are multiple ways to be a good programmer, but companies need a standardized way to assess skill. There's an inherent mismatch.
3. Most teams don't even know how to gauge their own employees' skill/value.
4. Teams rarely have their own employees retake their hiring tests to calibrate effectively.
5. Unpopular opinion: they aren't. Skills like algorithms are vital, and people who argue that they don't matter simply don't want to do the work.
1. We haven't yet figured out a way to get enough signal from two hours or so of work.
2. There are multiple ways to be a good programmer, but companies need a standardized way to assess skill. There's an inherent mismatch.
3. Most teams don't even know how to gauge their own employees' skill/value.
4. Teams rarely have their own employees retake their hiring tests to calibrate effectively.
5. Unpopular opinion: they aren't. Skills like algorithms are vital, and people who argue that they don't matter simply don't want to do the work.
> 4. Teams rarely have their own employees retake their hiring tests to calibrate effectively
I can't imagine that would end well in most cases.
I can't imagine that would end well in most cases.
Hiring is an inherently hard problem. I imagine the additional hard to test requirements of remote work (autonomy, discipline, ability to do your own it, ...) doesn't make it easier.
I have come to see trying to find a job is a lot like dating. You see the company for the first time "oh look how pretty. We would be perfect together!"
Then you start talking and they ask you a bunch of really stupid questions. The voice in your head starts telling you something is off.
Then they start testing you and giving you the run around. In dating this is known as playing games.
Just like in dating it's time to wake up and realize they are showing you who they truly are. Ignore at your own peril!
Then you start talking and they ask you a bunch of really stupid questions. The voice in your head starts telling you something is off.
Then they start testing you and giving you the run around. In dating this is known as playing games.
Just like in dating it's time to wake up and realize they are showing you who they truly are. Ignore at your own peril!
I am building a product/startup [1] to address some of the problems you mention, and as a result, I've been talking to hiring teams at several companies, so I can give you some reasons why the processes are bad.
* Hiring is a marketplace, and supply/demand is not always balanced, so most issues related to job search/hiring is due to this.
* When a company posts an ad for a job, they usually receive about 150-200 applicants within 2 weeks, thanks to job boards, LinkedIn etc. Unless it is for specific high-skilled jobs, in which case, they receive hardly any applicants at all.
* Most of the applicants are usually not a match for the job, but given the number of applicants, recruiters rely on resumes, social profiles etc to shortlist about 20 applicants.
* Tests and assignments are quick means to filter, hence their popularity.
* Not much of an incentive to keep applicants posted at every step, plus, managing communication with a few hundred applicants for multiple positions is hard - so you're most likely to receive only automated communication from the hiring team.
I believe that having a clear specification of the job, that can be checked/validated with applicants is critical to ensuring a smooth, fast interviewing process.
[1] - Shameless plug to my startup (in beta) - https://www.interviewpass.co. If any of you are interested in using InterviewPass in your hiring, drop me an email at [email protected] - happy to help set it up for you.
* Hiring is a marketplace, and supply/demand is not always balanced, so most issues related to job search/hiring is due to this.
* When a company posts an ad for a job, they usually receive about 150-200 applicants within 2 weeks, thanks to job boards, LinkedIn etc. Unless it is for specific high-skilled jobs, in which case, they receive hardly any applicants at all.
* Most of the applicants are usually not a match for the job, but given the number of applicants, recruiters rely on resumes, social profiles etc to shortlist about 20 applicants.
* Tests and assignments are quick means to filter, hence their popularity.
* Not much of an incentive to keep applicants posted at every step, plus, managing communication with a few hundred applicants for multiple positions is hard - so you're most likely to receive only automated communication from the hiring team.
I believe that having a clear specification of the job, that can be checked/validated with applicants is critical to ensuring a smooth, fast interviewing process.
[1] - Shameless plug to my startup (in beta) - https://www.interviewpass.co. If any of you are interested in using InterviewPass in your hiring, drop me an email at [email protected] - happy to help set it up for you.
The problem as I see it is that good applicants don't bother with job boards. When you have recruiters banging on your door and begging to handle all the details for you (and provide proper communication) it's no wonder candidates don't bother applying. That, however, means the expectation is that job board candidates are bad and desperate. So companies will filter them more aggressively than recruiter candidates. So candidates now have even more incentive to go with recruiters since it actually gives them a better chance to get hired.
That's true. Recruiters provide the initial screening, which is lacking in a job board.
But the hiring process is broken beyond the initial screening as well, biggest reason being lack of incentives for the involved parties to close a position quickly.
But the hiring process is broken beyond the initial screening as well, biggest reason being lack of incentives for the involved parties to close a position quickly.
>That's true. Recruiters provide the initial screening, which is lacking in a job board.
It's not just the initial screening. They actively go out and find candidates who otherwise wouldn't be looking for jobs directly. And as I said before, those tend to be prime candidates since they get so many recruiters they have little need to apply directly.
>But the hiring process is broken beyond the initial screening as well, biggest reason being lack of incentives for the involved parties to close a position quickly.
Again, recruiters are a solution to this because their paycheck is based on closing the deal. They will hound the company and the candidate to get the process finalized.
It's not just the initial screening. They actively go out and find candidates who otherwise wouldn't be looking for jobs directly. And as I said before, those tend to be prime candidates since they get so many recruiters they have little need to apply directly.
>But the hiring process is broken beyond the initial screening as well, biggest reason being lack of incentives for the involved parties to close a position quickly.
Again, recruiters are a solution to this because their paycheck is based on closing the deal. They will hound the company and the candidate to get the process finalized.
All of my previous job searches started with me seeking remote work and ended with me giving up and taking a local job. There clearly is a surplus of great engineers looking for remote gigs.
I've recently landed an on-site job (I had to relocate) that pays pretty well in an R&D type environment that's actually all right -- in fact, this is one of the few jobs I've had that I've not hated -- so I may stay here more than my usual 1-2 years :)
I've recently landed an on-site job (I had to relocate) that pays pretty well in an R&D type environment that's actually all right -- in fact, this is one of the few jobs I've had that I've not hated -- so I may stay here more than my usual 1-2 years :)
I really hope there's a big push for remote roles. If that's where the talent wants to be, companies should be able to stay competitive.
Plus, it's much better for the environment. If you can do you work from home, why not?
Plus, it's much better for the environment. If you can do you work from home, why not?
My biggest problem was that companies can't compete with a good European unlimited contract.
Most want to hire you as a contractor. Contracting I'd have to at least double my salary to take home the same amount of salary and insurances and out of germany it's basically illegal to be a full-time contractor for just one company.
Most want to hire you as a contractor. Contracting I'd have to at least double my salary to take home the same amount of salary and insurances and out of germany it's basically illegal to be a full-time contractor for just one company.
Most were looking for exactly one type with one set of experiences. Anything outside of that and you are filtered out.
In my experience this rings true for senior roles and less so for new college grads.
Companies seem afraid to hire thinking there is a slightly better/cheaper option around the corner.
I can see why perhaps a candidate receiving a rejection may think this, but in the companies I’ve worked at this has never been the case. It’s always been “it’s really tough finding talent, not paying talent”.
The take home assignments with random marking standards. Tests can matter, ui could matter, api structure could matter, documentation/choice of framework, speed, style all could matter but you rarely know which matters to whom and rarely have time to do it all and even if you did everything perfectly a lot of the time no one even looks or the reviewer expects the code to look like how they might write it.
A fair reviewer recognizes the limitations of these take home exercises. While there are many ways to perform a take-home successfully, there are more ways to show that you aren’t qualified for the role. Not all that pass will be right for the job, but most who fail aren’t.
In my experience this rings true for senior roles and less so for new college grads.
Companies seem afraid to hire thinking there is a slightly better/cheaper option around the corner.
I can see why perhaps a candidate receiving a rejection may think this, but in the companies I’ve worked at this has never been the case. It’s always been “it’s really tough finding talent, not paying talent”.
The take home assignments with random marking standards. Tests can matter, ui could matter, api structure could matter, documentation/choice of framework, speed, style all could matter but you rarely know which matters to whom and rarely have time to do it all and even if you did everything perfectly a lot of the time no one even looks or the reviewer expects the code to look like how they might write it.
A fair reviewer recognizes the limitations of these take home exercises. While there are many ways to perform a take-home successfully, there are more ways to show that you aren’t qualified for the role. Not all that pass will be right for the job, but most who fail aren’t.
> Most were looking for exactly one type with one set of experiences. Anything outside of that and you are filtered out.
> In my experience this rings true for senior roles and less so for new college grads.
I agree that I've seen this to be true for senior roles, but what I've noticed on many job descriptions is the reluctance to say they are looking for a senior engineer. I've gone through quite a few phone screens where it becomes immediately apparent that the company is looking only for a senior but the job title and sometimes description looks like it was written for a mid or even junior position. So I can completely understand where OP's view of the hiring process comes from - you go through the initial test round, get to speak to them, then find out that they have extremely specific requirements. If you happen to be unlucky enough to go through many of these, it can really mess with your perspective on the hiring process.
> In my experience this rings true for senior roles and less so for new college grads.
I agree that I've seen this to be true for senior roles, but what I've noticed on many job descriptions is the reluctance to say they are looking for a senior engineer. I've gone through quite a few phone screens where it becomes immediately apparent that the company is looking only for a senior but the job title and sometimes description looks like it was written for a mid or even junior position. So I can completely understand where OP's view of the hiring process comes from - you go through the initial test round, get to speak to them, then find out that they have extremely specific requirements. If you happen to be unlucky enough to go through many of these, it can really mess with your perspective on the hiring process.
I would say many who fail are probably right for the job. Not having clear goals for the test that the applicant understands leads to this disconnect plus th time involved.
They only get as picky as their options. Remote companies get exponentially more candidates so they can make them jump like monkeys with impunity.
https://www.youtube.com/watch?v=v1WiCGq-PcY
https://www.youtube.com/watch?v=v1WiCGq-PcY
My opinion - Why is the process so bad? Hiring technical talent is flat out difficult. Even for the best companies. Thus, attempt after attempt has been made to figure out "the right way" to screen candidates to prevent bad hires.
It started with algorithmic interviews. Then, we tried take home assignments. Now, lots of companies are doing pair programming type scenarios including a code review for a more accurate representation of a day on the job. Still, there hasn't been this silver bullet companies are looking for to solve their hiring woes.
I don't know the solve. There's also a large problem with those doing the interviewing being either untrained or unempathetic to the candidates.
It started with algorithmic interviews. Then, we tried take home assignments. Now, lots of companies are doing pair programming type scenarios including a code review for a more accurate representation of a day on the job. Still, there hasn't been this silver bullet companies are looking for to solve their hiring woes.
I don't know the solve. There's also a large problem with those doing the interviewing being either untrained or unempathetic to the candidates.
Hiring processes are terrible for lack of accountability, transparency, feedback.
I ran for political office. Endorsement interviews can be either awesome or brutal. One key difference is whether the interview is recorded, and then shared publicly.
It will surprise no one that my worst interviews (in both politics and tech) were behind closed doors.
Worst of all are the 1:1 interviews with inexperienced interviewers. Zero accountability, zero transparency, no feedback loops. They just report whatever they want, are not even expected to explain themselves.
I've since decided that any future job interviews will be recorded and posted. I will definitely embarrass myself. But until someone starts, no improvement can occur.
I ran for political office. Endorsement interviews can be either awesome or brutal. One key difference is whether the interview is recorded, and then shared publicly.
It will surprise no one that my worst interviews (in both politics and tech) were behind closed doors.
Worst of all are the 1:1 interviews with inexperienced interviewers. Zero accountability, zero transparency, no feedback loops. They just report whatever they want, are not even expected to explain themselves.
I've since decided that any future job interviews will be recorded and posted. I will definitely embarrass myself. But until someone starts, no improvement can occur.
At least I can weed out companies with bad hiring practices. They team can't be much better than how they hire.
Having a remote interview with really bad audio, no word on their product, no small talk, just questions without discourse or feedback on my answers? - No thanks.
I'm a bit torn on assignments and trial days. I think they should simply be paid.
Having a remote interview with really bad audio, no word on their product, no small talk, just questions without discourse or feedback on my answers? - No thanks.
I'm a bit torn on assignments and trial days. I think they should simply be paid.
At the company for which I work, we definitely pay something for the take home assignment. Not a ton. It's less a "this is what you'd get paid as a contractor" and more "this is a recognition that you are spending some free time on this and we appreciate it".
Hiring process in our industry has lots of problems and discussing them is one of HN's favourite topics. For remote the bar is higher, simply because not everybody is able to be effective working remotely, so companies are more weary about remote workers.
For ex my company does hire remote but only senior and more exceptional candidates.
For ex my company does hire remote but only senior and more exceptional candidates.
People giving remote-specific response as if that is the only problem. It is probably a contributor as well but frankly I have had very similar experiences interviewing for non-remote jobs.
Unpopular answer: Interviewer Ego
Let's first establish: how are you measuring hiring success?
My company is 100% remote so I have quite a bit of experience with being on the recruitment side.
I think if there was a standard for recruiting that the industry followed, then people would just be thinking of ways to "hack" the standard, so I don't think that would be helpful.
Remote working is desirable and rare but also a lot of companies that recruit for remote workers are very new ones and they often have no clue what they're doing. I think they feel that so long as they make it really hard and unpleasant, they'll be like the other massive internet companies.
To be honest, I also have no real clue what I'm doing but I am trying. Perhaps you could give me some feedback on our process while we're here:
1. A written test where we ask a few questions around the candidate's experience - what's the most interesting thing they've worked on, what recent tech are they most interested in, and we ask them to do a code review of a poorly written method. We have a strong culture of documentation so if the candidate can't write well then it's not going to be a good fit.
2. An online interview where we talk about the company, discuss the test, answer questions and write some code together via screen sharing. This latter part takes the longest part - firstly we write a simple string reverse method, write some unit tests for it, debug another method and design a history API for a browser (which has more edge cases than you'd think). What we're looking for: confidence in programming, code, design and communication.
3. An online or in-person (depending on where the candidate lives) interview with me and our CEO. This part has about a 95% success rate for the candidate, our CEO's just a people person and likes to get to know people.
4. The candidate is hired, and we start assigning work in increasing levels of difficulty. This is a probation period of 3 months.
Stage 4 is still part of the interview, we're able to take advantage of UK labour laws that allow us to let someone go inside 2 years without having too much trouble.
This way we can see them working for real and even if they aren't that good, get some sort of benefit from it. Of course, we might waste some money but it's an opportunity to learn what we need to do better during the interview phase.
For better or worse, capitalism rewards those who take risks. I think the companies with their multi-month long recruitment cycles are putting too much effort into risk minimisation. I'm happy when I hear about my competitors' "brutal" interview processes. It means they're moving slower than me.
I think if there was a standard for recruiting that the industry followed, then people would just be thinking of ways to "hack" the standard, so I don't think that would be helpful.
Remote working is desirable and rare but also a lot of companies that recruit for remote workers are very new ones and they often have no clue what they're doing. I think they feel that so long as they make it really hard and unpleasant, they'll be like the other massive internet companies.
To be honest, I also have no real clue what I'm doing but I am trying. Perhaps you could give me some feedback on our process while we're here:
1. A written test where we ask a few questions around the candidate's experience - what's the most interesting thing they've worked on, what recent tech are they most interested in, and we ask them to do a code review of a poorly written method. We have a strong culture of documentation so if the candidate can't write well then it's not going to be a good fit.
2. An online interview where we talk about the company, discuss the test, answer questions and write some code together via screen sharing. This latter part takes the longest part - firstly we write a simple string reverse method, write some unit tests for it, debug another method and design a history API for a browser (which has more edge cases than you'd think). What we're looking for: confidence in programming, code, design and communication.
3. An online or in-person (depending on where the candidate lives) interview with me and our CEO. This part has about a 95% success rate for the candidate, our CEO's just a people person and likes to get to know people.
4. The candidate is hired, and we start assigning work in increasing levels of difficulty. This is a probation period of 3 months.
Stage 4 is still part of the interview, we're able to take advantage of UK labour laws that allow us to let someone go inside 2 years without having too much trouble.
This way we can see them working for real and even if they aren't that good, get some sort of benefit from it. Of course, we might waste some money but it's an opportunity to learn what we need to do better during the interview phase.
For better or worse, capitalism rewards those who take risks. I think the companies with their multi-month long recruitment cycles are putting too much effort into risk minimisation. I'm happy when I hear about my competitors' "brutal" interview processes. It means they're moving slower than me.
As long as there are clear expectations at each step I think that goes a long way.
why would you choose to work remote - are you retired? no jobs available in your immediate area?
There are lots of jobs in the area. I've worked remotely a few different times in my life and prefer to reduce commute mostly.
I set out attempting to get a remote position and if that failed I would look locally.
It took almost two months where locally I usually could land a position in a month or less.
Locally is a lot easier for sure.
I set out attempting to get a remote position and if that failed I would look locally.
It took almost two months where locally I usually could land a position in a month or less.
Locally is a lot easier for sure.
Why do you ask that?
I work partial remote and every day I go to the office I wish I was fully remote... not because I hate the office (I love it, and really enjoy my co-workers) but because I hate commuting.
I work partial remote and every day I go to the office I wish I was fully remote... not because I hate the office (I love it, and really enjoy my co-workers) but because I hate commuting.
Partial remote or designated telework days make more sense than being fully remote.
However, it seems like you're exchanging any future/potential at a company for the convenience of working remote which why i was asking if he was retired.
However, it seems like you're exchanging any future/potential at a company for the convenience of working remote which why i was asking if he was retired.
In the end I found what I was looking for. It just seems the hiring processes overall is flawed in many ways.
Most were looking for exactly one type with one set of experiences. Anything outside of that and you are filtered out.
Companies seem afraid to hire thinking there is a slightly better/cheaper option around the corner.
There is a fear to pull the trigger compared to local companies. Afraid to take a chance on obvious candidates. Someone with x amount of years in a language but not with a specific framework version. It's like the ability to learn even the smallest thing isn't considered.
Multiple unnecessary rounds of interviews/tests/assignments/group hiring. The long the process ensures the best candidates go elsewhere or are filtered out.
The random unrelated tests.
The take home assignments with random marking standards. Tests can matter, ui could matter, api structure could matter, documentation/choice of framework, speed, style all could matter but you rarely know which matters to whom and rarely have time to do it all and even if you did everything perfectly a lot of the time no one even looks or the reviewer expects the code to look like how they might write it.
Why are the processes so bad?