Asking math questions might exclude some good candidates. I know more than a couple very productive programmers that did not go through a formal CS education. Asking math questions to those candidates could even scare them for no reason. I hired people who had no idea about Lagrange Multipliers but were able to ship code in various languages and even learn new paradigms when necessary.
There are not only smart people and persons referencing reference manuals. Being a programmer often means solving bugs in messed-up codebases, build web apps using the technology du jour, or making data go from one place to another, and asking math questions does not help a lot to find people able to do this. This blog post resonates with some people I met.
I have been programming for a while, and went through a CS education, but my experience with hiring made me realize that being good with maths and being a productive programmer are not necessarily two things that always come together.
> Asking math questions might exclude some good candidates.
Every question can exclude a good candidate, especially if you only ask the question and tick the "correct/incorrect answer" box. However, often you can learn the most interesting trait from asking a question which the candidate can't answer right off the bat: How does the candidate deal with failure or lack of knowledge. Does she/he start guessing? Does she/he ask the right questions moving in the general direction of solving the problem?
I'm not checking for academic knowledge in interviews.
> and even learn new paradigms when necessary.
This often requires knowledge about the stuff you don't know. That is a value of formal education: Not the stuff that you memorize, the bigger value I derive from my formal education is all that "I know that there's a solution to the problem but can't remember exactly" kind of knowledge. I can't remember all the sort algorithms I had to code, but I remember there's more than one and that there are tradeoffs between all of them. So if I'm constrained on memory and have a pre-sorted list I can go luck up how bubblesort is implemented exactly. That's a knowledge that self-taught programmers often lack [1].
> being good with maths and being a productive programmer are not necessarily two things that always come together.
No, nobody proclaimed so. But having a trait for problem solving and logical puzzles certainly helps :)
[1] n.b: often. Some of them have read and digested tons of theory books which could count as formal education.
> However, often you can learn the most interesting trait from asking a question which the candidate can't answer right off the bat: How does the candidate deal with failure or lack of knowledge.
Some research suggests that tests are much better at predicting performance than informal grading.
I agree - whenever interview processes come up, commenters mostly criticise the interview processes for excluding good candidates.
But that's only one part of the equation - the number of unsuitable candidates that slip through is normally more important.
Suppose that somehow we magically know that 20% of candidates would be good hires - and the other 80% are unsuitable. But we don't know which are which!
As an interviewer, I'd be very happy with an interview process that discards 50% of the good candidates and 99% of the unsuitable candidates, because that leaves me with 10 good hires and 1 unsuitable hire for every 100 candidates.
On the other hand, if a different interview process discarded 20% of the good candidates and 80% of the unsuitable candidates, that would result in 16 good hires and 16 unsuitable hires - which would be disastrous!
Even from the point of the interviewee, one probably wouldn't want to work somewhere where 50% of your colleagues are not suited to their jobs!
Summary - it's a shame to discard good candidates, but it's worse to let too many unsuitable candidates slip through ...
Hell, even those can exclude a good candidate, especially at larger companies. Candidate not a good fit for the team? Probably won't do as well as one who is.
There are not only smart people and persons referencing reference manuals. Being a programmer often means solving bugs in messed-up codebases, build web apps using the technology du jour, or making data go from one place to another, and asking math questions does not help a lot to find people able to do this. This blog post resonates with some people I met.
I have been programming for a while, and went through a CS education, but my experience with hiring made me realize that being good with maths and being a productive programmer are not necessarily two things that always come together.