7 ms·
I don't like these questions at all. My initial reaction to these is: Why do you insist the candidate reads your mind? Some of the questions can be useful if re
by Jach 7y ago
I don't like these questions at all. My initial reaction to these is: Why do you insist the candidate reads your mind? Some of the questions can be useful if rephrased to not require mind-reading the best range of answers.
The purpose of the interview for the interviewer: deciding between "no, don't hire this person", "maybe, we'll decide later with more data or after comparing with another person", and "yes, hire".
The purpose of the interview for the interviewee: deciding "yes/no, I want to continue with this company" and conditionally if yes trying their best to get the interviewer into the "yes, hire" state.
I'm only going to pick on one of these questions, but they all have the same problem in that they're not (to me) very effective means at fulfilling the purpose since they'll select for candidates most capable of reading your mind, not actually really useful candidates. When you ask "what's your take on accessibility on the web?", the candidate is thinking many things at once. Here are some: 1) do I have a take and what is it? 2) what's the answer the interviewer wants to hear? 3) if my answer is wrong does that make it impossible to get into the "no, don't hire" state? 4) will I know once I answer?
Maybe you want a take that says accessibility is important despite the added costs, because humanism or whatever. If they say accessibility isn't important, because the costs don't justify it, you put them in the "no" bucket. Or perhaps it's vice versa, or you analyze the issue through some other framework. Maybe you really just want to see if they can converse about it at all, and will devil's-advocate the opposite of what they say, and only put them in the "no" bucket if they can't converse or start screaming at you.
In any case, I don't think you're being fair to the candidate and you're likely wasting time. If you just want to test ability to converse, and don't actually care what they personally believe, state that in the question and don't ask for their actual belief: "I'd like to have a sort of philosophical discussion with you about accessibility on the web. Let's imagine I ask you ... and you feel ..." If you actually have a specific range of answers in mind that can put someone in the "no" bucket, put that information in the job description requirements. "Expected to design with accessibility in mind." fits the first of my maybes, "Expected to move fast and not spend time on non-MVP work like accessibility." fits the vice-versa. Presto, no mind games, no wasted time for everyone because it wasn't clear until you asked your question that you hold opposite views and thus this is a "no". Maybe you're worried about liars, which you have to be anyway since plenty of people apply to coding positions without being able to code, so you might ask a more specific question (like we do by asking them to code something) around accessibility that makes clear what conclusion you expect (it matches the job description) and that you're looking for some sort of reasoning for why that conclusion is such in their mind.
Maybe since you're mentioning "end up being really useful" (as opposed to just useful) you don't weigh answers to these questions as hard "yes" or "no" filters, but just "maybes" that you can subjectively reflect upon later (e.g. by adding up a bunch of "maybes" you've recast to point-weighted soft yes/nos that can cancel each other). Fine, you can still put "Bonus:" in the job description, rather than "Required:", so that candidates know ahead of time that if they can only get to the "maybe" state the presence/absence of those certain "Bonus" attributes will influence their chances of moving from "maybe" to "yes". If they're already uncertain about "yes", and see a lack of "bonus" attributes on top of that, they're likely to not bother, again saving everyone's time.
It's fine to distinguish between "really useful" and "useful". Questions that can distinguish between degrees of "maybe" between candidates aren't bad, but they should be back-loaded as much as possible, and only used when the front-loaded yes/no questions have been asked and you're still in a state of uncertainty about which candidate would really be better, lamenting that you only have the budget for one of them. How many of those do you get?
- cco 7y agoIf a candidate says accessibility isn't worth the added costs and they're interviewing at Bain Capital, well they're probably a good culture fit and the answer put them in the yes column. If the candidate said that, I don't know, while applying to a prosthetic design company they probably aren't a good culture fit and go in the no column. Why doesn't the question work?
- illnewsthat 7y ago> they're not (to me) very effective means at fulfilling the purpose since they'll select for candidates most capable of reading your mind, not actually really useful candidates This is an important point, and it can be difficult as an interviewer to prevent your own self bias to select candidates that respond how you would personally respond. That being said, I don't think this criticism applies to all the suggested questions. "If you have to solve a problem you haven't solved before, how do you approach it?" seems like a fairly easy one to identify learning methods and response to new problems. Although, a variation of this question was in the original linked article as well (#3).
- Jach 7y agoAs you note it's pretty similar to #3 which is blasted elsewhere in this thread; a sufficient enough argument against it for many companies is that it's of lower value than the technical portion you're forced to give anyway which actually involves the candidate solving a (hopefully novel in some respect) problem. But as quoted, "If you have to solve a problem you haven't solved before, how do you approach it?" -- my beef with this is it requires mind reading to hit the range of good (to the interviewer) answers. Sure they're asking it to "identify learning methods" or whatever, but that's not a criteria, that's the information they hope to gain, which can have a range of values some good and some bad. What values are good, what values are bad? At least with technical problem solving challenges, even if the interviewer uses questionable hidden criteria ("ahh, you didn't put the { on the line I wanted you to!"), there's one very visible criteria no one can disagree on, which is whether the problem was solved or not. If I answer the non-technical version (possibly the same way I might answer the submission's #3, "ok let me tell you about this one problem for which I was initially out of my depth...") but never once mention "ask for help", is that a good sign or a bad sign? I don't know. In some interviewers' eyes, that's an instant-no, for a variety of plausible sounding cultural fit reasons. ("Egotistical", "Not A Team Player", "Hubris.") In others', they might not care if that came up or not. There are lots of alternatives here. If I say or don't say "Google for how others approached it", good or bad? "I start trying to model it with TLA+..." -- maybe good/bad because of formal methods, maybe good/bad because of unknown (to the interviewer) technology, maybe good/bad because immediately attacking the problem? Reasonable people can believe any of those positions, I don't know without mind reading what the interviewer believes and whether if I believe opposite that's going to scuttle my chances and make everyone regret the sunk time so far. "I grab the nearest whiteboard and start drawing/chatting out the unknowns with another engineer or PM", "I try writing some unit tests"... how big of a problem are we talking about anyway? How unfamiliar is it, anyway? Have I solved something similar even if not exactly the same? What category does the problem naturally fall under? ("I think back through my Polya and try to apply it here..") Maybe the question is really just thrown out to see if I'll answer the question with a question? (Might be good or bad.) Maybe the intent is kind but not executed well, and what I say doesn't matter in the slightest with the question only meant to break the ice, get me talking, and hopefully get past any initial nervousness. (Resume questions are better for that though.) #3 in the submission is kind enough to point out that companies usually have a hidden criteria for this question: > The actual problem they describe is unimportant; what matters is how they approached it and how that attitude aligns with your company's values. Some companies stress the importance of teamwork and asking for help, while other companies encourage independent troubleshooting and initiative. Make sure that your candidate can fulfill the job's responsibilities by using the resources available. Ok, as the candidate, how am I supposed to know without reading the interviewer's mind that the actual problem I bring up is unimportant (some companies actually might want to hear about a cool problem and reject you if you haven't solved anything cool enough -- some hiring processes includes giving a whole presentation on some project you did) and how much it will hurt me if my answer doesn't match their view on the relative value of teamwork vs going it alone? The hint is in the final sentence: make explicit the company's preference, whatever it is, in the "Requirements:" or "Responsibilities:" section of the job posting. I'm not against culture fit questions in general -- it's important to like the people you work with and reasonable people can very strongly hold that "team player personality" is a hire/no-hire criteria even if I disagree -- I'm against making the criteria of the fit hidden in the interviewer's mind. If there's sufficient context (this paragraph is also acting as a reply to the sibling comment) like the nature of the company¹ or the requirements/expectations laid out in the job posting or relevant "about our company" materials, then even these questions asked as-is can be ok, because the prepared candidate can easily infer what the expected response should be instead of having to read minds. Somewhat fruitless though, since then you're really only testing candidate preparedness; people who would give you "bad" answers would have already filtered themselves out and not had anyone's time wasted. But I would never ask the questions as-is even with the context of a job posting. Were I to ask similar ones, I'd instead rephrase them in a way that the context is explicit in the question, the real criteria and what I'm hoping to hear about is revealed. This also makes it safe in the common case of disconnect between the interviewers and whoever wrote the job posting. ¹Though I have no idea what Bain Capital is about I would not be hasty concluding one way or another about an employee's feelings on web accessibility. I'll note that their home page loads and renders great in Links.