What we do instead of technical interviews(be.helpful.com)
be.helpful.com
What we do instead of technical interviews
https://be.helpful.com/https-medium-com-fnthawar-helpful-technical-interviews-are-garbage-dc5d9aee5acd
84 comments
Yep, yep.
A conversation on relevant subjects helps filtering out people with fake or stuffed resumes in a matter of minutes, assuming the interviewer is a technical person. It also helps understanding if it's someone we can work with as a colleague. If all goes well, we would make an offer, but will make it clear that the 3 month probation period _is_ the actual interview.
Had very good results with this approach, but it doesn't really scale or work for larger projects with aggressive hiring plans.
A conversation on relevant subjects helps filtering out people with fake or stuffed resumes in a matter of minutes, assuming the interviewer is a technical person. It also helps understanding if it's someone we can work with as a colleague. If all goes well, we would make an offer, but will make it clear that the 3 month probation period _is_ the actual interview.
Had very good results with this approach, but it doesn't really scale or work for larger projects with aggressive hiring plans.
It can scale when the company starts to let go of the notion that only senior devs and managers can do interviews.
I was in a growing company that allowed anyone who had been there six months or more to conduct interviews. It massively increased the speed of recruitment and prevented managers and senior devs being tied up with recruitment stuff.
I was in a growing company that allowed anyone who had been there six months or more to conduct interviews. It massively increased the speed of recruitment and prevented managers and senior devs being tied up with recruitment stuff.
I've done this and then subsequently given a 30 minute coding test. With the coding test I tried to make it match as closely as possible the kind of activities the candidate would actually engage with (e.g. processing a CSV rather than implementing a merge sort).
There wasn't much of a correlation between how well a candidate chatted and how well they coded, and there was some horrendously bad code and terrible habits exhibited by people who talked the talk pretty well.
Conversely, some of the less verbose people wrote excellent code and were often cheaper - possibly because they didn't interview well.
The downside of this approach is that crafting (and iterating upon) a realistic test that exercises all the necessary skills and can be squeezed into 30 minutes is hard work.
There wasn't much of a correlation between how well a candidate chatted and how well they coded, and there was some horrendously bad code and terrible habits exhibited by people who talked the talk pretty well.
Conversely, some of the less verbose people wrote excellent code and were often cheaper - possibly because they didn't interview well.
The downside of this approach is that crafting (and iterating upon) a realistic test that exercises all the necessary skills and can be squeezed into 30 minutes is hard work.
I totally agree with this. The best interviews I've had with candidates have gone like this, and not only do you get a feel for their knowledge in a subject in a more relaxed way it also gives you a bit of a feeling if this person would fit in the team or not.
Being on the other side of the table, interviews done this way has landed me in my most interesting/best jobs, and in the best teams, in my opinion.
Being on the other side of the table, interviews done this way has landed me in my most interesting/best jobs, and in the best teams, in my opinion.
this x1000
I've done maybe 100+ tech interviews, easily. The ones that have been the best have been conversation based. The worst are take home projects that take days to complete. (the worst I had: create a poker game)
A good inbetween can be try-before-you-buy for a day or two, but if the scope of work isn't managed correctly you may not see what you want. I had that happen recently in an interview - i asked what success looked like (being communicative on the work to be done) but at the end was told they didn't see enough front-end work.
If you can't tell within 30 minutes of talking to someone whether they are competent or not, you shouldn't be doing the hiring.
Likewise, if you can't express yourself in a casual setting - what kind of person are you to work with? How will you handle disagreements or feedback? What will you offer the team?
Lastly, if they have OSS work, take a look at it. If they have contributed to an OSS project, take a look at their PR and how they worked with the main devs to get it merged in. That is a much stronger indicator to skill and quality than a random coding exercise.
I've done maybe 100+ tech interviews, easily. The ones that have been the best have been conversation based. The worst are take home projects that take days to complete. (the worst I had: create a poker game)
A good inbetween can be try-before-you-buy for a day or two, but if the scope of work isn't managed correctly you may not see what you want. I had that happen recently in an interview - i asked what success looked like (being communicative on the work to be done) but at the end was told they didn't see enough front-end work.
If you can't tell within 30 minutes of talking to someone whether they are competent or not, you shouldn't be doing the hiring.
Likewise, if you can't express yourself in a casual setting - what kind of person are you to work with? How will you handle disagreements or feedback? What will you offer the team?
Lastly, if they have OSS work, take a look at it. If they have contributed to an OSS project, take a look at their PR and how they worked with the main devs to get it merged in. That is a much stronger indicator to skill and quality than a random coding exercise.
> try-before-you-buy for a day or two
Not very easy to accomplish, from the company perspective. You have to have contracts, NDAs, and a whole bunch of stuff in place, even if the person is gonna only work for a couple of days, or for a week.
Not very easy to accomplish, from the company perspective. You have to have contracts, NDAs, and a whole bunch of stuff in place, even if the person is gonna only work for a couple of days, or for a week.
> Not very easy to accomplish, from the company perspective. You have to have contracts, NDAs, and a whole bunch of stuff in place
FWIW, this has not been my experience. NDA's sometimes, contracts usually - thats about it. overall, 10-20 mins of paperwork tops.
FWIW, this has not been my experience. NDA's sometimes, contracts usually - thats about it. overall, 10-20 mins of paperwork tops.
This is a legal problem for large, stupid slow companies. The beauty of tests is they're hard to sue over.
I used to do this for a multi-national tech conglomerate. Everyone else did technical interviews. I gave a laughably easy tech test (few binary operators). If you mentioned a technology I knew well on your resume I asked you a question about that.
After that, "Tell me about your favorite book, author, movie, album, musician, hobby, magazine. Anything. There's no wrong answer." Just to get a conversation going. I had a number of questions like this. The point was to get them talking.
The most memorable was a Bukowski fan. We talked about his novels and the employer happened to be just a mile from where some of the scenes were set. It was cool because the guy lit UP when he got to talk about it.
The guy who made the worst impression said Freebird was the only thing he could think of, and the last album he could remember buying... when it came out... in 1973...
I observed no correlation between test results and whether the person turned out to be a good hire.
There was also an inverse correlation between competency and "gotcha" questions. One of our least competent engineers was vicious and mean-spirited during interviews. In the 100 or so interviews we did together, the only person he ever liked was his friend. Ironically I fought hard against hiring the interviewer himself but was explicitly instructed that we were seeking "moderately competent" individuals for his role.
Then HR found out about it somehow and forbade me from asking "personal questions" because we "might get sued." I had to stick to a script.
So I quit giving interviews, and we hired people who were good test takers from then on.
I used to do this for a multi-national tech conglomerate. Everyone else did technical interviews. I gave a laughably easy tech test (few binary operators). If you mentioned a technology I knew well on your resume I asked you a question about that.
After that, "Tell me about your favorite book, author, movie, album, musician, hobby, magazine. Anything. There's no wrong answer." Just to get a conversation going. I had a number of questions like this. The point was to get them talking.
The most memorable was a Bukowski fan. We talked about his novels and the employer happened to be just a mile from where some of the scenes were set. It was cool because the guy lit UP when he got to talk about it.
The guy who made the worst impression said Freebird was the only thing he could think of, and the last album he could remember buying... when it came out... in 1973...
I observed no correlation between test results and whether the person turned out to be a good hire.
There was also an inverse correlation between competency and "gotcha" questions. One of our least competent engineers was vicious and mean-spirited during interviews. In the 100 or so interviews we did together, the only person he ever liked was his friend. Ironically I fought hard against hiring the interviewer himself but was explicitly instructed that we were seeking "moderately competent" individuals for his role.
Then HR found out about it somehow and forbade me from asking "personal questions" because we "might get sued." I had to stick to a script.
So I quit giving interviews, and we hired people who were good test takers from then on.
> The guy who made the worst impression said Freebird was the only thing he could think of, and the last album he could remember buying.
Lynyrd Skynyrd's Freebird? That was a song, not an album. The album was called Lynyrd Skynyrd.
Lynyrd Skynyrd's Freebird? That was a song, not an album. The album was called Lynyrd Skynyrd.
Where are you on the spectrum? :)
It requires experienced and technically competent interviewers though. Ideally someone who is more than qualified for the job. In other words, experts.
And sometimes, experts are not available. Either because the only expert is the person you want to hire, or because of a strong divide between HR and technical people.
And sometimes, experts are not available. Either because the only expert is the person you want to hire, or because of a strong divide between HR and technical people.
That's just about the worst way to filter candidates. You are selecting for chatty people.
I am not a chatty person - crippling social anxiety sees to that - and I would much prefer this kind of informal chat to a "real" interview because it removes a lot of the pressure which then helps to alleviate the anxiety enough to show that I know what I'm talking about.
Competent chatty people.
If you can't express your competency during an interview chat I don't see how you could be a good candidate (there are exceptions), nothing more damaging to a team that someone who can't communicate.
If you can't express your competency during an interview chat I don't see how you could be a good candidate (there are exceptions), nothing more damaging to a team that someone who can't communicate.
How about shy people who have a hard time talking to new people? Who only feel comfortable after a couple of days and then they become very chatty? Aren't most developers like that?
Not significantly more than among the population in general, at least not in my experience.
Being able to simulate extroversion for short periods at need is a useful life skill for any introvert - I've found it invaluable in plenty of situations beyond just job interviews.
Being able to simulate extroversion for short periods at need is a useful life skill for any introvert - I've found it invaluable in plenty of situations beyond just job interviews.
I'm sorry but if you have crippling anxiety that you cannot chat about subjects you find interesting then you're going to be a burden on any team.
Selecting only based on chattiness is not good, but filtering out people who cannot even chat is probably a good thing from a company's point of view.
Selecting only based on chattiness is not good, but filtering out people who cannot even chat is probably a good thing from a company's point of view.
No necessarily competent. It could be that they are well read on the subject but have no practical experience in it. So they seem able to converse in the subject's vocabulary but if they were to sit down and try to make something they would fail.
No, you filter on people’s ability to communicate about what they already know.
I've found simply talking to prospective employees (be it software or anything else) about how they work, challenges they've encountered and how they overcame them and figuring out their attitudes has never failed me in hiring.
The bullshit feeling that everyone has to live and breathe coding is the biggest nonsense thing I encounter in this field (software development). A good job with a good work environment is more than enough to get productivity and results from your coworkers.
99.9% of the issues I encounter in companies as a consultant or employee revolve around poor management. They don't have budgets. They don't have plans. They don't have people that understand IT. Their IT doesn't understand how their products affect the bottom line. Add in about 1000 other "management doesn't get it" items and you might be close to the realistic picture.
It's quite depressing in practice.
The bullshit feeling that everyone has to live and breathe coding is the biggest nonsense thing I encounter in this field (software development). A good job with a good work environment is more than enough to get productivity and results from your coworkers.
99.9% of the issues I encounter in companies as a consultant or employee revolve around poor management. They don't have budgets. They don't have plans. They don't have people that understand IT. Their IT doesn't understand how their products affect the bottom line. Add in about 1000 other "management doesn't get it" items and you might be close to the realistic picture.
It's quite depressing in practice.
> I've found simply talking to prospective employees (be it software or anything else) about how they work, challenges they've encountered and how they overcame them and figuring out their attitudes has never failed me in hiring.
At previous jobs, I've run into candidates who interview well but code poorly. They look good at first:
1. Their resume looks reasonable.
2. They sound qualified on a phone screen.
3. They can talk about previous projects.
4. They seem like great people to work with.
...but when put to the test, they can't code. I'm talking really simple stuff, like "You have 40 minutes to write (something no harder than FizzBuzz)." They can use their own laptop, with the language of their choice, and StackOverflow. Or for a job involving Scheme, we asked them reverse a singly-linked list. These were almost insultingly easy tests, given the posted job requirements. But I saw otherwise promising candidates struggle for the better part of an hour.
But asking people to code can also help them get hired. I remember one interviewee who was doing poorly until we asked him to code, and then he solved the coding problems in literally about 20 seconds. We hired him, and he turned out to be a incredibly strong team member for many years.
I think one fair way to handle these things might be to offer interviewees a choice:
1. We can ask you to write code during the interview, or
2. You can submit a link to a small open source project for us to look at.
That gives both people who can't code under pressure and people who don't write code outside their day job an option. And it provides the interviewer with a work sample to discuss in the interview.
At previous jobs, I've run into candidates who interview well but code poorly. They look good at first:
1. Their resume looks reasonable.
2. They sound qualified on a phone screen.
3. They can talk about previous projects.
4. They seem like great people to work with.
...but when put to the test, they can't code. I'm talking really simple stuff, like "You have 40 minutes to write (something no harder than FizzBuzz)." They can use their own laptop, with the language of their choice, and StackOverflow. Or for a job involving Scheme, we asked them reverse a singly-linked list. These were almost insultingly easy tests, given the posted job requirements. But I saw otherwise promising candidates struggle for the better part of an hour.
But asking people to code can also help them get hired. I remember one interviewee who was doing poorly until we asked him to code, and then he solved the coding problems in literally about 20 seconds. We hired him, and he turned out to be a incredibly strong team member for many years.
I think one fair way to handle these things might be to offer interviewees a choice:
1. We can ask you to write code during the interview, or
2. You can submit a link to a small open source project for us to look at.
That gives both people who can't code under pressure and people who don't write code outside their day job an option. And it provides the interviewer with a work sample to discuss in the interview.
>I remember one interviewee who was doing poorly until we asked him to code, and then he solved the coding problems in literally about 20 seconds
It's entirely possible that person just happened to have seen the problem before. Many interviewers would throw additional problems at them if they solved it that quickly because they would assume this. Especially true if you pulled the problem directly from a problem site where it has a high chance of someone seeing it before.
You can get decently far as a programmer in mediocre jobs just knowing how to write a CRUD app. You'd never use modulo or reverse a linked list in these positions, yet they pay $60k+ and otherwise deliver products. The org doesn't care that code is delivered at a bureaucratically slow pace or incredibly simple because it's dysfunctional in the first place, so delivering a feature in 3 days which would take a good programmer 2 hours doesn't matter. Lots of "the user is wrong" pushback when something in the code fails too. Unfortunately, because of the way we're made to write resumes, these positions can be made to appear like any other normal position.
I think it's more interesting that he seemed to do poorly until you gave him code.
This may also sound insulting but I certainly don't mean it to be: maybe your code base isn't that challenging, which is why he is now a strong candidate. Are they doing maintenance, or contributing a lot of new code which requires architectural decisions that weren't previously found in your code (and could be copied)?
It's entirely possible that person just happened to have seen the problem before. Many interviewers would throw additional problems at them if they solved it that quickly because they would assume this. Especially true if you pulled the problem directly from a problem site where it has a high chance of someone seeing it before.
You can get decently far as a programmer in mediocre jobs just knowing how to write a CRUD app. You'd never use modulo or reverse a linked list in these positions, yet they pay $60k+ and otherwise deliver products. The org doesn't care that code is delivered at a bureaucratically slow pace or incredibly simple because it's dysfunctional in the first place, so delivering a feature in 3 days which would take a good programmer 2 hours doesn't matter. Lots of "the user is wrong" pushback when something in the code fails too. Unfortunately, because of the way we're made to write resumes, these positions can be made to appear like any other normal position.
I think it's more interesting that he seemed to do poorly until you gave him code.
This may also sound insulting but I certainly don't mean it to be: maybe your code base isn't that challenging, which is why he is now a strong candidate. Are they doing maintenance, or contributing a lot of new code which requires architectural decisions that weren't previously found in your code (and could be copied)?
> You'd never use modulo or reverse a linked list in these positions
The position I'm thinking of was a senior developer position that involved writing large amounts of Scheme code to interface with a video game engine. Typical Scheme code uses recursion where normal languages would use loops, and singly-linked lists are the most basic Scheme data structure, used for everything. So if you can't reverse a linked link in some language, you're probably not especially qualified for a job as a senior Scheme programmer. Not everything is a CRUD app.
(And it's basically the first homework question you get in a first-year Data Structures class, so it's not too much to ask for a senior dev doing low-level work.)
> I think it's more interesting that he seemed to do poorly until you gave him code.
I've found that some amazing developers have weak people skills. They don't necessarily know how to write a resume, and they don't know how to "sell" themselves in interviews. But they may still be brilliant, dedicated coders, and excellent teammates.
The position I'm thinking of was a senior developer position that involved writing large amounts of Scheme code to interface with a video game engine. Typical Scheme code uses recursion where normal languages would use loops, and singly-linked lists are the most basic Scheme data structure, used for everything. So if you can't reverse a linked link in some language, you're probably not especially qualified for a job as a senior Scheme programmer. Not everything is a CRUD app.
(And it's basically the first homework question you get in a first-year Data Structures class, so it's not too much to ask for a senior dev doing low-level work.)
> I think it's more interesting that he seemed to do poorly until you gave him code.
I've found that some amazing developers have weak people skills. They don't necessarily know how to write a resume, and they don't know how to "sell" themselves in interviews. But they may still be brilliant, dedicated coders, and excellent teammates.
>so it's not too much to ask for a senior dev doing low-level work.
Actually for a senior dev, it is too much to expect low-level work they haven't used in 10 years. The analogy I quite often give is that you wouldn't assess a French teacher on their Latin class from 2005.
The bottom line is that you probably asked a useless question that was great for teaching the CS foundations in school, but that hasn't ever been used once in their careers. People discard useless information, especially smart people because they prize the efficiency that their memory can use in place of useless information.
Actually for a senior dev, it is too much to expect low-level work they haven't used in 10 years. The analogy I quite often give is that you wouldn't assess a French teacher on their Latin class from 2005.
The bottom line is that you probably asked a useless question that was great for teaching the CS foundations in school, but that hasn't ever been used once in their careers. People discard useless information, especially smart people because they prize the efficiency that their memory can use in place of useless information.
Yep. The most critical question I ask if I'm interviewing is "What are the problems?"
I'm not even especially interested in the actual answers, per se. I'm interested in two things: do people know what they are, and are people willing to say so out loud.
I'm not even especially interested in the actual answers, per se. I'm interested in two things: do people know what they are, and are people willing to say so out loud.
So you still do technical interviews, just long ones that require you to quit your current job first.
No thanks.
This might work if you're looking to fill a pipeline with 'good enough' junior people who you can then push into an appropriate role, rather than hiring for something specific.
No thanks.
This might work if you're looking to fill a pipeline with 'good enough' junior people who you can then push into an appropriate role, rather than hiring for something specific.
NEVER quit the job for another one where they just want to sniff you. Try to learn how many people the company is hiring and how many positions long term they want to sustain.
Thanks for engaging.
Actually the offers are exactly the same as if we did 7hours of interviews, so it's not an interview after we hire you.
Let me know if that answers your question.
Actually the offers are exactly the same as if we did 7hours of interviews, so it's not an interview after we hire you.
Let me know if that answers your question.
An actual test drive takes just a few minutes, an hour at most. The "test drives" they suggest take 30 to 90 days... It is not a test, it is a job.
Their suggestion is essentially "you don't need to make sure you are hiring the right people, because you can fix it later by firing them".
I think the flipside of this strategy is that you won't get the people who are good at the job and good at interviews. Imagine I am offered a job where 90% of people pass probation because of a thorough interview process vs one where only 20% pass. If I pass the interview, other things being equal, it is easy to guess the job I'll take. The 20% company won't even have a chance to "test" me.
Their suggestion is essentially "you don't need to make sure you are hiring the right people, because you can fix it later by firing them".
I think the flipside of this strategy is that you won't get the people who are good at the job and good at interviews. Imagine I am offered a job where 90% of people pass probation because of a thorough interview process vs one where only 20% pass. If I pass the interview, other things being equal, it is easy to guess the job I'll take. The 20% company won't even have a chance to "test" me.
I knew a company a bit like this once. The CEO would hire people very quickly. In most cases they didn’t have the appropriate skill set, and had personality issues. They’d have a massive negative impact on the culture of this early stage startup.
They’d then get fired. The CEO would say, it will be better for them in the long term and I’m sure they’ll be happier. This wasn’t true, they had their issues but actually the CEO has screwed them too by not doing the due diligence and hiring too quickly...
Honestly the best solution I can think of is to work as a paid consultant for the company and see how that goes. If the relationship seems to work, then join full time. Not everybody has the time to take on consulting gigs though which is a significant downside.
They’d then get fired. The CEO would say, it will be better for them in the long term and I’m sure they’ll be happier. This wasn’t true, they had their issues but actually the CEO has screwed them too by not doing the due diligence and hiring too quickly...
Honestly the best solution I can think of is to work as a paid consultant for the company and see how that goes. If the relationship seems to work, then join full time. Not everybody has the time to take on consulting gigs though which is a significant downside.
This approach is so far from reality it hurts. What are you learning in 15 minutes that can inform you enough to make a decision to hire someone for a minimum of 90 days? Not enough.
You're missing out on other aspects of hiring like recruiter fees. If I were to hire every idiot that ticked off the boxes but couldn't demonstrate relate knowledge to something tangible I would've put my current and previous company out of business.
Your 90-day long interview process (this is what it is, face it) is not only a financial detriment, but a productivity tumor. Yes, I do agree that the current wide-spread use of "solve this on a whiteboard", "implement merge-sort", or some other backwards method of technical ability does not work; that is why I implement questions, and paired exercises that are tailored to the position they will be filling and the background they're coming from. The process I have in place consists of 3-parts: phone screen, and 2 in-person interviews - this process normally doesn't extend past 3 hours. The interviews are structured as a conversation to make sure the most nervous of interviewees can perform comfortably. I'd rather waste 2 hours more per candidate opposed to ~20-40k GBP for a poor trial, and a decrease in overall team velocity.
You're missing out on other aspects of hiring like recruiter fees. If I were to hire every idiot that ticked off the boxes but couldn't demonstrate relate knowledge to something tangible I would've put my current and previous company out of business.
Your 90-day long interview process (this is what it is, face it) is not only a financial detriment, but a productivity tumor. Yes, I do agree that the current wide-spread use of "solve this on a whiteboard", "implement merge-sort", or some other backwards method of technical ability does not work; that is why I implement questions, and paired exercises that are tailored to the position they will be filling and the background they're coming from. The process I have in place consists of 3-parts: phone screen, and 2 in-person interviews - this process normally doesn't extend past 3 hours. The interviews are structured as a conversation to make sure the most nervous of interviewees can perform comfortably. I'd rather waste 2 hours more per candidate opposed to ~20-40k GBP for a poor trial, and a decrease in overall team velocity.
Great points.
The 90-day interview (as you call it), is the same if we did 3 hours of interviews (like you do) or 15 minutes. We didn't see a better accuracy as we shrunk our interviews down from 3 hours to eventually 15 minutes.
I really like your pairing idea espescially if that's close to the reality of the actual job.
The 90-day interview (as you call it), is the same if we did 3 hours of interviews (like you do) or 15 minutes. We didn't see a better accuracy as we shrunk our interviews down from 3 hours to eventually 15 minutes.
I really like your pairing idea espescially if that's close to the reality of the actual job.
That is a real cruel process. You are taking advantage of your position as an employer - are you at least honest with those people and tell them there's a 90% chance you will fire them in 90 days? Sure, it might be good for you as a company but it's really bad for the 90% of people who quit their job to get fired by you 90 days later because you can't be arsed to interview them. I can't believe you want to be praised for this approach.
If it's really 90% of the people who are left behind, it's probably not good for the company really.
People in existing teams will be very fatigued from getting to know new people and then trying to forget them. This is well documented in the military. After a while veterans don't want to get to know the fresh reinforcements that arrive into their unit, as the new guys will probably die quickly simply because they are inexperienced and thrown to battlefield. As a result, any investment in social relationship with them is wasted. And as a result, the whole unit will get grumpy.
People in existing teams will be very fatigued from getting to know new people and then trying to forget them. This is well documented in the military. After a while veterans don't want to get to know the fresh reinforcements that arrive into their unit, as the new guys will probably die quickly simply because they are inexperienced and thrown to battlefield. As a result, any investment in social relationship with them is wasted. And as a result, the whole unit will get grumpy.
Interesting points.
We never found smart effective folks who did not want to get to know newer smart and effective folks.
We never found smart effective folks who did not want to get to know newer smart and effective folks.
I'd guess there is something like 50% cutoff point.
Less than 50% of hires stay: "oh geez, more meat to the grinder."
More than 50% of hires stay: "A new guy came, do you play ping pong?"
But my cut off point might be way off. And there might be some elasticity between those where people are more iffy about the whole deal.
I'd suggest testing this. Stack slightly not so promising new hires to one team and more promising in other. Let's hope there is different retain rate. Now you can measure the performance changes of both teams and see the net effect.
Less than 50% of hires stay: "oh geez, more meat to the grinder."
More than 50% of hires stay: "A new guy came, do you play ping pong?"
But my cut off point might be way off. And there might be some elasticity between those where people are more iffy about the whole deal.
I'd suggest testing this. Stack slightly not so promising new hires to one team and more promising in other. Let's hope there is different retain rate. Now you can measure the performance changes of both teams and see the net effect.
[deleted]
We are totally transparent about the process, but this is the standard process anywhere. i.e. if I interview at Google (7 hours) and am not a fit within 90 days, I sure hope we both figure that out (and not in 9-12 months). So given the same # of people who would be let go within 90 days, why waste time interviewing them for longer?
So even though this is implicit elsewhere, we make it explicit (if you don't think we're a fit for you, or we don't think you're a fit for us, we'll part ways)
Let me know if that makes sense
So even though this is implicit elsewhere, we make it explicit (if you don't think we're a fit for you, or we don't think you're a fit for us, we'll part ways)
Let me know if that makes sense
No, it's not the same. If unsuccessful at google you will waste a day of your life and and keep your old job. At your place you will waste up to 90 days of your life and lose your old job. Not the same. It's the same to you but it's not the same to the employee.
By interviewing and throwing away potential false negatives you also cut down on the number of people failing probation. You can't have it both ways: not interview and keep the same number of people.
By interviewing and throwing away potential false negatives you also cut down on the number of people failing probation. You can't have it both ways: not interview and keep the same number of people.
For me one skill that stands out as a predictor for performance is the person's ability to do code reviews.
Of course not all decent devs are particularly good at this [1], but from my experience below average ones are consistently unable to find flaws in both their own and someone else's code or even if they do they don't care enough to point that out.
[1] Not saying I'm an especially decent dev, but although I manage, reviews are hard for me because I'm way to lenient - I guess it boils down to trying not to hurt other people's feelings.
EDIT: accidental emphasis
Of course not all decent devs are particularly good at this [1], but from my experience below average ones are consistently unable to find flaws in both their own and someone else's code or even if they do they don't care enough to point that out.
[1] Not saying I'm an especially decent dev, but although I manage, reviews are hard for me because I'm way to lenient - I guess it boils down to trying not to hurt other people's feelings.
EDIT: accidental emphasis
> unable to find flaws in both their own
It would be an interesting interview where they put some of my own code from github/bitbucket down and said "code review this, please". Especially if it was reasonably old and I'd forgotten about it...
It would be an interesting interview where they put some of my own code from github/bitbucket down and said "code review this, please". Especially if it was reasonably old and I'd forgotten about it...
I will add, not just "doing code reviews" but how - what are they like to disagree with? How do they express a different perspective? How methodical are they? What do they look for?
[deleted]
"We interview people who fit the basic criteria, and for less than one hour (sometimes 15 minutes!). If the person seems capable and there aren’t major red flags, we hire them (we use an extremely coarse grained filter). If we have five applicants, sometimes we’ll hire all five. They’re then on a 90 day probationary period to see if they work out…”
Not sure how that would fly outside of the US. In France we have probationary periods but I have never heard of a company hiring multiple people for a full time role (CDI) and then laying off the ones that aren’t the best fit after a couple of months. That sounds to me like a way to get in a bit of trouble - legally, socially, with unions - in the employment context here.
Would be interested in learning whether there’s a French company that does anything like this - maybe a half dozen CDD’s with the express commitment to hire one of the six on a CDI after three months? But who is leaving a CDI on that sort of bet?
Not sure how that would fly outside of the US. In France we have probationary periods but I have never heard of a company hiring multiple people for a full time role (CDI) and then laying off the ones that aren’t the best fit after a couple of months. That sounds to me like a way to get in a bit of trouble - legally, socially, with unions - in the employment context here.
Would be interested in learning whether there’s a French company that does anything like this - maybe a half dozen CDD’s with the express commitment to hire one of the six on a CDI after three months? But who is leaving a CDI on that sort of bet?
I'm an American living in Berlin, and I think the problem here would be more of a cultural one than a legal one. Germans just have an expectation that once hired they will be given every chance to succeed, to the point that firings seem to come across as a shock or an implication of major wrong-doing.
"Hire fast, fire fast" is already ingrained in American startups, so I think the policy outlined in this article would be easier to adopt in the US. Americans in general view jobs as more transient than Europeans do.
"Hire fast, fire fast" is already ingrained in American startups, so I think the policy outlined in this article would be easier to adopt in the US. Americans in general view jobs as more transient than Europeans do.
I think you meant “hire slow, fire fast.” Never heard fast for both.
That's what the article says that is being discussed. Probably you didn't read it.
(1) the article put forward their approach as a novelty; OP claimed he’d never heard such a thing (as being ingrained in American culture already.) These two statements do not contradict one another.
(2) claiming people didn’t read the linked article is actually one of the few things that’s explicitly called out in the HN guidelines as not being kosher. Please don’t.
(2) claiming people didn’t read the linked article is actually one of the few things that’s explicitly called out in the HN guidelines as not being kosher. Please don’t.
In Ireland a recruiter can impose a one year probationary period, but in practice most opt for six months with a two week notice period.
As for Helpful, I wouldn't work for a company that uses those sorts of recruitment practices. What they are doing feels very sketchy to me.
It massively balances the recruitment process in their favour. They are putting all the risk on to the candidates as they have much more to lose if they fail probation. I know from experience short duration jobs on CVs/Resumes raises alarm bells with recruiters. Plus, it could affect benefit entitlements too if they fail probation as that could be seen as a firing.
What if they have one position and decided to hire all five candidates on probation and make them compete against each other? That would be so stressful.
They could also misuse this process to quickly boost staff numbers for a short period instead of hiring contract staff.
It feels like the author is trying to use spin to make what is an unfair recruitment process sound like a good thing.
As for Helpful, I wouldn't work for a company that uses those sorts of recruitment practices. What they are doing feels very sketchy to me.
It massively balances the recruitment process in their favour. They are putting all the risk on to the candidates as they have much more to lose if they fail probation. I know from experience short duration jobs on CVs/Resumes raises alarm bells with recruiters. Plus, it could affect benefit entitlements too if they fail probation as that could be seen as a firing.
What if they have one position and decided to hire all five candidates on probation and make them compete against each other? That would be so stressful.
They could also misuse this process to quickly boost staff numbers for a short period instead of hiring contract staff.
It feels like the author is trying to use spin to make what is an unfair recruitment process sound like a good thing.
Hi there, these are some good points.
This process doesn't put more risk on the employee, because at any job and with any interview process, one would hope that both the company and the candidate are still in the honeymoon period within the first 90 days. So even if I passed the 5 hour interview, I may not pass the first 90 days.
The biggest difference, is that I'm transparent about the fact that interviews are not a good predicator (I guess I could waste everyone's time by spending 5 hours interviewing?)
This process doesn't put more risk on the employee, because at any job and with any interview process, one would hope that both the company and the candidate are still in the honeymoon period within the first 90 days. So even if I passed the 5 hour interview, I may not pass the first 90 days.
The biggest difference, is that I'm transparent about the fact that interviews are not a good predicator (I guess I could waste everyone's time by spending 5 hours interviewing?)
If you hire five people but can only keep one for whatever reason because they are all good, then you have a problem of riches. This is a solvable problem.
Worst case scenario is that you do quality vetting and then place these hires into other organizations that need them and (maybe) don't hire as efficiently. If you're a big org, HR people should know HR people and make that happen. If you're at a small org, just use contacts of the founder/C-suite folks -- good people don't grow on trees and will be welcome additions to other companies/teams.
The more likely result is that a not small percentage of the people actually interview way better than they perform. It's ok to let these people find a new place to work -- they have effectively engaged in false advertising.
Worst case scenario is that you do quality vetting and then place these hires into other organizations that need them and (maybe) don't hire as efficiently. If you're a big org, HR people should know HR people and make that happen. If you're at a small org, just use contacts of the founder/C-suite folks -- good people don't grow on trees and will be welcome additions to other companies/teams.
The more likely result is that a not small percentage of the people actually interview way better than they perform. It's ok to let these people find a new place to work -- they have effectively engaged in false advertising.
> Not sure how that would fly outside of the US. In France we have probationary periods but I have never heard of a company hiring multiple people for a full time role (CDI) and then laying off the ones that aren’t the best fit after a couple of months. That sounds to me like a way to get in a bit of trouble - legally, socially, with unions - in the employment context here.
No problem whatsoever in doing it in post-Communist EU countries. In fact it's the daily bread in low cost and outsourcing centers over there. It's a very fertile land for the most exploitive cost-cutting corporate practices.
No problem whatsoever in doing it in post-Communist EU countries. In fact it's the daily bread in low cost and outsourcing centers over there. It's a very fertile land for the most exploitive cost-cutting corporate practices.
>> "[...] They’re then on a 90 day probationary period to see if they work out…"
> Not sure how that would fly outside of the US.
Why not? The purpose of probationary period is precisely that: to see if things work out. If they don't, the probationary period ends and the employer simply doesn't extend the employment.
> [...] I have never heard of a company hiring multiple people for a full time role (CDI) and then laying off the ones that aren’t the best fit after a couple of months.
From the short fragment you cited I got the impression that the goal is not to choose a single candidate from the bunch, but to keep potentially all of them. Though I may be wrong, as I haven't read TFA.
> Not sure how that would fly outside of the US.
Why not? The purpose of probationary period is precisely that: to see if things work out. If they don't, the probationary period ends and the employer simply doesn't extend the employment.
> [...] I have never heard of a company hiring multiple people for a full time role (CDI) and then laying off the ones that aren’t the best fit after a couple of months.
From the short fragment you cited I got the impression that the goal is not to choose a single candidate from the bunch, but to keep potentially all of them. Though I may be wrong, as I haven't read TFA.
>employer simply doesn't extend the employment
Simple! Simple for the employer but a major issue for the employee.
Americans value corporations over people. In Europe it's the other way around.
Simple! Simple for the employer but a major issue for the employee.
Americans value corporations over people. In Europe it's the other way around.
Depends. If you're unemployed, a two-month stint at this kind of company is certainly better for you than an interview rejection. You get two months' salary, hopefully learn something, and if you think that it would look worse than unemployment on your resume you can always omit it (maybe bring it up in person where you can explain the context).
If, however, you're already employed, joining this company looks like an awful proposition. Assuming they don't lie to their recruits about their likelihood to pass the probationary period, they're gonna have a really hard time recruiting anybody who already has a stable and not-horrible job. This is gonna screw the corporation pretty hard as soon as they need to hire senior people rather than startup cannon fodder.
If, however, you're already employed, joining this company looks like an awful proposition. Assuming they don't lie to their recruits about their likelihood to pass the probationary period, they're gonna have a really hard time recruiting anybody who already has a stable and not-horrible job. This is gonna screw the corporation pretty hard as soon as they need to hire senior people rather than startup cannon fodder.
>> employer simply doesn't extend the employment
> Simple! Simple for the employer but a major issue for the employee.
Well, yes, but from what I see around me, it's a standard practice to first hire for the probationary period of three months, so an employee has to take this into the account. And unless the employee is highly incompetent or the employer is outright hostile, the probationary period usually ends with regular employment.
It's good that the Europe is generally favourable towards the employees, but employers also need a little slack, don't you think? We can't only put obstacles in their way.
> Simple! Simple for the employer but a major issue for the employee.
Well, yes, but from what I see around me, it's a standard practice to first hire for the probationary period of three months, so an employee has to take this into the account. And unless the employee is highly incompetent or the employer is outright hostile, the probationary period usually ends with regular employment.
It's good that the Europe is generally favourable towards the employees, but employers also need a little slack, don't you think? We can't only put obstacles in their way.
[deleted]
I'm delighted to see comments that show some people here actually get this. While my conclusions are based only on my own experience, they have served me well so far. In the dozens of interviews that I've conducted over the years, not once did I need to resort to quizzes that do a fine job of showing how a person can answer a quiz under pressure of an interview but not much beyond that. Most of the important qualities I'm interested in concerning an applicant have very little to do with this sort of ability. A decision based on a chat which reveals more than any professional quiz ever could (if you know how to listen) is usually a better one.
Not only do I refuse to ask candidates quizzes, but after getting enough professional experience, I started refusing to answer them when I was looking for new positions. One such case involved two executives that interviewed me for a certain senior R&D position. The interview was going well when at a certain point one of them asked if he could test me on some professional stuff. I politely answered that while I respect their candidate filtering methods, it doesn't fit my MO and that I'll pass on that. Not surprisingly, I later received a negative reply from them. A couple of weeks passed and I was hired for the same position by a much larger company (and with much better compensation) that didn't insist on me standing next to a whiteboard to see if I can pick up on some silly trick. About 3 months later, I received a call from one of the executives in the company from which I received a negative reply. Apparently they hired someone who had managed to pass their interview tests with flying colours, but was terrible at his job and so they asked me whether I would like to work for them (of course, this time with no tests). I said I'll pass on that too.
I think the reason for the difficulty in finding the right people for the job stems from a deeper problem of people having lost touch with their inner drive and resorting to external means to understand what is good for them. It starts in grade school and continues on from there. This is not a problem that can (or should) go away quickly, but the more I see people at least being aware of the issue, the more hopeful I am that a more sane process for people fulfilling their potential will eventually replace the existing method.
Not only do I refuse to ask candidates quizzes, but after getting enough professional experience, I started refusing to answer them when I was looking for new positions. One such case involved two executives that interviewed me for a certain senior R&D position. The interview was going well when at a certain point one of them asked if he could test me on some professional stuff. I politely answered that while I respect their candidate filtering methods, it doesn't fit my MO and that I'll pass on that. Not surprisingly, I later received a negative reply from them. A couple of weeks passed and I was hired for the same position by a much larger company (and with much better compensation) that didn't insist on me standing next to a whiteboard to see if I can pick up on some silly trick. About 3 months later, I received a call from one of the executives in the company from which I received a negative reply. Apparently they hired someone who had managed to pass their interview tests with flying colours, but was terrible at his job and so they asked me whether I would like to work for them (of course, this time with no tests). I said I'll pass on that too.
I think the reason for the difficulty in finding the right people for the job stems from a deeper problem of people having lost touch with their inner drive and resorting to external means to understand what is good for them. It starts in grade school and continues on from there. This is not a problem that can (or should) go away quickly, but the more I see people at least being aware of the issue, the more hopeful I am that a more sane process for people fulfilling their potential will eventually replace the existing method.
As someone who recently rejected a company who wanted a 2-3 hour test + 90 minute interview after a 45 minute phone interview (which I did), this is gratifying to read.
I'm not a fan of technical interviews, at least not whiteboard ones, or asking people trick questions, or algorithm analysis bingo.
I like to work through a problem. The problem is synthetic, unfortunately, but anything actually relevant will give too much of a leg up to people who are familiar with frameworks. Steps: (a) discuss the problem and come up with potential solutions, and once we've agreed on a solution (b) turn the solution into code in any language they want, as long as we can easily install it on Ubuntu. An explicit non-goal is actually coming up with a solution to the problem: it's great if they do come up with a solution, but far more important is mind-melding on a problem and solution, and being able to convert agreed solutions into working code.
The idea is to simulate work: I assume that everyone we interview has at least basic ability to code (we use a Codility pre-check), so I create a scenario where I'd be helping set up a team member to work on a functional piece of the application. Communicate and ensure we have a shared understanding of the problem, discuss a solution, and see them actually produce a solution.
Once we have a solution, I do want to know if they understand what the performance characteristics are; that's a very practical concern, as the company I work for deals with data batches ranging in 100 items to 10 million items, so code should be written to scale linearly at worst.
I like to work through a problem. The problem is synthetic, unfortunately, but anything actually relevant will give too much of a leg up to people who are familiar with frameworks. Steps: (a) discuss the problem and come up with potential solutions, and once we've agreed on a solution (b) turn the solution into code in any language they want, as long as we can easily install it on Ubuntu. An explicit non-goal is actually coming up with a solution to the problem: it's great if they do come up with a solution, but far more important is mind-melding on a problem and solution, and being able to convert agreed solutions into working code.
The idea is to simulate work: I assume that everyone we interview has at least basic ability to code (we use a Codility pre-check), so I create a scenario where I'd be helping set up a team member to work on a functional piece of the application. Communicate and ensure we have a shared understanding of the problem, discuss a solution, and see them actually produce a solution.
Once we have a solution, I do want to know if they understand what the performance characteristics are; that's a very practical concern, as the company I work for deals with data batches ranging in 100 items to 10 million items, so code should be written to scale linearly at worst.
We've often found that employers want to see a willingness and ability to learn and adapt to new challenges as opposed to a candidate having an encyclopedic knowledge of coding languages etc. With a competent knowledge of your market you can be taught the rest of your role but if you're unable to articulate your goals and mission to non-technical people you'll often come unstuck when trying to communicate what your doing to others.
This seems a lot more important in the hiring process for tech people now as technology is usually the product or output of a company as opposed to being shut up in a basement somewhere just helping a company operate.
We've just spoke to an internal IT recruiter about this and he's echoed a lot of the sentiments put across in this thread. Links below if you wanna listen :)
http://www.venturi-group.com/podcast/internal-recruitment/
This seems a lot more important in the hiring process for tech people now as technology is usually the product or output of a company as opposed to being shut up in a basement somewhere just helping a company operate.
We've just spoke to an internal IT recruiter about this and he's echoed a lot of the sentiments put across in this thread. Links below if you wanna listen :)
http://www.venturi-group.com/podcast/internal-recruitment/
I had a 3-month job search over the last summer, encompassing about 150 contacts which I filtered into roughly 25 actual interviews. It takes an enormous amount of time to deal with all the various interview techniques out there. Such as:
* Four or five-hour interviews. * Interview prep suggested by recruiters for tech interviews. * All-day work sessions pairing with employees. * "Homework" that can take anywhere from 5 hours to days. * Multiple online sessions, each to solve a tech riddle.
I can't imagine how I could've done this when holding a job at the same time. I'd have to be incredibly picky about who I chose to interview with - which means, I wouldn't have interviewed with my current company because they didn't interest me during the screening, only until after the interview when I got to talk with actual developers.
* Four or five-hour interviews. * Interview prep suggested by recruiters for tech interviews. * All-day work sessions pairing with employees. * "Homework" that can take anywhere from 5 hours to days. * Multiple online sessions, each to solve a tech riddle.
I can't imagine how I could've done this when holding a job at the same time. I'd have to be incredibly picky about who I chose to interview with - which means, I wouldn't have interviewed with my current company because they didn't interest me during the screening, only until after the interview when I got to talk with actual developers.
This makes no sense to me.
Most candidates aren't unemployed; they're switching jobs. Leaving a job they don't like, or looking for an upgrade. Many have to be persuaded to leave their current employer.
If I were thinking about switching, I'd want a lot more commitment from my future employer than "we'll hire you and four more guys for the same position, then we'll see which one of you will last 90 days". Regardless of my confidence in being able to do the job, who wants to compete for a job for 90 days? Interviews are horrible and stressful, but this is just replacing them with what is essentially a 90 day interview for which you have you quit your current job.
Most candidates aren't unemployed; they're switching jobs. Leaving a job they don't like, or looking for an upgrade. Many have to be persuaded to leave their current employer.
If I were thinking about switching, I'd want a lot more commitment from my future employer than "we'll hire you and four more guys for the same position, then we'll see which one of you will last 90 days". Regardless of my confidence in being able to do the job, who wants to compete for a job for 90 days? Interviews are horrible and stressful, but this is just replacing them with what is essentially a 90 day interview for which you have you quit your current job.
This is a particularly bizarre article to come from someone who is ex-Pivotal, given that Pivotal's interviews are all-day pair programming on real code (mostly) rather than whiteboard nonsense, and don't suffer from the problems described here. AFAIK, Farhan came in through Pivotal's acquisition of Xtreme Labs, but I thought the point of Xtreme Labs was that they copied the Pivotal way of doing things, including hiring.
Also:
> For example, let’s say that someone is working on our mobile client and it’s not going as quickly as we need it to go. We’ll
... work with them to identify and remove the impediments slowing them down, while revising our plan to be more realistic?
> let them know that they need to speed up
This guy is an asshole.
Also:
> For example, let’s say that someone is working on our mobile client and it’s not going as quickly as we need it to go. We’ll
... work with them to identify and remove the impediments slowing them down, while revising our plan to be more realistic?
> let them know that they need to speed up
This guy is an asshole.
Is it only me who can't think properly when constantly being prodded to by a bunch of people ? I also feel that the game is so rigged that one doesn't have any real option other than to be pretentious; to be the "model programmer" who is "passionate" about whatever shit that the company is doing; to fit into the "culture" of whatever flavor of WASP is running it. Frankly, SV bullshit smells worse than Trump's hotel bed.
No, it's not only you who can't think when being prodded. I have similar issues.
Actually, my issues are kind of entertaining when they don't get in the way of my livelihood. My brain appears to prioritize processing interaction with people, especially strangers, over some other kinds of activity, including the kind that's needed to solve logic problems. Ask me to take some open-ended time alone to write a solution to a problem, and I'll give you one when I'm done. Ask me to do the same thing with people watching or, worse, interacting with me as I do it, and you will get random results that may or may not bear any relation to the problem.
It affects things other than coding. When she was a teenager, my daughter sometimes engaged me in conversation when I was driving somewhere, just to see where we would end up. I remember a particular instance of winding up in the parking lot of a Safeway in Capitola, California, wondering why I was there, while my daughter laughed her head off.
I've been at this programming thing for a long time now. I have a reasonable idea of how good I am at it. Given the right circumstances and the right kinds of problems, I can be (and have been) extremely productive. I've been described by someone paying me as one of those "10X" programmers, and the dvcs logs bore him out (but I know what he didn't: if the tools and goals and problem space had been different, or if the work circumstances had been different, then I wouldn't have been nearly as productive).
But technical interviews aren't going to reveal any of that, certainly not about me, specifically. I'm always going to look like something between an idiot and a mediocrity in the typical technical interview.
Various critics are complaining that the OP's methods aren't going to work, but all the data we have says that current fashions in hiring already don't work. The correlation between interview performance and job performance is laughable. Companies all like to say they hire "the best"; what they really mean is that they hire the best that currently-known methods can distinguish, which is to say, a random selection of people. About the most you can say about current methods is that they select for people who want a job, which I suppose is better for hiring than pure sortition.
We don't know how to hire good people in technology. Popular hiring strategies are voodoo. The only method that has been shown to produce much better results than chance is blind, standardized skills-testing, which is not currently popular.
Technical interviews are nonsense. The proper role of interviewing is to find out whether the candidate seems to be a glaring asshole. If you want to select for skills, administer standardized tests. If you don't want to do that, then it doesn't matter much what you do. It all seems to be about equally useless.
You might try doing a Tarot card reading for the candidate.
Actually, my issues are kind of entertaining when they don't get in the way of my livelihood. My brain appears to prioritize processing interaction with people, especially strangers, over some other kinds of activity, including the kind that's needed to solve logic problems. Ask me to take some open-ended time alone to write a solution to a problem, and I'll give you one when I'm done. Ask me to do the same thing with people watching or, worse, interacting with me as I do it, and you will get random results that may or may not bear any relation to the problem.
It affects things other than coding. When she was a teenager, my daughter sometimes engaged me in conversation when I was driving somewhere, just to see where we would end up. I remember a particular instance of winding up in the parking lot of a Safeway in Capitola, California, wondering why I was there, while my daughter laughed her head off.
I've been at this programming thing for a long time now. I have a reasonable idea of how good I am at it. Given the right circumstances and the right kinds of problems, I can be (and have been) extremely productive. I've been described by someone paying me as one of those "10X" programmers, and the dvcs logs bore him out (but I know what he didn't: if the tools and goals and problem space had been different, or if the work circumstances had been different, then I wouldn't have been nearly as productive).
But technical interviews aren't going to reveal any of that, certainly not about me, specifically. I'm always going to look like something between an idiot and a mediocrity in the typical technical interview.
Various critics are complaining that the OP's methods aren't going to work, but all the data we have says that current fashions in hiring already don't work. The correlation between interview performance and job performance is laughable. Companies all like to say they hire "the best"; what they really mean is that they hire the best that currently-known methods can distinguish, which is to say, a random selection of people. About the most you can say about current methods is that they select for people who want a job, which I suppose is better for hiring than pure sortition.
We don't know how to hire good people in technology. Popular hiring strategies are voodoo. The only method that has been shown to produce much better results than chance is blind, standardized skills-testing, which is not currently popular.
Technical interviews are nonsense. The proper role of interviewing is to find out whether the candidate seems to be a glaring asshole. If you want to select for skills, administer standardized tests. If you don't want to do that, then it doesn't matter much what you do. It all seems to be about equally useless.
You might try doing a Tarot card reading for the candidate.
Yeah. No. I'd never like to interview with a company which just hires me (I don't think I've any red flags) and then after 3 months tells me "Sorry, we only had to hire 2, we hired 5, and though you're good, you're not as good as Mr. X". I'd rather work at a place which has the intention of keeping me for a long time.
"Tons of great people, and, disproportionately, women and minorities, can perform less well at technical interviews but be great in role."
You lost all your credibility with one sentence. Congratulations.
You lost all your credibility with one sentence. Congratulations.
I cringed too. This is akin to a religious dogma at many places I have worked at and is a huge red flag for me, as an employee.
However, the rest of the article makes some good points (testing on the ability to do the job is a better predictor of job performance), you shouldn’t dismiss it out of hand.
However, the rest of the article makes some good points (testing on the ability to do the job is a better predictor of job performance), you shouldn’t dismiss it out of hand.
> You lost all your credibility with one sentence. Congratulations.
Can you explain the basis for that opinion?
Can you explain the basis for that opinion?
I think this sentence was added to fit the "we're more diverse" narrative in the beginning of the article
The poor guy is simply unaware he is a misogynist.
The data available shows that women and minorities ARE under represented in the tech industry. Corellation does not imply causation, but if you have a limited number of causal factors during the hiring process, the logical conclusion is that parts of the hiring process contribute to this under representation in significant ways.
Perhaps the focus is wrong. Perhaps it's not the 'technical' part of the technical interview that causes this disparity. Perhaps it's just good ol' fashioned racism or prejudices, and really the part of the technical interview that causes a disproportionate number of white males to be hired is simply the fact that the interviews happen with the interviewer fully cognizant of the applicants race and gender. You'll notice that the article also mentioned their disdain for being able to see the applicant.
To dismiss a fact that reasonably straightforwardly follows from empirical evidence and limited options for causality is simply obstinancr.
Perhaps the focus is wrong. Perhaps it's not the 'technical' part of the technical interview that causes this disparity. Perhaps it's just good ol' fashioned racism or prejudices, and really the part of the technical interview that causes a disproportionate number of white males to be hired is simply the fact that the interviews happen with the interviewer fully cognizant of the applicants race and gender. You'll notice that the article also mentioned their disdain for being able to see the applicant.
To dismiss a fact that reasonably straightforwardly follows from empirical evidence and limited options for causality is simply obstinancr.
Multiple problems with your argumentation:
1. women and minorities are underrepresented. True. That does not imply there is sexism. In reality, women have a 2:1 chance over men to get hired, just because everyone is desperate to hire women. Be it to improve the image, whatever. Source http://news.cornell.edu/stories/2015/04/women-preferred-21-o...
2. Norway (correct me if I'm wrong on the country) experimented with genderless and faceless applications. The result: Men were actually favoured over women in STEM. How can we explain that? It's certainly not sexism.
At the end of the day, it comes down to this: it is very controversial to say men and women chose differently, but they do. And there's nothing wrong with that! Isn't that what early feminists fought for? Were is the "sexism" in plumbing, oil rigs, and other less desirable jobs? There are virtually only men on those jobs. Tells you what these "diversity" people really are: jealous.
EDIT: Grammar
1. women and minorities are underrepresented. True. That does not imply there is sexism. In reality, women have a 2:1 chance over men to get hired, just because everyone is desperate to hire women. Be it to improve the image, whatever. Source http://news.cornell.edu/stories/2015/04/women-preferred-21-o...
2. Norway (correct me if I'm wrong on the country) experimented with genderless and faceless applications. The result: Men were actually favoured over women in STEM. How can we explain that? It's certainly not sexism.
At the end of the day, it comes down to this: it is very controversial to say men and women chose differently, but they do. And there's nothing wrong with that! Isn't that what early feminists fought for? Were is the "sexism" in plumbing, oil rigs, and other less desirable jobs? There are virtually only men on those jobs. Tells you what these "diversity" people really are: jealous.
EDIT: Grammar
Sexism isn't real. Men actually have it twice as hard as women, because companies hire women just to make them look good. Here's a link to one source that proves this forever.
Norway hired men more often than women with genderless applications. Science cannot explain this, just like the tides of the ocean, or magnets.
At the end of the day, people fighting for equal representation are just jealous, and they can't accept that their Y chromosome made them not want to work on an oil rig.
Norway hired men more often than women with genderless applications. Science cannot explain this, just like the tides of the ocean, or magnets.
At the end of the day, people fighting for equal representation are just jealous, and they can't accept that their Y chromosome made them not want to work on an oil rig.
well, I wish I could be that direct sometimes :D
> To dismiss a fact that reasonably straightforwardly follows from empirical evidence and limited options for causality is simply obstinancr.
Simpler explanation: there are less women applying and therefore less women selected. IMO framing an individual getting a job as “representing” a particular group is just faulty thinking created by a faulty ideology.
Simpler explanation: there are less women applying and therefore less women selected. IMO framing an individual getting a job as “representing” a particular group is just faulty thinking created by a faulty ideology.
>The data available shows that women and minorities ARE under represented in the tech industry.
That wasn't the claim.
That wasn't the claim.
Try reading the sentence that followed that.
So "correlation does not imply causation, but correlation does imply causation."?
Technical interviews are just a form of an expensive filter that works for big companies and should be considered as a warmup.
Women, minorities?! At this point even those "privileged" (male, qualified, experienced) have problem getting hired. The technical recruitment has become perpetuum-mobile of job postings, assignments, countless audio and video calls, technical teasing. Sometimes I'm wondering - is there any actual hiring happening? I have impression there are people in companies who are literally getting paid for creating recruitment noise and infinite "hiring".
Just let the candidate talk about their career and what they have done. Ask their opinion of certain things. Ask about how they tackled certain projects and give them the time to answer and go off on tangents. Treat it like you are a few friends having an in-depth discussion over drinks.
Technical interviews focus too much on headline points. They want the candidate to touch on or mention certain things that everyone should know about the subject. I'm not interested in that, I'm more interested about them mentioning less obvious things such as known quirks, bugs or tricks about the subject matter. Stuff that only a regular user would learn about.
The problem with this approach is that for many companies HR insists on structured interviews. I once had do some interviews for a couple of C# roles. The interview format was literally the same as the game show Talk About. The interviewee was given time to talk about a subject and we had to tick off a list whether they mentioned certain keywords and phrases in the allotted time. The same format applied to the HR interview. Whoever scored highest got the job, a very silly way to do recruitment.