4 ms·

I actually like asking math questions on interviews. It shows how people approach a problem. Asking code questions in an arbitrary interview setting shows just

I actually like asking math questions on interviews. It shows how people approach a problem. Asking code questions in an arbitrary interview setting shows just about nothing - no access to a reference doc, somebody peering over your shoulder. Heck, I couldn't code my way out of a wet paperback in that setting. Certainly, asking only math questions is stupid as well, people should know at least a little about the stuff they're supposed to work with, but teaching an actual language to a smart person eager to learn is a breeze compared to teaching problem solving to someone who memorized the reference manual.

kenster07 13y ago
"...a smart person eager to learn is a breeze compared to teaching problem solving to someone who memorized the reference manual." I would guess that there is actually significant overlap between these two groups.
- morgante 13y ago
  > I would guess that there is actually significant overlap between these two groups. I wouldn't. Smart people get bored sitting around memorizing things. They'd rather be thinking. Purely anecdotally, the smartest people I know rarely have encyclopedic knowledge of anything.
  - pdonis 13y ago
    But thinking has the side effect of storing lots of stuff in your memory. So you can end up with encyclopedic knowledge of subjects that you've spent a lot of time thinking about. It just isn't knowledge that got stored by explicitly trying to "memorize" things (which means it's more reliable anyway, since it's knowledge that's connected to other things you know).
    - Xylakant 13y ago
      I store a lot of "I've read the solution for that problem somewhere while researching something else." I still can't recite the stdlib doc for any of the programming languages I work with. There's only so much stuff I can cram in my head and reference docs are fairly easy to look up.
      - pdonis 13y ago
        I store a lot of "I've read the solution for that problem somewhere while researching something else." Yes, this is more what I was thinking of as "encyclopedic knowledge" (which may not be what the parent post to mine meant by the term).
        Xylakant 13y ago
        "encyclopedic knowledge" is usually meant to be "I can recite the cities phonebook by heart"
        pdonis 13y ago
        Not necessarily; an encyclopedia isn't just an unconnected catalogue of facts--at least, it's not supposed to be. An encyclopedia article about a given subject is supposed to show the subject as a connected whole; it will contain facts, but will also contain important relationships between the facts, general principles, theories that explain the facts, etc. If you have that kind of knowledge of a subject, you don't have to memorize all its facts, because you can easily get to them from the facts you do have memorized via one of many interconnections.
- Pitarou 13y ago
  Not really. Memorising the manual is the strategy of a surface learner. Surface learners can make pretty good PHP programmers, but they'll struggle with, say, passing Javascript closures. A deep learner will look for the underlying principles and abstractions. They can quickly get an overview that, even when it's fuzzy, is still accurate enough for them to know where the gaps in their knowledge are, so they can fill those gaps quickly when they need to. They're like Mendeleev with his first periodic table. He didn't need somebody to show him a sample of gallium to know that it existed: he could inferred its presence and properties from the overall structure of the system. Of course, a really advanced programmer will have done both. They will know and understand everything. But those guys are few and far between.
  - kenster07 13y ago
    What I mean is that people who enjoy programming probably tend to be smart. I haven't done any statistical surveys, but the motivational feedback loop for learning programming rewards intelligence.
    - Xylakant 13y ago
      I doubt that. There's a lot of people going into programming because they think a) IT is akin to playing computer games all day. b) It's easy work in a climatized office with solid pay c) The jobs are relatively secure and abundant. I've seen many people go into IT that would much better have been employed elsewhere, so I think that we, as programmers are not more intelligent on average than the rest of the population. I might agree that people who enjoy programming have a knack for a certain type of intelligence and problem solving ability, but I don't think that programmers are limited to the group of people that enjoy programming.
      - kenster07 13y ago
        You have a point. Sometimes, I forget that there are actually people out there who pursue careers where they know they won't enjoy the journey.
      - 13y ago
auggierose 13y ago
I think you don't get the point. Learning a new language after you programmed for 5 years in a variety of paradigms like assembler, object-oriented, purely functional, will take you between a couple of hours and a week. But if you have NOT had those 5 years of varied programming experience, then the new language is not your problem. Learning the concepts is, and that will take time.
- Xylakant 13y ago
  I think you don't get my point: I expect a domain expert to be a domain expert, but I don't expect a trainee to know anything and I'll structure my interview accordingly. I'll ask the domain expert questions about his domain. But I don't expect a domain expert to know the programming language that we work with just because he's a domain expert. And seriously, I'll prefer the eager-to-learn math graduate with little coding experience over the bored cs graduate that knows the java reference doc by heart and now thinks he knows how to build stuff. In any case coding examples in your interview will show you little beyond the fact that somebody memorized the docs. The actual pain point I read from the article is a different one: There's a mismatch between hiring process and expectations. If I need a lead programmer for the iOS project that I'm about to start next week then I can't hire anyone that doesn't know Objective C and then I absolutely need to structure my interview accordingly. But if I have a couple of weeks more I'll happily teach him. And if I'm hiring somewhat smart I try to avoid those "we need someone urgently" situations.
  - auggierose 13y ago
    I also think that there might be a mismatch between hiring process and expectations. When you say "But if I have a couple of weeks more" then you obviously underestimate the time it takes to learn if we are actually talking about somebody without much programming experience. Try "if I have a couple of years more".
    - Xylakant 13y ago
      See, there's so much more that you need to learn when you start on a project in a company. There's the framework they use, their libraries, the requirements for the project, the problem domain, the people you work with, the process they use, ... just to list the few that come to the top my head. Especially learning the problem domain can be very hard and challenging to programmers with little or no knowledge of the field. It can easily take a couple of month, if not years to become reasonably proficient. So yes, "a couple of weeks" is certainly not enough to transform a graduate into a project lead for bespoke iOS project, but it could easily be enough to transform a decent java programmer with solid project lead experience. Transforming a crack Objective C Programmer with no lead experience can take easily as much time, if not more. My gist is that programming knowledge will only get you so far and depending on what position you're hiring for other experience combined with the ability and willingness to learn may be much more interesting. And whatever I do, I tend to hire for that trait since that allows people to pick up other abilities when required.
uniclaude 13y ago
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.
- baddox 13y ago
  Everything might exclude some good candidates, right? With the possible exception of a lengthy internship or "trial period."
  - mynameisvlad 13y ago
    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.
  - giergirey 13y ago
    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 ...
RogerL 13y ago
Did you read the OP? The point of the article was that one can be great at that sort of thing and yet quite terrible as a production programmer. You are not measuring the skill you want with math problems, you are measuring a proxy. Furthermore, I've known plenty of smart math people that just never seemed to be able to program (well). I think they are different skill sets, certainly with plenty of overlap, but plenty of differences as well, and those differences matter. I laughed out loud at the "variables, variables everywhere!" answer in the OP - I've had to deal with so much code written that way. Some people, very smart people, just don't 'get' design in that way. I worked with a guy that used to run around the office, asking brain teasers, sharing tidbits of knowledge, but he couldn't execute a basic project - couldn't plan what to do, couldn't do things in a rational order, couldn't experiment and gather data, couldn't incrementally design, develop, refactor, nor do a big-bang waterfall kind of design, and so on. He was not sorely missed when let go. Smart as a whip, and useless (for programming). I've worked at several companies with staff mathematicians. Sooner or later they got their hands on a compiler. Oh my. No, let me do that. You tell me what is wrong with my Kalman filter, but I'll take care of the implementation, thank you. Its easy to kvetch at somebody else's answer without offering an alternative (I do agree whiteboard progamming is disastrous). So, instead of asking math, why not ask them to write a simple routine, but then start asking real world problems about the code they would face - how would you make this API interface robust? What kind of documentation would you write. How would you handle errors? Is this code exception safe? Thread safe? How would you make it either/both of those. Suppose your problem size was n=100MM, how might you need to change this (say they have a data structure that loaded everything into memory)? Ask them some problems they will see in production - what is the network delay, or whatever your problem case is. You still get to see how they approach problems, but in the context of the actual decisions they will be making while programming for you. Anyway, that is what I try to do. I am revising my thoughts even on that, because I find people flopping on the 'code the simple problem (and, it is simple)' yet doing great on all the engineering questions, and doing fine if we hire them.
- Xylakant 13y ago
  > Did you read the OP? Did you read my post? May I quote myself: > Certainly, asking only math questions is stupid as well So what I actually advocate is asking questions about the field that the person is going to work in. I still like to ask some math questions - a lot of the stuff that programs deal with basically fall back to math. Heck, all relational database stuff falls back to set theory, so knowledge in that area certainly helps a lot. I'm not advocating employing pure theoretical mathematicians to develop contact forms in php. However, from my experience the following two statements hold true: * Studying CS does just about nothing good to your actual programming skills and your knowledge of real-world problems. So just don't expect recent graduates to be able to develop a program in a rational order, using a reasonable process, refactor or any of the skills you're asking for just by virtue of having "programmed". If you're looking for an experienced programmer hire for an experienced programmer, but the OPs tale clearly shows that she was no experienced programmer - why would I quiz her in the way I'd quiz a 10-years-learned ruby programmer? * If you have time to teach and educate a programmer, prefer a smart and eager type over someone who spools down memorized knowledge. While memorized knowledge can sometimes help, the ability to learn and educate yourself is much more helpful once your memorized stuff is not saving you.
driverdan 13y ago
What kind of math questions do you ask? Are then relevant to the job? Is it knowledge that the employee will need to have for their day-to-day tasks? Asking math questions that are unrelated to the employee's tasks has strong bias for recent graduates. Ask a 40 year old a question about an equation they haven't used since they were 19 and they won't remember. I was once asked to do binary math on a phone interview. I hadn't had to do binary math since I was in school 10 years prior. I was pretty much guaranteed to fail. This was not a good test. If I needed it I could easily relearn binary math in a few hours at most.

kenster07 13y ago

"...a smart person eager to learn is a breeze compared to teaching problem solving to someone who memorized the reference manual." I would guess that there is actually significant overlap between these two groups.

morgante 13y ago
> I would guess that there is actually significant overlap between these two groups. I wouldn't. Smart people get bored sitting around memorizing things. They'd rather be thinking. Purely anecdotally, the smartest people I know rarely have encyclopedic knowledge of anything.
- pdonis 13y ago
  But thinking has the side effect of storing lots of stuff in your memory. So you can end up with encyclopedic knowledge of subjects that you've spent a lot of time thinking about. It just isn't knowledge that got stored by explicitly trying to "memorize" things (which means it's more reliable anyway, since it's knowledge that's connected to other things you know).
  - Xylakant 13y ago
    I store a lot of "I've read the solution for that problem somewhere while researching something else." I still can't recite the stdlib doc for any of the programming languages I work with. There's only so much stuff I can cram in my head and reference docs are fairly easy to look up.
    - pdonis 13y ago
      I store a lot of "I've read the solution for that problem somewhere while researching something else." Yes, this is more what I was thinking of as "encyclopedic knowledge" (which may not be what the parent post to mine meant by the term).
      - Xylakant 13y ago
        "encyclopedic knowledge" is usually meant to be "I can recite the cities phonebook by heart"
        pdonis 13y ago
        Not necessarily; an encyclopedia isn't just an unconnected catalogue of facts--at least, it's not supposed to be. An encyclopedia article about a given subject is supposed to show the subject as a connected whole; it will contain facts, but will also contain important relationships between the facts, general principles, theories that explain the facts, etc. If you have that kind of knowledge of a subject, you don't have to memorize all its facts, because you can easily get to them from the facts you do have memorized via one of many interconnections.
Pitarou 13y ago
Not really. Memorising the manual is the strategy of a surface learner. Surface learners can make pretty good PHP programmers, but they'll struggle with, say, passing Javascript closures. A deep learner will look for the underlying principles and abstractions. They can quickly get an overview that, even when it's fuzzy, is still accurate enough for them to know where the gaps in their knowledge are, so they can fill those gaps quickly when they need to. They're like Mendeleev with his first periodic table. He didn't need somebody to show him a sample of gallium to know that it existed: he could inferred its presence and properties from the overall structure of the system. Of course, a really advanced programmer will have done both. They will know and understand everything. But those guys are few and far between.
- kenster07 13y ago
  What I mean is that people who enjoy programming probably tend to be smart. I haven't done any statistical surveys, but the motivational feedback loop for learning programming rewards intelligence.
  - Xylakant 13y ago
    I doubt that. There's a lot of people going into programming because they think a) IT is akin to playing computer games all day. b) It's easy work in a climatized office with solid pay c) The jobs are relatively secure and abundant. I've seen many people go into IT that would much better have been employed elsewhere, so I think that we, as programmers are not more intelligent on average than the rest of the population. I might agree that people who enjoy programming have a knack for a certain type of intelligence and problem solving ability, but I don't think that programmers are limited to the group of people that enjoy programming.
    - kenster07 13y ago
      You have a point. Sometimes, I forget that there are actually people out there who pursue careers where they know they won't enjoy the journey.
    - 13y ago

auggierose 13y ago

I think you don't get the point. Learning a new language after you programmed for 5 years in a variety of paradigms like assembler, object-oriented, purely functional, will take you between a couple of hours and a week. But if you have NOT had those 5 years of varied programming experience, then the new language is not your problem. Learning the concepts is, and that will take time.

Xylakant 13y ago
I think you don't get my point: I expect a domain expert to be a domain expert, but I don't expect a trainee to know anything and I'll structure my interview accordingly. I'll ask the domain expert questions about his domain. But I don't expect a domain expert to know the programming language that we work with just because he's a domain expert. And seriously, I'll prefer the eager-to-learn math graduate with little coding experience over the bored cs graduate that knows the java reference doc by heart and now thinks he knows how to build stuff. In any case coding examples in your interview will show you little beyond the fact that somebody memorized the docs. The actual pain point I read from the article is a different one: There's a mismatch between hiring process and expectations. If I need a lead programmer for the iOS project that I'm about to start next week then I can't hire anyone that doesn't know Objective C and then I absolutely need to structure my interview accordingly. But if I have a couple of weeks more I'll happily teach him. And if I'm hiring somewhat smart I try to avoid those "we need someone urgently" situations.
- auggierose 13y ago
  I also think that there might be a mismatch between hiring process and expectations. When you say "But if I have a couple of weeks more" then you obviously underestimate the time it takes to learn if we are actually talking about somebody without much programming experience. Try "if I have a couple of years more".
  - Xylakant 13y ago
    See, there's so much more that you need to learn when you start on a project in a company. There's the framework they use, their libraries, the requirements for the project, the problem domain, the people you work with, the process they use, ... just to list the few that come to the top my head. Especially learning the problem domain can be very hard and challenging to programmers with little or no knowledge of the field. It can easily take a couple of month, if not years to become reasonably proficient. So yes, "a couple of weeks" is certainly not enough to transform a graduate into a project lead for bespoke iOS project, but it could easily be enough to transform a decent java programmer with solid project lead experience. Transforming a crack Objective C Programmer with no lead experience can take easily as much time, if not more. My gist is that programming knowledge will only get you so far and depending on what position you're hiring for other experience combined with the ability and willingness to learn may be much more interesting. And whatever I do, I tend to hire for that trait since that allows people to pick up other abilities when required.

uniclaude 13y ago

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.

baddox 13y ago
Everything might exclude some good candidates, right? With the possible exception of a lengthy internship or "trial period."
- mynameisvlad 13y ago
  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.
- giergirey 13y ago
  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 ...

RogerL 13y ago

Did you read the OP? The point of the article was that one can be great at that sort of thing and yet quite terrible as a production programmer. You are not measuring the skill you want with math problems, you are measuring a proxy. Furthermore, I've known plenty of smart math people that just never seemed to be able to program (well). I think they are different skill sets, certainly with plenty of overlap, but plenty of differences as well, and those differences matter. I laughed out loud at the "variables, variables everywhere!" answer in the OP - I've had to deal with so much code written that way. Some people, very smart people, just don't 'get' design in that way. I worked with a guy that used to run around the office, asking brain teasers, sharing tidbits of knowledge, but he couldn't execute a basic project - couldn't plan what to do, couldn't do things in a rational order, couldn't experiment and gather data, couldn't incrementally design, develop, refactor, nor do a big-bang waterfall kind of design, and so on. He was not sorely missed when let go. Smart as a whip, and useless (for programming). I've worked at several companies with staff mathematicians. Sooner or later they got their hands on a compiler. Oh my. No, let me do that. You tell me what is wrong with my Kalman filter, but I'll take care of the implementation, thank you. Its easy to kvetch at somebody else's answer without offering an alternative (I do agree whiteboard progamming is disastrous). So, instead of asking math, why not ask them to write a simple routine, but then start asking real world problems about the code they would face - how would you make this API interface robust? What kind of documentation would you write. How would you handle errors? Is this code exception safe? Thread safe? How would you make it either/both of those. Suppose your problem size was n=100MM, how might you need to change this (say they have a data structure that loaded everything into memory)? Ask them some problems they will see in production - what is the network delay, or whatever your problem case is. You still get to see how they approach problems, but in the context of the actual decisions they will be making while programming for you. Anyway, that is what I try to do. I am revising my thoughts even on that, because I find people flopping on the 'code the simple problem (and, it is simple)' yet doing great on all the engineering questions, and doing fine if we hire them.

Xylakant 13y ago
> Did you read the OP? Did you read my post? May I quote myself: > Certainly, asking only math questions is stupid as well So what I actually advocate is asking questions about the field that the person is going to work in. I still like to ask some math questions - a lot of the stuff that programs deal with basically fall back to math. Heck, all relational database stuff falls back to set theory, so knowledge in that area certainly helps a lot. I'm not advocating employing pure theoretical mathematicians to develop contact forms in php. However, from my experience the following two statements hold true: * Studying CS does just about nothing good to your actual programming skills and your knowledge of real-world problems. So just don't expect recent graduates to be able to develop a program in a rational order, using a reasonable process, refactor or any of the skills you're asking for just by virtue of having "programmed". If you're looking for an experienced programmer hire for an experienced programmer, but the OPs tale clearly shows that she was no experienced programmer - why would I quiz her in the way I'd quiz a 10-years-learned ruby programmer? * If you have time to teach and educate a programmer, prefer a smart and eager type over someone who spools down memorized knowledge. While memorized knowledge can sometimes help, the ability to learn and educate yourself is much more helpful once your memorized stuff is not saving you.

driverdan 13y ago

What kind of math questions do you ask? Are then relevant to the job? Is it knowledge that the employee will need to have for their day-to-day tasks? Asking math questions that are unrelated to the employee's tasks has strong bias for recent graduates. Ask a 40 year old a question about an equation they haven't used since they were 19 and they won't remember. I was once asked to do binary math on a phone interview. I hadn't had to do binary math since I was in school 10 years prior. I was pretty much guaranteed to fail. This was not a good test. If I needed it I could easily relearn binary math in a few hours at most.