5 ms·

No one knows why they actually failed her on the interview. Have run many interviews, and it is very rarely the case that you fail a candidate for one technical

No one knows why they actually failed her on the interview. Have run many interviews, and it is very rarely the case that you fail a candidate for one technical slip up.

ellyagg 5y ago
And I retrained on smaller numbers and got that job at that start-up. Folks are probably much more likely to tell you why you didn't make it the first time you applied...
ragnese 5y ago
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.
- 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.
fragmede 5y ago
Exactly. We don't know anything the author didn't tell us. For all we know, the author adamantly gave the wrong time complexity for quicksort. Or also possibly they were (intentionally or unintentionally) rude and condescending. Or there was a way candidate with a way better fit than our plucky author. Or, or, or.... Thankfully the author left the name of the company off. I'd hate for half of a secondhand account like this to cause candidates to avoid interviewing at a company!
tombert 5y ago
I want to agree with you, but having been part of the pair-interviewing process at one of the FAANG companies, it did seem like candidates would be declined for the most arbitrary technical screw-ups. One time a manager (at least nominally) voted "No" on a candidate specifically because, despite figuring out the solution to the problem, had a compilation error in their Java code and ran out of time to fix it. I remember saying to the manager that that seems like a pretty silly reason to decline someone, compilation errors are typically pretty easy to fix, but I was relatively new to the job so I didn't want to rock the boat too much. He claimed that they only want "the best" and I guess that implied that the best don't have compilation errors.
- ljm 5y ago
  If it wasn't a compilation error it would have been something else to cover up an unconscious bias or a 'gut feeling'. Basically seeking out the evidence, no matter how weak it is, to fit the 'crime'. I wouldn't believe anyone who said they've never been there. For all the times you're told to trust your gut, there are plenty more times where your gut is just plain wrong and you have to go against it.
  - wpietri 5y ago
    For sure. It seems akin to throwing out half the resumes at random because you only want to hire lucky people. Personally, when I'm interviewing I help people get past dumb mistakes. We all make them, and some of the best developers I have worked with are the type to get nervous in interviews, so they become more likely to make them and have a hard time finding them. The "best" interviewee is not always the best developer.
- deleted 5y ago
  [deleted]
jreese 5y ago
About ten years ago, I applied for a SWE role at Facebook. During the interview, the only question that I didn't feel confident was when they asked me how group-by works in SQL and to write a group by query. I said I didn't know and usually looked it up, but they didn't want me to look it up. They rejected me, and the recruiter literally told me it was due to a lack of familiarity with SQL (something I'd been using with PHP for 6+ years at that point). Edit: I interviewed a year later, wasn't asked about SQL at all, absolutely fumbled my way through some networking questions, and was still hired, so it's clearly very dependent on who's interviewing you and what they ask.

No one knows why they actually failed her on the interview. Have run many interviews, and it is very rarely the case that you fail a candidate for one technical slip up.

ellyagg 5y ago

And I retrained on smaller numbers and got that job at that start-up. Folks are probably much more likely to tell you why you didn't make it the first time you applied...

ragnese 5y ago

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.
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.

fragmede 5y ago

Exactly. We don't know anything the author didn't tell us. For all we know, the author adamantly gave the wrong time complexity for quicksort. Or also possibly they were (intentionally or unintentionally) rude and condescending. Or there was a way candidate with a way better fit than our plucky author. Or, or, or.... Thankfully the author left the name of the company off. I'd hate for half of a secondhand account like this to cause candidates to avoid interviewing at a company!

tombert 5y ago

I want to agree with you, but having been part of the pair-interviewing process at one of the FAANG companies, it did seem like candidates would be declined for the most arbitrary technical screw-ups. One time a manager (at least nominally) voted "No" on a candidate specifically because, despite figuring out the solution to the problem, had a compilation error in their Java code and ran out of time to fix it. I remember saying to the manager that that seems like a pretty silly reason to decline someone, compilation errors are typically pretty easy to fix, but I was relatively new to the job so I didn't want to rock the boat too much. He claimed that they only want "the best" and I guess that implied that the best don't have compilation errors.

ljm 5y ago
If it wasn't a compilation error it would have been something else to cover up an unconscious bias or a 'gut feeling'. Basically seeking out the evidence, no matter how weak it is, to fit the 'crime'. I wouldn't believe anyone who said they've never been there. For all the times you're told to trust your gut, there are plenty more times where your gut is just plain wrong and you have to go against it.
- wpietri 5y ago
  For sure. It seems akin to throwing out half the resumes at random because you only want to hire lucky people. Personally, when I'm interviewing I help people get past dumb mistakes. We all make them, and some of the best developers I have worked with are the type to get nervous in interviews, so they become more likely to make them and have a hard time finding them. The "best" interviewee is not always the best developer.
deleted 5y ago
[deleted]

jreese 5y ago

About ten years ago, I applied for a SWE role at Facebook. During the interview, the only question that I didn't feel confident was when they asked me how group-by works in SQL and to write a group by query. I said I didn't know and usually looked it up, but they didn't want me to look it up. They rejected me, and the recruiter literally told me it was due to a lack of familiarity with SQL (something I'd been using with PHP for 6+ years at that point). Edit: I interviewed a year later, wasn't asked about SQL at all, absolutely fumbled my way through some networking questions, and was still hired, so it's clearly very dependent on who's interviewing you and what they ask.