When I'm hiring I don't ask math stuff, puzzle stuff, and architectural stuff, to see if you can code. I ask you these things to see if you can do anything other than code. Coding is usually a relatively small part of the job. The ability to grok and manipulate the problem setting is more important, so how you react to puzzles tells me something.
Not being able to do the math, or the puzzles, or whatever, is not a "no hire" - it's a place to start talking about other strengths, abilities, interests, and potential contributions.
During my last round of interviews last fall, places that required knowledge of major math theorems in the interview resulted in rejections 100% of the time. Interviews that either provided a definition of the math required or provided some of the steps to solve the problem resulted in job offers 100% of the time.
Oddly, while I didn't need to be able to reference the language I was using exactly (pseudocode was good enough), they wouldn't help me out with the math knowledge, implying that it was "Algebra I stuff" and that "Everyone knows that."
The interviews (and my job as an Ops guy) in general don't require advanced math knowledge. Places that require memorized knowledge about things during an interview that are not part of the job field pull crappy things. I saw this in at least half of the interviews.
I see a bit of this on the devops world, any employer that does this sort of egotistical dick swagger I drop immediately. There are TONS of good opportunities out there where you don't need to play dumb little games.
And don't get me started on those who use those equally dumb Google questions. "You are shrunk to the height of a nickel and thrown into a blender..." Its not a creative question its basic physics, stop asking things you don't understand or aren't relevant
As someone who recently interviewed for a major internet company, I can report that every interview I took included the requirement for me to write code (real code, with semicolons) on the white board, in front of the interviewers. Every coding problem involved some degree of "maths" problem solving as well. I guess the question is, since 2013, how much has this filtered down into the startup scene. That I cannot report.
I haven't seen any difference. I interviewed late last year for a bunch of positions.
Many of the programming problems required knowledge of major math theorems and proofs. My education didn't include these things (things that aren't normally dependencies of the job) and as a result, I failed those interviews.
Interviews that did not include this dependency resulted in offer letters 100% of the time.
I think puzzles are common at the interviews because hiring based on abilities is a bit looked upon (see for example this advice attributed to John Ousterhout: http://www.quora.com/What-are-the-most-profound-life-lessons...). Thinking goes that if you are going to build next google you obviously need to hire the smartest people and their abilities are irrelevant - they will figure it along the way. There is some truth in it but in practice even the smartest beginning programmer needs extensive coaching in minutiae of the craft and ramp-up projects of the right caliber (that is challenging but allowing sloppy execution and having essentially no deadline). And this coaching is going to take a big chunk of your senior engineers' time. So there is a big trade-off to consider.
I suspect the main value of puzzles at the interview is to determine cultural fit - a guy who just codes will be uncomfortable among the types who enjoy puzzles (discuss them at lunch etc.).
Not being able to do the math, or the puzzles, or whatever, is not a "no hire" - it's a place to start talking about other strengths, abilities, interests, and potential contributions.
But I will also ask you to code.