As someone who does these types of interviews on both ends, something like this is why I like to start with an outrageously simple question to break the ice.
Surprisingly, I have an 80% fail rate on the first question usually, which is just “find the second largest number in an array of numbers” for a 5 YOE role.
I just saw that this comment was fading from downvotes.
I think HN is just overwhelmed with people who somehow got hired into technical jobs but can't do them. Anyone who thinks that 'finding second largest number in an array' or 'finding if a string is a substring of another string' are hard, or that the pressures of an interview are a valid excuse for being unable to do it are simply not intelligent enough to be successful in this field and they are casting about for some excuse to protect their ego. These are problems that a bright 12 year old with no programming experience could do for fun, and these folks are purporting to be educated, experienced, professional programmers.
As much as people like to say 'muh anxiety', I've yet to meet someone who can't do very basic coding in an interview but also they are capable of basic coding in any other context. I would suggest that this sort of person is so rare that you will probably never meet one over the course of a normal career.
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.
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.
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
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.
That's fine. Lets say 5% of the time a world class programmer would get this wrong, but 100% of people who can't program get this wrong.
Lets say we interview 100 (N) people for a role. (100 is a lot but pick a number yourself and follow along)
The probability that a random interviewee is a top programmer is lets say 1/50 (T). So in our pool of 100 we have on average 2. Give everyone this problem, and if they get it right they move to round 2 which is 4 more interviews. Lets say 20 (P) people pass to round #2.
We are paying for a total of 100 + 80 = 180 interviews (N + 4P). To give everyone who failed the first round another try would require another 80 (N - P) interviews. So for almost 50% more cost (N-P)/(N + 4P) we gain (T * N * 5%) = 0.1 additional top programmer making it to round 2 on average. Just interviewing another 80 people (same cost) would get us (T * 80 * 95%) == 1.52 additional top programmers to round #2 on average. There's basically no reasonable % you can pick for how often people screw up where it makes sense to do anything but just ignore the possibility.
Sure, but now you're making a different claim from the one you made before.
Before, you were saying: anyone who says "muh anxiety" is just trying to cover for the fact that they're incompetent.
I suggested that we've got pretty good evidence that interview stress really truly can, and not only-vanishingly-occasionally, make competent people fail to do simple interview-type coding tasks.
So now you're advancing a different claim: even if some competent people appear incompetent in some interviews because of the stress of interviewing, you should make interview decisions as if those people are just plain incompetent, because most people who fail to do simple interview-type coding tasks really are incompetent and identifying the few who were just stressed out is difficult.
That could very well be true! But it's not what I was arguing against before.
... But I'll argue against it just a bit, even though I mean it when I say it could well be true.
1. There may be much less inefficient ways of catching the competent-but-stressed candidates than "just interview everyone twice"; completely incompetent people probably don't interview exactly the same as competent-but-stressed ones. (I don't know for sure because, of course, when you interview someone and they don't perform well you don't generally get to tell which category they were in. But I bet it would be possible to find out.)
2. If the situation is that some people are particularly susceptible to interview stress (but that this doesn't make them bad at actual programming jobs unless they're in an extra-stressful environment), the "eh, just reject them" strategy might be good for companies that are hiring but punishingly bad for the people affected who just can't get a job because they are bad at interviews. If there were a good way to identify people who are good but fall apart readily under interview-stress, that might be a big deal for those people. (Which someone on the hiring side might not care about, of course; but it's sad when some group of people gets systematically screwed over.)
I repeat, as I have said before, that I don't have a solution to this problem nor even good reason to believe that there is one. I'm just pushing back against the blithe assertion that there isn't a real problem here.
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.
> 'finding if a string is a substring of another string'
Unless you mean using a "substring" function or regexes... coming up with the naïve O(n^2) algorithm is indeed easy, but finding a fast algorithm like KMP is, I would say, non-trivial?
For the "second-largest number in array" it's rather easy to come up with an O(n) algorithm, so I would consider the two cases to be different.
Surprisingly, I have an 80% fail rate on the first question usually, which is just “find the second largest number in an array of numbers” for a 5 YOE role.