4 ms·

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.

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.

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.