4 ms·

And I wonder how often a candidate actually follows up to ask why they failed and whether many interviewers will give honest/complete answers.

gwbas1c 5y ago
I'd never give a detailed answer, because I don't want future candidates to cheat. The last thing I want is for someone to share my interview, and then I can no longer filter out bad candidates. It takes a super-long time to write a good interview. But, more importantly, very few candidates fail on a single question. They usually fail on patterns: Poor comprehension of the task at hand, too many snap judgements, or lack of professionalism. (Another reason, though, is that I've rejected a lot of people who I believe shouldn't be software engineers. It's not my place to tell them they should pick another career, nor do I want to make it easier for them to bluff their way to becoming someone else's headache.)
- thanhhaimai 5y ago
  Opinions are my own. If you rely on a "not-leaked" interview to filter out bad candidates, it's likely that you may not be conducting an effective interview. Good interview is about figuring out "what the candidate is good at" not about "gotcha I proved that you're a bad one to filter out". I don't have a set of questions I ask all the candidates. Instead, I based the questions on their experience and projects. It's common that I found out "the candidate is not as good as they claim for this subject", and that's fine. The interviewer can switch the topic and see if the candidate is good at another subject. Everyone is good at something. The job of the interviewer is to find out that, and whether that fits the business needs. The job of the hiring committee is to decide whether it's worth paying for that compared to other candidates. The only "filtering candidates" job is the recruiter, not the interviewer.
  - lamontcg 5y ago
    Yeah my interview questions are more jumping off points to have a conversation. At some point I'd most like the candidate to actively start teaching me something that I didn't know and generally geeking out about something and displaying some skill at getting to the lower levels of problems and its the "off script" discussions which are best. And then just avoid any personality red flags. You can't really cram for that.
  - Turing_Machine 5y ago
    Indeed... the whole "trick question" school of interviewing is basically an admission that this industry has absolutely no idea how to reliably rate job candidates (I'm not claiming that I have a magic solution myself, note...). Doctors don't, in general, get asked trick/gotcha questions when they apply for jobs. Neither do lawyers. Neither do other kinds of engineers. Neither do musicians, for that matter. From long-ago undergrad I remember that there is a data structure called a "red-black tree". Now, I've never had that as an interview question, but I could easily imagine it being one. Would I be able to answer a cold question on red-black trees? Nope. As I said, that was a long time ago, and I've never had to use one to the best of my knowledge. Would that be a good reason to filter me out? Nope. If I needed to use a red-black tree (or, in general, had a problem where some unusual type of tree might be in order), I'd pull my copies of Knuth, CLR* and Sedgewick off the shelf, look at strengths and weaknesses of the different types of tree, and make a decision. * mine is old enough that it's just CLR, not CLRS :-)
  - handrous 5y ago
    I've seen a lot of this. FAANG practically release a study guide, while tons of smaller companies think their precious little process will fall apart if the candidates even know the sort of interview they conduct up front. Will there be leetcode-type questions? Roughly which level? Laptop, or whiteboard? Should I expect to be quizzed on networking? Javascript "gotchas" for crap I reflexively avoid so may have forgotten about? UX principles? Will the questions be general, or specific? Will it be a mix? How much, if any, of the day will be whiteboard stuff, and which part of the day will it be in? The answers to these, and more, you should provide up front, without being asked, well ahead of time. Your signal will go up, not down, if your candidates have half a clue what to expect, out of the space of all things that might be asked in a software developer interview. Keeping this stuff a mystery and ambushing your candidate at 9AM sharp with data structure whiteboard questions, after they've flown for two hours to get to you, got up early, were on a plane then in a taxi for a while, et c., when they didn't know you were gonna do something like that, is just giving you tons of false negatives. Knock that shit off, you're wasting money and giving people bad days for no reason. That, or just stop expecting people to "naturally" be able to pull this stuff out of their head and perform for you like a monkey, while in a stressful and semi-adversarial situation that does not resemble collaboration and teamwork in a real job (there's the excuse that "well you have to be able to perform under pressure" but interview pressure has nothing to do with, say, "prod broke and the DB went bye-bye" pressure, so that's bullshit, too). And then communicate that fact—that you're not going to torture them—too, so they don't have to stress out over it.
  - gwbas1c 5y ago
    > The only "filtering candidates" job is the recruiter, not the interviewer Then what's the point of the interview? Considering the amount of incompetent candidates I've had to filter out, that just won't work. IMO: We need a licensing board to do that for us. It works really well in other industries, where they don't need to test competence in their job interviews.
garmaine 5y ago
At my last startup I was advised not to give honest feedback, since no matter your intentions it is possible it could be construed to be discriminatory :(
zomglings 5y ago
Very rarely. And they shouldn't trust any answers that they receive. It's difficult to give an honest answer to this question even if you want to be honest. There are often so many little reasons that go into a rejection -- different reasons for different interviewers all feeding into an activation function that leads to a rejection or an acceptance (default state depends on team culture and how well you filter out candidates at the top of the funnel). For most candidates, it's very hard to distill this into actionable criticism. Edit: For anyone fundraising, this is also why you shouldn't listen too carefully to the reasons that investors give you when they reject your business as an investment.
- justin_oaks 5y ago
  I agree that people shouldn't trust the answers they receive. All of us frequently give inaccurate explanations for our actions or attitudes because people often act on feelings, not on logic. Even when we want to be honest, we often lack the self awareness to know what what we're feeling and why. On top of that, there are many who don't want to be honest, and will give an answer, any answer, just to make you stop asking and go away.
tonyedgecombe 5y ago
Even if a candidate gets an answer I'm doubtful the response will be much use. We like to think of ourselves as rational but I'm willing to bet most hiring decisions are anything but. They might well tell you your skills are lacking when the reality is you remind the recruiter of the guy who ran off with his wife.
saghm 5y ago
It's fairly common for companies to instruct interviewers not to tell candidates why they failed if they reach out for fear of being sued over the response. It really sucks for candidates, but given that it essentially costs companies nothing to have this policy, I'm not surprised they do; no company is going to make a choice that has even a small risk of a huge negative downside if there are no direct obvious upsides to counter it.
justin_oaks 5y ago
It's rare to get an employer to give any honest reason for a rejection. As others have pointed out, it may be for fear of getting sued, but that is only part of the general reason: Further interaction with the job candidate almost certainly has a negative ROI (return on investment) for the employer. If you tell the job candidate the honest reasons for rejection then at best you've used (wasted?) some time to tell the candidate this. At worst, the candidate sues. But there are many other possibilities: The job candidate gets angry at you for telling them a hard-to-swallow truth and causes a scene. The candidate tries to argue or negotiate with you. The candidate accepts the truth and tries to use more of your time to discuss your original criticism and seek further advice. None of these scenarios are a net positive for the employer.

gwbas1c 5y ago

I'd never give a detailed answer, because I don't want future candidates to cheat. The last thing I want is for someone to share my interview, and then I can no longer filter out bad candidates. It takes a super-long time to write a good interview. But, more importantly, very few candidates fail on a single question. They usually fail on patterns: Poor comprehension of the task at hand, too many snap judgements, or lack of professionalism. (Another reason, though, is that I've rejected a lot of people who I believe shouldn't be software engineers. It's not my place to tell them they should pick another career, nor do I want to make it easier for them to bluff their way to becoming someone else's headache.)

thanhhaimai 5y ago
Opinions are my own. If you rely on a "not-leaked" interview to filter out bad candidates, it's likely that you may not be conducting an effective interview. Good interview is about figuring out "what the candidate is good at" not about "gotcha I proved that you're a bad one to filter out". I don't have a set of questions I ask all the candidates. Instead, I based the questions on their experience and projects. It's common that I found out "the candidate is not as good as they claim for this subject", and that's fine. The interviewer can switch the topic and see if the candidate is good at another subject. Everyone is good at something. The job of the interviewer is to find out that, and whether that fits the business needs. The job of the hiring committee is to decide whether it's worth paying for that compared to other candidates. The only "filtering candidates" job is the recruiter, not the interviewer.
- lamontcg 5y ago
  Yeah my interview questions are more jumping off points to have a conversation. At some point I'd most like the candidate to actively start teaching me something that I didn't know and generally geeking out about something and displaying some skill at getting to the lower levels of problems and its the "off script" discussions which are best. And then just avoid any personality red flags. You can't really cram for that.
- Turing_Machine 5y ago
  Indeed... the whole "trick question" school of interviewing is basically an admission that this industry has absolutely no idea how to reliably rate job candidates (I'm not claiming that I have a magic solution myself, note...). Doctors don't, in general, get asked trick/gotcha questions when they apply for jobs. Neither do lawyers. Neither do other kinds of engineers. Neither do musicians, for that matter. From long-ago undergrad I remember that there is a data structure called a "red-black tree". Now, I've never had that as an interview question, but I could easily imagine it being one. Would I be able to answer a cold question on red-black trees? Nope. As I said, that was a long time ago, and I've never had to use one to the best of my knowledge. Would that be a good reason to filter me out? Nope. If I needed to use a red-black tree (or, in general, had a problem where some unusual type of tree might be in order), I'd pull my copies of Knuth, CLR* and Sedgewick off the shelf, look at strengths and weaknesses of the different types of tree, and make a decision. * mine is old enough that it's just CLR, not CLRS :-)
- handrous 5y ago
  I've seen a lot of this. FAANG practically release a study guide, while tons of smaller companies think their precious little process will fall apart if the candidates even know the sort of interview they conduct up front. Will there be leetcode-type questions? Roughly which level? Laptop, or whiteboard? Should I expect to be quizzed on networking? Javascript "gotchas" for crap I reflexively avoid so may have forgotten about? UX principles? Will the questions be general, or specific? Will it be a mix? How much, if any, of the day will be whiteboard stuff, and which part of the day will it be in? The answers to these, and more, you should provide up front, without being asked, well ahead of time. Your signal will go up, not down, if your candidates have half a clue what to expect, out of the space of all things that might be asked in a software developer interview. Keeping this stuff a mystery and ambushing your candidate at 9AM sharp with data structure whiteboard questions, after they've flown for two hours to get to you, got up early, were on a plane then in a taxi for a while, et c., when they didn't know you were gonna do something like that, is just giving you tons of false negatives. Knock that shit off, you're wasting money and giving people bad days for no reason. That, or just stop expecting people to "naturally" be able to pull this stuff out of their head and perform for you like a monkey, while in a stressful and semi-adversarial situation that does not resemble collaboration and teamwork in a real job (there's the excuse that "well you have to be able to perform under pressure" but interview pressure has nothing to do with, say, "prod broke and the DB went bye-bye" pressure, so that's bullshit, too). And then communicate that fact—that you're not going to torture them—too, so they don't have to stress out over it.
- gwbas1c 5y ago
  > The only "filtering candidates" job is the recruiter, not the interviewer Then what's the point of the interview? Considering the amount of incompetent candidates I've had to filter out, that just won't work. IMO: We need a licensing board to do that for us. It works really well in other industries, where they don't need to test competence in their job interviews.

garmaine 5y ago

At my last startup I was advised not to give honest feedback, since no matter your intentions it is possible it could be construed to be discriminatory :(

zomglings 5y ago

Very rarely. And they shouldn't trust any answers that they receive. It's difficult to give an honest answer to this question even if you want to be honest. There are often so many little reasons that go into a rejection -- different reasons for different interviewers all feeding into an activation function that leads to a rejection or an acceptance (default state depends on team culture and how well you filter out candidates at the top of the funnel). For most candidates, it's very hard to distill this into actionable criticism. Edit: For anyone fundraising, this is also why you shouldn't listen too carefully to the reasons that investors give you when they reject your business as an investment.

justin_oaks 5y ago
I agree that people shouldn't trust the answers they receive. All of us frequently give inaccurate explanations for our actions or attitudes because people often act on feelings, not on logic. Even when we want to be honest, we often lack the self awareness to know what what we're feeling and why. On top of that, there are many who don't want to be honest, and will give an answer, any answer, just to make you stop asking and go away.

tonyedgecombe 5y ago

Even if a candidate gets an answer I'm doubtful the response will be much use. We like to think of ourselves as rational but I'm willing to bet most hiring decisions are anything but. They might well tell you your skills are lacking when the reality is you remind the recruiter of the guy who ran off with his wife.

saghm 5y ago

It's fairly common for companies to instruct interviewers not to tell candidates why they failed if they reach out for fear of being sued over the response. It really sucks for candidates, but given that it essentially costs companies nothing to have this policy, I'm not surprised they do; no company is going to make a choice that has even a small risk of a huge negative downside if there are no direct obvious upsides to counter it.

justin_oaks 5y ago

It's rare to get an employer to give any honest reason for a rejection. As others have pointed out, it may be for fear of getting sued, but that is only part of the general reason: Further interaction with the job candidate almost certainly has a negative ROI (return on investment) for the employer. If you tell the job candidate the honest reasons for rejection then at best you've used (wasted?) some time to tell the candidate this. At worst, the candidate sues. But there are many other possibilities: The job candidate gets angry at you for telling them a hard-to-swallow truth and causes a scene. The candidate tries to argue or negotiate with you. The candidate accepts the truth and tries to use more of your time to discuss your original criticism and seek further advice. None of these scenarios are a net positive for the employer.