And where can I find ones that aren't? I want to improve my skill but I don't feel like I should pick up advanced algebra or number theory just to do a coding assignment.
-- "Why do you keep looking for your car keys under the lamp post?"
-- "Because that's where the light is."
Less snarkily: that's because they traits that really matter in a modern development environment -- the ability to deal with ambiguity and complexity; to navigate the tipping points between technical perfection and optimal business value; and and top of all this, a genuine sense of humility and a willingness to work with others whose strengths and weaknesses are different from your own -- are very hard to test for, if they can be "tested" for at all.
But since the current interview "process" is so obsessed with "testing" and stack-ranking... not surprisingly, it's largely rigged around traits that are... easy to "test" for.
Like you know, the ability to crank out rehearsed solutions to algorithm puzzles and the like.
> I want to improve my skill but I don't feel like I should pick up advanced algebra or number theory just to do a coding assignment.
Really? Advanced algebra or number theory? Can you show me a coding assignment that required either? Are you sure you're not just excusing your ignorance by suggesting that stuff you've been asked and didn't know the answer to is somehow advanced when it's really not?
I got asked a project Euler question at an interview for a crud job. I'm sure it's simple if you break it down, but there are plenty of other fish in the sea. If you ask me a question that starts: "let n be ...", I'm out.
An integer partition of a number n is a way of writing n as a sum of positive integers.
Partitions that differ only in the order of their summands are considered the same. A partition of n into distinct parts is a partition of n in which every part occurs at most once.
The partitions of 5 into distinct parts are:
5, 4+1 and 3+2.
Let f(n) be the maximum product of the parts of any such partition of n into distinct parts and let m(n) be the number of elements of any such partition of n with that product.
So f(5)=6 and m(5)=2.
For n=10 the partition with the largest product is 10=2+3+5, which gives f(10)=30 and m(10)=3.
And their product, f(10)·m(10) = 30·3 = 90
It can be verified that
∑f(n)·m(n) for 1 ≤ n ≤ 100 = 1683550844462.
Find ∑f(n)·m(n) for 1 ≤ n ≤ 1014.
Give your answer modulo 982451653, the 50 millionth prime.
Questions like that are asked more to find out how people cope psychologically with ridiculously hard requirements.
It's more like -- how they cope with some one deliberately playing with their head.
Or if they're not deliberately playing - they're at at least acting very, very pretentiously. Believing that they know how to cook up a "test" for real-life problem-solving skills. When in reality they're just parroting some toy problem they read on the internet somewhere. Or that someone that they thought was cool gave them in an interview way back when.
Can they start picking it apart, and at least find some bits of it they can solve, or do they squirm, or whine, or rage quit?
In a completely contrived and artificial context that not only bears very little resemblance to the conditions in which developers actually do need to solve difficult real-life problems - but in many ways is in fact a grotesque distortion of those conditions.
I said, "if that's representative of the day to day work, I'm probably not a great fit for the position," and got up to walk out. They asked me stay and talk about some of my github projects, so we had a nice talk for a few minutes and then I left.
I'd gotten an offer earlier that morning, so I was a little more self-assured than I would have been otherwise.
What's so great about going to uni to learn to solve the same problems in the same way as everyone else? That doesn't seem like a way to achieve anything new or interesting. Also, tons of people graduate without even being able to really code. I'd much rather hire someone who, on their own volition spent 4 years teaching themselves programming, doing their own projects, making things that are interesting, learning about new tech, etc than someone who just showed up to school and did their homework. I also think that self-taught people have a much greater ability to teach themselves new things when they have to. (Your prof won't always be there to tell you exactly how to solve the problem.)
Many excellent developers earned degrees in areas other than CS, or are self-taught and have demonstrably first-rate minds, well worth the salaries on offer.
Don't interpret my statement as a value judgement about the candidates, it's not. A guy who just got a phd in physics would probably have problems with these "programming as math" problems. I was just stating why these types of problems are being used. It's like a secret handshake.
Yeah, some of us (phd) physicists do have these problems.
More interestingly, some of the problems on places like hackerrank, which are expressed as math problems have fundamental problems in that the answers they posit as being correct are not. I dealt with one such failure, where one could write down an closed form solution for a problem in complex analysis that the author mistakenly assumed was a number theory problem. They did not comprehend that their answer was nonsensical.
Well it's true that the ignorance of some of these company's (hiring process) is in fact pretty insulting to the kind of people they really want to hire.
Compare that poor souls experience with Elon Musk's interview question for a tech hiring position, "So, tell me about a time you had a really hard technical problem to solve and how you did it?" The difference is night and day.
Coding challenges involving number-theoretical math have small, simple input cases, and can be stated compactly, yet can be fairly complicated and subtle. They often have the property that it's easy to test whether a solution is correct. They are also a good way to test someone's understanding of subtleties in requirements; if you misunderstand some key element in the problem, you will solve the wrong thing. Some problems in this area will drag in the use of data structures; you may have to keeps some hashes or lists, or even construct a graph. Or generate permutations, or some sort of tree with backtracking and such; it's not necessarily just numbers and nothing but numbers.
I find it true that most coding challenges are either about math, or simple algorithms, such as path finding, DFS/BFS, tree traversal, etc. I think it's because they're simple to explain in a quick way, and don't involve the person needing to know libraries or frameworks.
That being said, most of the coding I've done in my life has been all about integrating different libraries and frameworks together. I don't see a lot of complex algorithms, which is good (because they are complex, and probably someone else already wrote it better, with less bugs and better performance). I'd never want to work with someone who rolls their own red black tree into production code just for the lols.
That being said, I don't think it's a great way to evaluate candidates, because it's not what most people do all day. I find problems about integrating systems, and understanding complex topics like networking, databases, testing, protocols, and APIs to be much more useful.
To find a good middle ground, I like to ask design questions, and then give people a "library" of functions they can call with prototypes, and tell them what they will do. This focuses on the logic of putting it together rather than off by one errors in loops, which still happens to me all the time. Those kinds of bugs are easy to fix when you can actually run the code, but a right pain on a whiteboard.
I'll never forget the look of surprise on the interviewers face when I was doing an intern interview and asked "can I use stdlib calls like memset and memcpy, or do you want me to write loops?" I think just asking the question gave me huge interview points. (and yes, I got the job.)
Let me finish by giving an example of what I thought was a good coding assignment: Write a service that listens to rabbitmq and rotates the images 90 degrees and post them back to a different queue. This wasn't about writing code to rotate images either, it was about knowing how things work, and stitching them together correctly (with the right error handling and failure modes).
I figure the math-heavy tests probably represent an unconscious attempt by elite educated CS guys to homogenize the talent they hire, to build teams of people more or less like those doing the hiring - very smart and well-trained in a particular tradition. Smart matters of course, but a CS background, while worthy, is one among many ways of becoming a competent, creative, productive developer.
Because there is a right and wrong answer. There is very little ambiguity, either the algorithm you wrote on the white board will do the the thing in required time/space complexity or it won't. Which makes it easy to ask and easy to compare candidates.
IMO this is horribly broken but the Big 4 do it so everyone else does too.
1. Because computer science is about mathematics (combinatorics, permutations, counting, etc) and sometimes interviewers want to make sure that the candidate's foundation is solid.
2. As stated in earlier comments, because mathematics is unambiguous making the problem easy to state and easy to verify. Can you take a small piece of mathematics you may not be familiar with, understand it and translate that into working code? That is a core skill of any software developer -- not necessarily with just mathematics but you get the point.
25 comments
[ 3.8 ms ] story [ 74.9 ms ] thread-- "Because that's where the light is."
Less snarkily: that's because they traits that really matter in a modern development environment -- the ability to deal with ambiguity and complexity; to navigate the tipping points between technical perfection and optimal business value; and and top of all this, a genuine sense of humility and a willingness to work with others whose strengths and weaknesses are different from your own -- are very hard to test for, if they can be "tested" for at all.
But since the current interview "process" is so obsessed with "testing" and stack-ranking... not surprisingly, it's largely rigged around traits that are... easy to "test" for.
Like you know, the ability to crank out rehearsed solutions to algorithm puzzles and the like.
> I want to improve my skill but I don't feel like I should pick up advanced algebra or number theory just to do a coding assignment.
Really? Advanced algebra or number theory? Can you show me a coding assignment that required either? Are you sure you're not just excusing your ignorance by suggesting that stuff you've been asked and didn't know the answer to is somehow advanced when it's really not?
An integer partition of a number n is a way of writing n as a sum of positive integers.
Partitions that differ only in the order of their summands are considered the same. A partition of n into distinct parts is a partition of n in which every part occurs at most once.
The partitions of 5 into distinct parts are: 5, 4+1 and 3+2.
Let f(n) be the maximum product of the parts of any such partition of n into distinct parts and let m(n) be the number of elements of any such partition of n with that product.
So f(5)=6 and m(5)=2.
For n=10 the partition with the largest product is 10=2+3+5, which gives f(10)=30 and m(10)=3. And their product, f(10)·m(10) = 30·3 = 90
It can be verified that ∑f(n)·m(n) for 1 ≤ n ≤ 100 = 1683550844462.
Find ∑f(n)·m(n) for 1 ≤ n ≤ 1014. Give your answer modulo 982451653, the 50 millionth prime.
Can they start picking it apart, and at least find some bits of it they can solve, or do they squirm, or whine, or rage quit?
Attacking ridiculously hard requirements is a valuable skill even in crud jobs.
It's more like -- how they cope with some one deliberately playing with their head.
Or if they're not deliberately playing - they're at at least acting very, very pretentiously. Believing that they know how to cook up a "test" for real-life problem-solving skills. When in reality they're just parroting some toy problem they read on the internet somewhere. Or that someone that they thought was cool gave them in an interview way back when.
Can they start picking it apart, and at least find some bits of it they can solve, or do they squirm, or whine, or rage quit?
In a completely contrived and artificial context that not only bears very little resemblance to the conditions in which developers actually do need to solve difficult real-life problems - but in many ways is in fact a grotesque distortion of those conditions.
I'd gotten an offer earlier that morning, so I was a little more self-assured than I would have been otherwise.
No - it's about about people. And helping them solve their real problems.
Math is just a means to that end (one among many).
The question "why are so many coding challenges about maths?" You answer is "it's about the people."
... what?
More interestingly, some of the problems on places like hackerrank, which are expressed as math problems have fundamental problems in that the answers they posit as being correct are not. I dealt with one such failure, where one could write down an closed form solution for a problem in complex analysis that the author mistakenly assumed was a number theory problem. They did not comprehend that their answer was nonsensical.
Compare that poor souls experience with Elon Musk's interview question for a tech hiring position, "So, tell me about a time you had a really hard technical problem to solve and how you did it?" The difference is night and day.
That being said, most of the coding I've done in my life has been all about integrating different libraries and frameworks together. I don't see a lot of complex algorithms, which is good (because they are complex, and probably someone else already wrote it better, with less bugs and better performance). I'd never want to work with someone who rolls their own red black tree into production code just for the lols.
That being said, I don't think it's a great way to evaluate candidates, because it's not what most people do all day. I find problems about integrating systems, and understanding complex topics like networking, databases, testing, protocols, and APIs to be much more useful.
To find a good middle ground, I like to ask design questions, and then give people a "library" of functions they can call with prototypes, and tell them what they will do. This focuses on the logic of putting it together rather than off by one errors in loops, which still happens to me all the time. Those kinds of bugs are easy to fix when you can actually run the code, but a right pain on a whiteboard.
I'll never forget the look of surprise on the interviewers face when I was doing an intern interview and asked "can I use stdlib calls like memset and memcpy, or do you want me to write loops?" I think just asking the question gave me huge interview points. (and yes, I got the job.)
Let me finish by giving an example of what I thought was a good coding assignment: Write a service that listens to rabbitmq and rotates the images 90 degrees and post them back to a different queue. This wasn't about writing code to rotate images either, it was about knowing how things work, and stitching them together correctly (with the right error handling and failure modes).
https://www.hackerrank.com/calendar
I think topcoder (https://www.topcoder.com) covers a wide spectrum, but i have never tried them.
IMO this is horribly broken but the Big 4 do it so everyone else does too.
2. As stated in earlier comments, because mathematics is unambiguous making the problem easy to state and easy to verify. Can you take a small piece of mathematics you may not be familiar with, understand it and translate that into working code? That is a core skill of any software developer -- not necessarily with just mathematics but you get the point.