3 ms·

Elsewhere in this thread there is literally an example of someone who, by their own description, worked at a FAANG company for some years getting good performan

by gjm11 2y ago

Elsewhere in this thread there is literally an example of someone who, by their own description, worked at a FAANG company for some years getting good performance reviews, has enough interview experience that even if they couldn't generally code their way out of a paper bag they were surely good at interview-question coding, ... and, under pressure from a pushy interviewer, completely failed to do a straightforward coding task. I guess they could just by lying "to protect their ego" but in that case why post their comment at all? It really is the case that some people sometimes completely go to pieces when stressed, and mocking them by saying "muh anxiety" doesn't stop that being true.

bobthepanda 2y ago
I will say that, as the interviewer asking the question, I do recognize that people have anxiety, and I would prefer to nudge them out of a spiral, because a bad interview is generally not pleasant for anybody involved. To some degree the interview is not about getting the question right but also how you respond to questions about your answers. I would rather have someone who started with a totally incorrect answer and then reason back and forth with them til they got on the right path, than someone who came up with the right answer and then clammed up and refused to explain how they got there. (I once had a candidate tell me, verbatim, "I don't think analyzing performance of an algorithm is part of an engineer's job.") I would prefer if there were a more humane, less stressful, and scalable way to do an interview. The problem is that as a profession we lack the continued examination/licensing of other fields like engineering or medicine, so we don't have a good barometer of skills otherwise. And I often have to sift through massive numbers of people clearly overshooting their shot to get a good position.
ltbarcly3 2y ago
The solution to the problem in question is about 9 lines of very simple code. In a 45 minute interview, that is 5 minutes per line available. It's about 1 character every 40 seconds. I think anyone can get flustered and mess up. It's possible for someone, on a bad day, lack of sleep, hung over, experiencing an anxiety attack to mess this up, but it's really really a stretch. This is a VERY EASY task, and if someone has done it before there's nothing sneaky or hard to do here. The version where you match different kinds of braces is very slightly more complicated but actually less lines of code. Yes maybe someone can't come up with this in an interview. My point is 99.99% of the time when someone fails this they are lying about their work history or they are so stupid they can't hope to do the job. 00.01% of the time they could do this easily and the stars aligned to give them a rare bad day. The best way to deal with that is to just assume everyone who fails this can't do the work, and the 00.01% person just interviews somewhere else and doesn't have another bad day. I don't even know what the alternative to that is, just hire everyone who claims to be qualified and hope for the best? Give everyone who demonstrates very very strong incompetence signals 2 or 3 more tries? def matched(str): count = 0 for c in str: if c == "(": count += 1 elif c == ")": count -= 1 if count < 0: return False return count == 0
- genewitch 2y ago
  ((What happens) if you are missing a close paren?
  - genewitch 2y ago
    the formatting was funky when i first looked at this, i can see it's returning a boolean now, that covers the case of count > 0
  - bobthepanda 2y ago
    As an interviewer, my company allows the person to pick the language of their choice. At that point, you could just write it in psuedocode if it came down to it, and if you actually knew what you were talking about it doesn’t matter all that much. It’s not like I know the in and outs of every single language people have answered the question in. In an era where linters and autocomplete and IDEs have existed for decades it’s silly to fail an interview based on tiny error checks.
- gjm11 2y ago
  I completely agree that this is a very simple problem; I'm not at all arguing that it isn't. What I am arguing is that this doesn't make it super-unlikely that an otherwise competent person screws it up. If it's really a 1-in-10,000 event, isn't it rather surprising that we've got someone right here in this thread to whom it happened? Someone, moreover, not just barely competent but able to do well with a demanding employer, and who has a lot of exposure to this sort of interview question? I think this is good evidence that, in fact, it's not vanishingly unlikely that someone genuinely competent flubs what should be an embarrassingly straightforward coding task in an interview. That doesn't, unfortunately, mean I have a good suggestion for a better way of telling who is and who isn't capable of writing code. Maybe this is the best we can do. If it really is just a matter of "sometimes, at random, people have bad days"[1] then provided it's fairly rare this issue doesn't matter too much. I'm more worried about the possibility that it's more "a smallish fraction of otherwise-good people often have this sort of bad day", because then that smallish fraction of people may be getting completely overlooked, which is bad for them because it may take them ages to get a job and bad for employers because it effectively reduces the pool of good people to hire. [1] In this particular case, the "bad day" seems to have included an obnoxious interviewer, which it's reasonable to hope wouldn't be repeated at another company's interview. But, again, pointing out a problem unfortunately doesn't guarantee having a good answer. But, equally, not having a good answer doesn't mean the problem isn't real. It would be very nice to believe that all the people failing interviews because they fail to solve an easy coding problem are undeserving incompetents who should be bombing out of the interviews, but it looks to me like that ain't so.

by gjm11 2y ago

bobthepanda 2y ago

I will say that, as the interviewer asking the question, I do recognize that people have anxiety, and I would prefer to nudge them out of a spiral, because a bad interview is generally not pleasant for anybody involved. To some degree the interview is not about getting the question right but also how you respond to questions about your answers. I would rather have someone who started with a totally incorrect answer and then reason back and forth with them til they got on the right path, than someone who came up with the right answer and then clammed up and refused to explain how they got there. (I once had a candidate tell me, verbatim, "I don't think analyzing performance of an algorithm is part of an engineer's job.") I would prefer if there were a more humane, less stressful, and scalable way to do an interview. The problem is that as a profession we lack the continued examination/licensing of other fields like engineering or medicine, so we don't have a good barometer of skills otherwise. And I often have to sift through massive numbers of people clearly overshooting their shot to get a good position.

ltbarcly3 2y ago

The solution to the problem in question is about 9 lines of very simple code. In a 45 minute interview, that is 5 minutes per line available. It's about 1 character every 40 seconds. I think anyone can get flustered and mess up. It's possible for someone, on a bad day, lack of sleep, hung over, experiencing an anxiety attack to mess this up, but it's really really a stretch. This is a VERY EASY task, and if someone has done it before there's nothing sneaky or hard to do here. The version where you match different kinds of braces is very slightly more complicated but actually less lines of code. Yes maybe someone can't come up with this in an interview. My point is 99.99% of the time when someone fails this they are lying about their work history or they are so stupid they can't hope to do the job. 00.01% of the time they could do this easily and the stars aligned to give them a rare bad day. The best way to deal with that is to just assume everyone who fails this can't do the work, and the 00.01% person just interviews somewhere else and doesn't have another bad day. I don't even know what the alternative to that is, just hire everyone who claims to be qualified and hope for the best? Give everyone who demonstrates very very strong incompetence signals 2 or 3 more tries? def matched(str): count = 0 for c in str: if c == "(": count += 1 elif c == ")": count -= 1 if count < 0: return False return count == 0

genewitch 2y ago
((What happens) if you are missing a close paren?
- genewitch 2y ago
  the formatting was funky when i first looked at this, i can see it's returning a boolean now, that covers the case of count > 0
- bobthepanda 2y ago
  As an interviewer, my company allows the person to pick the language of their choice. At that point, you could just write it in psuedocode if it came down to it, and if you actually knew what you were talking about it doesn’t matter all that much. It’s not like I know the in and outs of every single language people have answered the question in. In an era where linters and autocomplete and IDEs have existed for decades it’s silly to fail an interview based on tiny error checks.
gjm11 2y ago
I completely agree that this is a very simple problem; I'm not at all arguing that it isn't. What I am arguing is that this doesn't make it super-unlikely that an otherwise competent person screws it up. If it's really a 1-in-10,000 event, isn't it rather surprising that we've got someone right here in this thread to whom it happened? Someone, moreover, not just barely competent but able to do well with a demanding employer, and who has a lot of exposure to this sort of interview question? I think this is good evidence that, in fact, it's not vanishingly unlikely that someone genuinely competent flubs what should be an embarrassingly straightforward coding task in an interview. That doesn't, unfortunately, mean I have a good suggestion for a better way of telling who is and who isn't capable of writing code. Maybe this is the best we can do. If it really is just a matter of "sometimes, at random, people have bad days"[1] then provided it's fairly rare this issue doesn't matter too much. I'm more worried about the possibility that it's more "a smallish fraction of otherwise-good people often have this sort of bad day", because then that smallish fraction of people may be getting completely overlooked, which is bad for them because it may take them ages to get a job and bad for employers because it effectively reduces the pool of good people to hire. [1] In this particular case, the "bad day" seems to have included an obnoxious interviewer, which it's reasonable to hope wouldn't be repeated at another company's interview. But, again, pointing out a problem unfortunately doesn't guarantee having a good answer. But, equally, not having a good answer doesn't mean the problem isn't real. It would be very nice to believe that all the people failing interviews because they fail to solve an easy coding problem are undeserving incompetents who should be bombing out of the interviews, but it looks to me like that ain't so.