Similar concept. You have them do some task like fizzbuzz to see if they can program stuff on the fly that they would never need to do in real life. You practice that since school doesn't prepare you for that unless you do ACM programming contests or something. The interview demands this to see if the candidate is capable of cramming for the interview, which correlates with the effort, ability they could put into the job, not with what the skills they actually apply on the job, which are hard to measure in a one hour interview slot anyways.
If someone doesn't know how to reverse words in a sentence they are absolutely not qualified to be a programmer. Yes they probably won't do this exact task often, but this is like a doctor that can't distinguish heart from the liver. It tells you something has gone horribly wrong.
I agree that some random leetcode-hard problem is not a good indicator, but if you can’t write fizzbuzz or can’t sum an array of integers, you’ve given me important data about your skills as a programmer on that day.
I’ve never had an interview question that asked me to do something straightforward. If I did get a question like that, I would be immediately suspicious about what the catch was.
For campus, we ask very straightforward questions to try to weed out the very lowest of coding fluency at that early stage. (Basically to try to guard against late track changers who haven’t actually coded but know that the SWE market is better than whatever their original interest was.)
If I ask that of a senior candidate, it’s because I got a whiff of “this candidate might not be able to code at all, and I’d like to save us both some time and frustration.”
We ask of every candidate. At least half the time, I wish I'd done so before getting invested in the "experience" portion, when that ends up not actually translating to ability (and believe me, I am trying to help them to succeed)
The beauty is, even a simple exercise answered quickly like "sum of integers" provides ample opportunity to learn a lot about how they think.
Start digging in to testability, requirement changes, etc. Change it to a rolling sum (producing a sequence instead of a single value). Do they use an array or an iterator? Do they output straight to the console, or produce an actual function? Could the numbers come from other sources (database, queue, etc)? What might the tradeoffs be? If there's something they are unfamiliar with, are they quick on the uptake if you explain it? And so on.
I don’t know, I still think 22 year old me might still flub even a simple on the fly question (granting that I do my first internship with IBM writing lots of code when I was 20).
If they flub half of the time and go on seven such interviews, they have over a 99% chance to pass at least one of them.
And that’s for someone with only a 50/50 success rate at summing an array of integers. Do you want to hire someone for a software role who is an underdog to be able to sum an array of ints?
Interviews are learning experiences, you get better at it the more often you do them. My first comment in this thread was that this guy was just a learning experience for these students. Summing integers is easy, understanding someone’s rushed description of what they want done along with rushing to code or write a solution on a whiteboard is the hard part.
