8 ms·

Things that are more useful to know: - What's your mechanism for bias self-check? - If someone gives you specs and you notice that something is off, what do y

by msum 7y ago

Things that are more useful to know: - What's your mechanism for bias self-check? - If someone gives you specs and you notice that something is off, what do you do? - If you have to solve a problem you haven't solved before, how do you approach it? - What's your take on accessibility on the web? - What's your process like for deciding that you're at the point in your career where you can mentor others? - What do you prefer to do when you see someone else getting nit-picked? - You're just about to finish a feature and have a great idea for improving it. What do you do? For all of these things, people will likely give different answers but those answers will tell me a lot about whether or not they would end up being really useful for the kinds of teams I build.

hnspirit 7y ago
Found the real person!
quanticle 7y ago
I really like the question about specs, and I'll definitely use that in the future when I'm on the interviewer side of the hiring desk. A useful follow up to that would be, "If I gave you a list of features, how would you go about estimating how long it would take to build them all out?" There is no perfect answer to that (as we know from the steady drumbeat of stories decrying the state of software estimation) but hearing how someone would go about solving a problem under conditions of uncertainty would tell give you a lot more useful information, in my opinion, than "What kind of relationship do you want to have with your co-workers?"
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 ago
  If 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 ago
    As 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.
Data_Junkie 7y ago
That is a complete useless waste of time.
tabtab 7y ago
I have an itch to answer these for some unknown reason. - What's your mechanism for bias self-check? Debate. I like debating, I have to admit. It's a great way to sharpen one's logic. But, one has to careful to not get labeled as "argumentative". - If someone gives you specs and you notice that something is off, what do you do? I always have suggestions or questions on any non-trivial spec. I list them up and email them out to the project manager. I do try to be polite in my criticism, though. Example: "I'm concerned that X may confuse users. Here's an alternative to consider." - If you have to solve a problem you haven't solved before, how do you approach it? I try to ponder such longer than normal rather than go with the first approach that pops into my head. I may work on something else while the idea dances around in the back of my head. Sometimes I dream up solutions at night. It sounds cliche, but it's true. - What's your take on accessibility on the web? Managers and users often like fancy UI's that may run into accessibility problems. It's a tricky thing to balance. Eye-candy does "sell" a UI, and accessibility often hampers that. Sometimes I try to find ways to spruce up a UI that don't harm accessibility, such as improving logos or including interesting "side" graphics that don't interfere with the primary function. - What's your process like for deciding that you're at the point in your career where you can mentor others? If I feel I can help somebody without offending them, I will often just jump in and do task-specific mentoring. But I wouldn't want to do such full time. - What do you prefer to do when you see someone else getting nit-picked? I will defend them if their ideas or work have merit. If not, there's probably a reason they create team friction, and to be frank, they probably should change careers into something that's a better fit for them. Often times such people are not "bad", rather just in the wrong field. - You're just about to finish a feature and have a great idea for improving it. What do you do? I'll check with my supervisor. If I'm enthusiastic about the better variation, he or she will typically allow me to go with the better one once they know me. If time is tight, it may have to wait until the next version. I will work extra hours if I feel it's a compelling feature.

by msum 7y ago

hnspirit 7y ago

Found the real person!

quanticle 7y ago

I really like the question about specs, and I'll definitely use that in the future when I'm on the interviewer side of the hiring desk. A useful follow up to that would be, "If I gave you a list of features, how would you go about estimating how long it would take to build them all out?" There is no perfect answer to that (as we know from the steady drumbeat of stories decrying the state of software estimation) but hearing how someone would go about solving a problem under conditions of uncertainty would tell give you a lot more useful information, in my opinion, than "What kind of relationship do you want to have with your co-workers?"

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 ago
If 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 ago
  As 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.

Data_Junkie 7y ago

That is a complete useless waste of time.

tabtab 7y ago

I have an itch to answer these for some unknown reason. - What's your mechanism for bias self-check? Debate. I like debating, I have to admit. It's a great way to sharpen one's logic. But, one has to careful to not get labeled as "argumentative". - If someone gives you specs and you notice that something is off, what do you do? I always have suggestions or questions on any non-trivial spec. I list them up and email them out to the project manager. I do try to be polite in my criticism, though. Example: "I'm concerned that X may confuse users. Here's an alternative to consider." - If you have to solve a problem you haven't solved before, how do you approach it? I try to ponder such longer than normal rather than go with the first approach that pops into my head. I may work on something else while the idea dances around in the back of my head. Sometimes I dream up solutions at night. It sounds cliche, but it's true. - What's your take on accessibility on the web? Managers and users often like fancy UI's that may run into accessibility problems. It's a tricky thing to balance. Eye-candy does "sell" a UI, and accessibility often hampers that. Sometimes I try to find ways to spruce up a UI that don't harm accessibility, such as improving logos or including interesting "side" graphics that don't interfere with the primary function. - What's your process like for deciding that you're at the point in your career where you can mentor others? If I feel I can help somebody without offending them, I will often just jump in and do task-specific mentoring. But I wouldn't want to do such full time. - What do you prefer to do when you see someone else getting nit-picked? I will defend them if their ideas or work have merit. If not, there's probably a reason they create team friction, and to be frank, they probably should change careers into something that's a better fit for them. Often times such people are not "bad", rather just in the wrong field. - You're just about to finish a feature and have a great idea for improving it. What do you do? I'll check with my supervisor. If I'm enthusiastic about the better variation, he or she will typically allow me to go with the better one once they know me. If time is tight, it may have to wait until the next version. I will work extra hours if I feel it's a compelling feature.