A decently clever candidate could sneak out of that first one without a loop. Something like

    numbers.reduce((a,b) => Math.min(a,b))

would do it in JavaScript. In general, if a candidate realizes they can use reduce for that purpose, in my experience interviewing candidates they probably wouldn't have much trouble doing it with a loop, and it would usually be a signal they're going to have a pretty good interview.

Then again, you might run into a joker who has just memorized how to use reduce for finding the maximum or minimum element in a list of numbers.

I find that's a telling way to determine the experience of the interviewer. I'm saddened by the number of times an interviewer has asked me, "What is a reduce? How does it work?" Of course, that information isn't very helpful in the flow of an interview, it's mostly just upsetting.

As of yet, nobody has used reduce(). If they did, and especially if they followed it with a coherent explanation of what reduce does & how it worked (and convinced me they've not memorized reduce for a singular purpose, but understand it well enough to apply it generally), I'd definitely accept it.

If they can also write, or at least quickly approximate, the for-loop solution too, then I'd say I've gotten an excellent signal: not only can the candidate write a for loop, but he or she might also have some experience with a functional paradigm from somewhere.

Funny, I remember being blown away when somebody asked me this question on my first internship interview. Only later I read about FizzBuzz and became enlightened ;)

The whole for loop thing - absolutely!

We used to ask people to right a function in C that converts an array of doubles from degrees to radians. It was amazing how many people had no idea and who had sailed through CV/resume screening, telephone interview, and 'technical discussion' part of the interview with ease.

If those people really "sailed" through your phone interview and technical discussion there is something very wrong with your phone interview format and technical discussion methods.

That's a good point, and I don't really understand what we were doing wrong.

I guess the candidates could 'talk the talk' when we were asking them questions on their CV, or general high-level questions on, say, threading or design patterns; but when it came to the crunch they couldn't write code.

Maybe the candidates were just good at generating CRUD applications and binding data to forms, and have rarely needed to process data. Not denigrating that aspect of software developement at all - it's just not what we need in our department.

This is a trigonometry question, not a C or programming question.