5 ms·

what's the point of this kinda of interview question?

wyldfire 9y ago
I'm not defending the interview question, but it's a valuable trait if someone can take the evidence of a logic-defying test run and ask themselves "This seems impossible, how could it have come about?" rather than "This is impossible, it must represent a hardware defect." -- or "This is mysterious and impossible but I just perturbed it enough to make the mysterious effect go away." IMO this interview question is not horrible, especially if the answer(s) given are taken as a larger context of evaluating someone. If the candidate the interviewer responded "no, can't evaluate to true", then a good follow up might be "in fact it can! can you think of why/how?"
lucideer 9y ago
I'd normally be extremely critical of pointless tech interview questions, but this one is excellent. It tests both debugging skill (not taking innocuous code for granted) and defensive programming (writing robust code that won't be affected by environment). The obvious example of the latter on Javascript is being aware of how closures and scope work and avoiding global namespacing. If you're even vaguely aware that the kind of trickery in the SO question is a possibility you're much more likely to practice safe coding in that context.
- FLUX-YOU 9y ago
  >but this one is excellent. Not really. You'll give the impression this quality of code is part of production code and send them running for the hills.
  - mark-r 9y ago
    Do you seriously think anybody would confuse this snippet for production code?
    - zaphar 9y ago
      You've obviously never seen the kinds of production code that I have. This example is clearly distilled down but manifestations of the cause can be found in many different languages and I've encountered quite a few of them in my day. That said I wouldn't really consider this a good interview question.
      - protomyth 9y ago
        Check me on this one. What if this is some absurd way to do a series of process steps where the a == 1 checks if you can do step 1 and then executes step 1 with a being set to 1 on success and 0 on failure thus allowing the && to go to the a == 2 comparison which handles step 2. This continues with the rest of the line. Its just psycho enough to be plausible in a truly dysfunctional way.
        zaphar 9y ago
        I have encountered code written by people just psycho enough to think that's a clever way to handle just that scenario. They were not wrong it was indeed clever. It was also terrible.
        protomyth 9y ago
        The sad part is I too can see someone who needs to do batch processes reading about short circuit evaluation and having this "amazing" idea for a framework that would look exactly like that if. Its moments like those that make me wake in a cold sweat.
    - FLUX-YOU 9y ago
      If they want me to assume this kind of code would never be in prod, then they can assume I know how to write code and we can dispense with the technical interview altogether.
    - billconan 9y ago
      IMO, a good interview question should reflect daily work.
  - lucideer 9y ago
    If I were hiring, I'd be looking for a candidate who makes considered, well-researched-and-thought-out judgements, not one who runs for the hills based on speculating that a few characters of a conditional might be representative of a company as a whole.
    - FLUX-YOU 9y ago
      Could you maybe use some considered, well-researched-and-thought-out judgements regarding the kinds of questions you ask so that candidates can get a better feel for the demands and level of quality you put into your code instead of intentionally asking lower-quality questions which give you arguably little insight into how candidates actually code?
      - lucideer 9y ago
        The quality of the question is subjective. My opinion of its quality is well-researched-and-thought out - you're entitled to disagree but that doesn't nullify the fact there's thought behind it. You were making out that a candidate would "run for the hills" based on a wild extrapolation about the company's production code - I was responding to that point, which is quite independent of the quality of the question.
        FLUX-YOU 9y ago
        Technical interviews are two-way assessments. If you're not going to put your best effort by representing the work fairly through the technical interview, it certainly says something about how you view and respect potential candidates' time and maybe it indicates the quality of code you run. I have nothing else to go on unless you have public repos. I personally don't think it's a wild extrapolation based on the code quality compared to interviews I've gotten and I quickly reject companies that don't put forth fair tests. At worst, I'm wrong about the code quality, but I'm still selecting based on bad interview questions, which I'm perfectly fine with and I think more people should do if only to generate some kind of rejection signal to get interviewers to stop asking mundane questions like this. It's not like companies don't also reject candidates for equally small bullshit or extrapolating conclusions about candidates based on the interview anyway.
- billconan 9y ago
  If you provide candidates a live debugger, I'd say this tests debugging skills (which I think is important to test.) I'm not sure what this tests if it was on a white board.
  - lucideer 9y ago
    You're right, and this wouldn't test debugging skills to that extent. But even with a live debugger you need an appropriate problem. In terms of whiteboard/paper questions, the fact this touches on the mindset/approach to debugging makes it far better than a lot of other whiteboard/paper questions I've seen.
- cpburns2009 9y ago
  No, this is a really poor trivia question for JavaScript. The question itself is lacking an important detail: what is the type of a? As presented, I think it would be safe to assume a is a number and thus it cannot possibly true. However, if a can be an arbitrary object, then there apparently is some hacky incantation that can make it true.
  - lucideer 9y ago
    You seem to be thinking of it as a yes/no/definite answer question. Interview questions should elicit discussion and deconstruction of the subject. Through this you can get an impression of how a candidate approaches the question. Your breakdown being a good example of such discussion.
- urda 9y ago
  This is a terrible interview question. It is an unrealistic scenario, should never be in production code, and does not offer any additional information from the candidate. Please never ask this on any interview loop, thanks.
  - UncleMeat 9y ago
    Interview questions are rarely about the code itself, but the discussion about the code. I think this is what people miss when they say "I'll never actually need to do X". Yes, but I want to see how you can take clear requirements and implement them in code. Or I want to see how you'd approach a seemingly impossible behavior happening in production. As a piece of trivia the question isn't great but as a "how does a person debug some totally unexpected behavior that requires somewhat deep knowledge of the language to comprehend" it is a great question.
sillysaurus3 9y ago
There is no point. The point of interviews is to find engineers that can do the work. This question doesn't further that goal. It "works" because we've been trained to laude pointless BS as if it were somehow valuable. The interviewers themselves had to answer some BS questions, therefore they perpetuate it. Candidates don't reject the questions because there's no quicker way to fail an interview than to balk at an unfair question. Ask yourself: Now that you know the answer, are you a better programmer? Truly? If becoming a better programmer were that simple, anyone off the street could do it.
- mark-r 9y ago
  Finding someone who knows the answer isn't nearly as valuable as finding someone who can figure out the answer.
  - mixmastamyk 9y ago
    And figure it out with the clock ticking, a gun to their head, and a hundred thousand dollars in a suitcase. Random outcomes FTW.
kccqzy 9y ago
I find this kind of question quite interesting in a somewhat unfair way. When something highly unexpected is presented, it really makes the candidate think out of the box. I can for example immediately think of several weird cases (overloaded operators/implementation of == or &&, another thread trying to increment it at the same time, strange type coercion rules, running inside a debugger etc) and to me, as an interviewer if I heard of a novel answer, this shows the creativity of the candidate. But again I concede that this is totally unfair. Not everyone can immediately think out of the box at a moment's notice, especially during an interview which can be quite stressful. I certainly wouldn't place a lot of weight on those kind of questions; if the candidate surprised me with a novel answer, that would be the icing on the cake.
- geofft 9y ago
  > Not everyone can immediately think out of the box at a moment's notice, especially during an interview which can be quite stressful. Yup. This is sometimes a skill you want to test for - I have had a job where I would occasionally get paged at 3 AM to diagnose and fix novel problems in parts of infrastructure that I hadn't previously interacted with, for a high-frequency trading company where every minute of downtime had a financial impact. If you're hiring for that sort of thing, asking people if they can figure out stupid problems under time pressure and in a high-stress situation is exactly what you want to select for. If you're hiring someone to sit at their desk, write code, and go home after 8 hours, where "time-sensitive" problems have their response time is measured in days and not minutes and where there's plenty of time to Google for similar situations or try to reproduce the problem in a test environment, responding to weird questions on short notice with someone staring at you until you figure it out is a much less relevant skill. And I think most tech jobs fall in this category. Ideally, give them interview problems where they can go home, get some sleep, drink some tea, and figure out the answer in the morning. I've done a bunch of hero work on O(minute) timeframes, but my actual quality work has always taken days of thinking about the problem quietly.
dustinmoorenet 9y ago
I think it would be more appropriate to ask: This conditional evaluates to `true`, but how? If you first ask, 'Is this possible?', then most of us, who have long forgotten terrible coding standards, would say no, out of hand. I would have thought the interviewer was testing to see if I was an idiot. I find once I resolve myself to knowing that the bug is possible, then I can find and fix it.

I'm not defending the interview question, but it's a valuable trait if someone can take the evidence of a logic-defying test run and ask themselves "This seems impossible, how could it have come about?" rather than "This is impossible, it must represent a hardware defect." -- or "This is mysterious and impossible but I just perturbed it enough to make the mysterious effect go away." IMO this interview question is not horrible, especially if the answer(s) given are taken as a larger context of evaluating someone. If the candidate the interviewer responded "no, can't evaluate to true", then a good follow up might be "in fact it can! can you think of why/how?"

lucideer 9y ago

I'd normally be extremely critical of pointless tech interview questions, but this one is excellent. It tests both debugging skill (not taking innocuous code for granted) and defensive programming (writing robust code that won't be affected by environment). The obvious example of the latter on Javascript is being aware of how closures and scope work and avoiding global namespacing. If you're even vaguely aware that the kind of trickery in the SO question is a possibility you're much more likely to practice safe coding in that context.

FLUX-YOU 9y ago
>but this one is excellent. Not really. You'll give the impression this quality of code is part of production code and send them running for the hills.
- mark-r 9y ago
  Do you seriously think anybody would confuse this snippet for production code?
  - zaphar 9y ago
    You've obviously never seen the kinds of production code that I have. This example is clearly distilled down but manifestations of the cause can be found in many different languages and I've encountered quite a few of them in my day. That said I wouldn't really consider this a good interview question.
    - protomyth 9y ago
      Check me on this one. What if this is some absurd way to do a series of process steps where the a == 1 checks if you can do step 1 and then executes step 1 with a being set to 1 on success and 0 on failure thus allowing the && to go to the a == 2 comparison which handles step 2. This continues with the rest of the line. Its just psycho enough to be plausible in a truly dysfunctional way.
      - zaphar 9y ago
        I have encountered code written by people just psycho enough to think that's a clever way to handle just that scenario. They were not wrong it was indeed clever. It was also terrible.
        protomyth 9y ago
        The sad part is I too can see someone who needs to do batch processes reading about short circuit evaluation and having this "amazing" idea for a framework that would look exactly like that if. Its moments like those that make me wake in a cold sweat.
  - FLUX-YOU 9y ago
    If they want me to assume this kind of code would never be in prod, then they can assume I know how to write code and we can dispense with the technical interview altogether.
  - billconan 9y ago
    IMO, a good interview question should reflect daily work.
- lucideer 9y ago
  If I were hiring, I'd be looking for a candidate who makes considered, well-researched-and-thought-out judgements, not one who runs for the hills based on speculating that a few characters of a conditional might be representative of a company as a whole.
  - FLUX-YOU 9y ago
    Could you maybe use some considered, well-researched-and-thought-out judgements regarding the kinds of questions you ask so that candidates can get a better feel for the demands and level of quality you put into your code instead of intentionally asking lower-quality questions which give you arguably little insight into how candidates actually code?
    - lucideer 9y ago
      The quality of the question is subjective. My opinion of its quality is well-researched-and-thought out - you're entitled to disagree but that doesn't nullify the fact there's thought behind it. You were making out that a candidate would "run for the hills" based on a wild extrapolation about the company's production code - I was responding to that point, which is quite independent of the quality of the question.
      - FLUX-YOU 9y ago
        Technical interviews are two-way assessments. If you're not going to put your best effort by representing the work fairly through the technical interview, it certainly says something about how you view and respect potential candidates' time and maybe it indicates the quality of code you run. I have nothing else to go on unless you have public repos. I personally don't think it's a wild extrapolation based on the code quality compared to interviews I've gotten and I quickly reject companies that don't put forth fair tests. At worst, I'm wrong about the code quality, but I'm still selecting based on bad interview questions, which I'm perfectly fine with and I think more people should do if only to generate some kind of rejection signal to get interviewers to stop asking mundane questions like this. It's not like companies don't also reject candidates for equally small bullshit or extrapolating conclusions about candidates based on the interview anyway.
billconan 9y ago
If you provide candidates a live debugger, I'd say this tests debugging skills (which I think is important to test.) I'm not sure what this tests if it was on a white board.
- lucideer 9y ago
  You're right, and this wouldn't test debugging skills to that extent. But even with a live debugger you need an appropriate problem. In terms of whiteboard/paper questions, the fact this touches on the mindset/approach to debugging makes it far better than a lot of other whiteboard/paper questions I've seen.
cpburns2009 9y ago
No, this is a really poor trivia question for JavaScript. The question itself is lacking an important detail: what is the type of a? As presented, I think it would be safe to assume a is a number and thus it cannot possibly true. However, if a can be an arbitrary object, then there apparently is some hacky incantation that can make it true.
- lucideer 9y ago
  You seem to be thinking of it as a yes/no/definite answer question. Interview questions should elicit discussion and deconstruction of the subject. Through this you can get an impression of how a candidate approaches the question. Your breakdown being a good example of such discussion.
urda 9y ago
This is a terrible interview question. It is an unrealistic scenario, should never be in production code, and does not offer any additional information from the candidate. Please never ask this on any interview loop, thanks.
- UncleMeat 9y ago
  Interview questions are rarely about the code itself, but the discussion about the code. I think this is what people miss when they say "I'll never actually need to do X". Yes, but I want to see how you can take clear requirements and implement them in code. Or I want to see how you'd approach a seemingly impossible behavior happening in production. As a piece of trivia the question isn't great but as a "how does a person debug some totally unexpected behavior that requires somewhat deep knowledge of the language to comprehend" it is a great question.

sillysaurus3 9y ago

There is no point. The point of interviews is to find engineers that can do the work. This question doesn't further that goal. It "works" because we've been trained to laude pointless BS as if it were somehow valuable. The interviewers themselves had to answer some BS questions, therefore they perpetuate it. Candidates don't reject the questions because there's no quicker way to fail an interview than to balk at an unfair question. Ask yourself: Now that you know the answer, are you a better programmer? Truly? If becoming a better programmer were that simple, anyone off the street could do it.

mark-r 9y ago
Finding someone who knows the answer isn't nearly as valuable as finding someone who can figure out the answer.
- mixmastamyk 9y ago
  And figure it out with the clock ticking, a gun to their head, and a hundred thousand dollars in a suitcase. Random outcomes FTW.

kccqzy 9y ago

I find this kind of question quite interesting in a somewhat unfair way. When something highly unexpected is presented, it really makes the candidate think out of the box. I can for example immediately think of several weird cases (overloaded operators/implementation of == or &&, another thread trying to increment it at the same time, strange type coercion rules, running inside a debugger etc) and to me, as an interviewer if I heard of a novel answer, this shows the creativity of the candidate. But again I concede that this is totally unfair. Not everyone can immediately think out of the box at a moment's notice, especially during an interview which can be quite stressful. I certainly wouldn't place a lot of weight on those kind of questions; if the candidate surprised me with a novel answer, that would be the icing on the cake.

geofft 9y ago
> Not everyone can immediately think out of the box at a moment's notice, especially during an interview which can be quite stressful. Yup. This is sometimes a skill you want to test for - I have had a job where I would occasionally get paged at 3 AM to diagnose and fix novel problems in parts of infrastructure that I hadn't previously interacted with, for a high-frequency trading company where every minute of downtime had a financial impact. If you're hiring for that sort of thing, asking people if they can figure out stupid problems under time pressure and in a high-stress situation is exactly what you want to select for. If you're hiring someone to sit at their desk, write code, and go home after 8 hours, where "time-sensitive" problems have their response time is measured in days and not minutes and where there's plenty of time to Google for similar situations or try to reproduce the problem in a test environment, responding to weird questions on short notice with someone staring at you until you figure it out is a much less relevant skill. And I think most tech jobs fall in this category. Ideally, give them interview problems where they can go home, get some sleep, drink some tea, and figure out the answer in the morning. I've done a bunch of hero work on O(minute) timeframes, but my actual quality work has always taken days of thinking about the problem quietly.

dustinmoorenet 9y ago

I think it would be more appropriate to ask: This conditional evaluates to `true`, but how? If you first ask, 'Is this possible?', then most of us, who have long forgotten terrible coding standards, would say no, out of hand. I would have thought the interviewer was testing to see if I was an idiot. I find once I resolve myself to knowing that the bug is possible, then I can find and fix it.