4 ms·

> Also, even though competitions won't help you develop as a mathematician, I still think it was a good experience for me to get out of school for a day and han

> Also, even though competitions won't help you develop as a mathematician, I still think it was a good experience for me to get out of school for a day and hang out with a bunch of other math nerds. That part of it was a lot more valuable than the competition itself. I haven't done math competitions, but I feel the same way about programming competitions. I don't think I'm a better programmer because of the competitions. But I do think spending 4 hours, 2-3 days a week in a room with other programmers who were also there voluntarily made me much better. It's not like I stopped focusing on my own projects or coursework and did this instead. It was just an additional 12 hours a week of practice and socializing. Some problems were hilariously artificial too. I still remember one, where 10-year-old Suzie had a lemonade stand and had been keeping track of her profits each day. You needed to find the 3 consecutive days in which she had made the most total profit. The catch? It needed to run in less than 1 second and the largest case could (which means it will) be n=9999999. (I may be off by an order of magnitude). Little Suzie had been running her lemonade for well over 27,000 years apparently, but would throw a tantrum if it took more than 1 second to compute her answer.

jnbiche 10y ago
> I haven't done math competitions, but I feel the same way about programming competitions. I don't think I'm a better programmer because of the competitions. While you may be correct with respect to actual day-to-day programming, I'm 100% sure that programming competitions make you a much stronger interviewer for typical software developer interviews. I've never competed in programming competitions, but I've seen the types of questions they ask, and many if not most of the interviews I've experienced recently use the exact same kinds of questions. And in some cases, even the exact same questions!
- j0e1 10y ago
  That just makes me think that they are not doing interviews right either -- ranking based on how quickly you can whip up an algorithm for a tricky question.
  - Retric 10y ago
    I just conducted several technical interviews. Starting with a very basic question even for people with years of experience shows you quite a bit. It's not about getting it correct, it's can you get in the correct ballpark and you can evaluate what your doing. Create a function that returns true or false if _. Followed by far more hand holding that I was expecting, but most people got the idea fairly quickly. Only person who failed wanted to add a lot of print statements for no reason. And then did not respond to help. IMO, good interview questions are such that most people pass. I mean your bringing them in so asking something you had to google is a waste of time. The goal should be to minimize false negatives while still removing some people. The classic what is an Object, what is an Interface is just filler that tells you little. And very technical questions have ridiculous false negative rates. So, just softball an easy code problem, ask about background and fit, and call it a day. PS: Remember you're interviewing people for a reason. When a good fit backs out you lose not just time but potentially a great coworker.
    - bbarn 10y ago
      The PS is something people forget all the time. It's a learned skill to make interviewees feel like this isn't an adversarial meeting, but a mutual interviewing. That said, you're right. Just this week I interviewed someone with almost 30 years experience, some of it dev, architect, some management, for a pure developer role, and gave him "Write a function(n) that takes an integer and gives you the nth number in the Fibonacci sequence." Got very angry and said he didn't know the algorithm, so I drew it on the board and explained it (red flag for someone who was a former "scrum master" not knowing what the Fibonacci sequence was), and he told me that it was arbitrary and academic and a waste of time. I asked him to do it anyway since it was to see his style and approach, and he got mad and left. Most junior devs solve this problem in ten-fifteen minutes, and I consider it actually more of an interactive ice breaker to get us both standing and talking rather than a stumper.
      - inimino 10y ago
        Are you sure that's really the hiring process you want? Junior devs were more recently in school, which is the last time such knowledge is needed. If you have actual technical challenges relevant to your work, why not take that hint and shift the interview to something that might possibly come up on the job and that isn't trivial for a junior dev? Instead of finding out what that candidate was good at, you just found out which academic trivia he doesn't remember, and that he has a low tolerance for irrelevant bullshit.
tinalumfoil 10y ago
> It needed to run in less than 1 second I've always wondered how these competitions measure the program's runtime consistently. I guess the easiest way would be to specify the CPU the program will run on and use the bash `time` builtin, but that seems inconvenient for participants to obtain that CPU and controlling for the cache might be difficult (maybe a kernel module that clears the cache before the program runs and make sure the program runs fully in cores dedicated to that program and is consistent enough with memory accesses so L3 is comparable). On the other hand they could just count instructions run, which would be completely deterministic, but might lead to some "optimizations" that don't make sense like using `rep movs` to zero memory instead of loops. Using a higher-level bytecode would have the same problems. They could also give different values to each instruction and possibly memory access, but even then students would be ignoring important real-world cache or pipeline optimizations. But maybe I'm just overthinking this. This type of problem would be better suited for GPUs anyway.
- ludamad 10y ago
  The time limits are overkill except if you chose the algorithm wrong.
  - ufo 10y ago
    In fact, you can often get a good ballpark-estimate of what big-O runtime your algorithm needs to have, just from the time limit. This can work as a hint on how to solve the problem.
- deleted 10y ago
  [deleted]
- squeaky-clean 10y ago
  The other commenters are right, the time limits were a non-issue if you chose the right algorithm. It might be the difference between solving it in 30 years and 300ms. I'm probably misremembering that specific problem, but they were typically very easy problems, but with a huge n and some small 'gotcha' to the scenario that allowed an algorithmic or dynamic programming trick. Not realistic at all, but they were lots of fun. All of the problems weren't like that, but those were the hardest to get.

jnbiche 10y ago

> I haven't done math competitions, but I feel the same way about programming competitions. I don't think I'm a better programmer because of the competitions. While you may be correct with respect to actual day-to-day programming, I'm 100% sure that programming competitions make you a much stronger interviewer for typical software developer interviews. I've never competed in programming competitions, but I've seen the types of questions they ask, and many if not most of the interviews I've experienced recently use the exact same kinds of questions. And in some cases, even the exact same questions!

j0e1 10y ago
That just makes me think that they are not doing interviews right either -- ranking based on how quickly you can whip up an algorithm for a tricky question.
- Retric 10y ago
  I just conducted several technical interviews. Starting with a very basic question even for people with years of experience shows you quite a bit. It's not about getting it correct, it's can you get in the correct ballpark and you can evaluate what your doing. Create a function that returns true or false if _. Followed by far more hand holding that I was expecting, but most people got the idea fairly quickly. Only person who failed wanted to add a lot of print statements for no reason. And then did not respond to help. IMO, good interview questions are such that most people pass. I mean your bringing them in so asking something you had to google is a waste of time. The goal should be to minimize false negatives while still removing some people. The classic what is an Object, what is an Interface is just filler that tells you little. And very technical questions have ridiculous false negative rates. So, just softball an easy code problem, ask about background and fit, and call it a day. PS: Remember you're interviewing people for a reason. When a good fit backs out you lose not just time but potentially a great coworker.
  - bbarn 10y ago
    The PS is something people forget all the time. It's a learned skill to make interviewees feel like this isn't an adversarial meeting, but a mutual interviewing. That said, you're right. Just this week I interviewed someone with almost 30 years experience, some of it dev, architect, some management, for a pure developer role, and gave him "Write a function(n) that takes an integer and gives you the nth number in the Fibonacci sequence." Got very angry and said he didn't know the algorithm, so I drew it on the board and explained it (red flag for someone who was a former "scrum master" not knowing what the Fibonacci sequence was), and he told me that it was arbitrary and academic and a waste of time. I asked him to do it anyway since it was to see his style and approach, and he got mad and left. Most junior devs solve this problem in ten-fifteen minutes, and I consider it actually more of an interactive ice breaker to get us both standing and talking rather than a stumper.
    - inimino 10y ago
      Are you sure that's really the hiring process you want? Junior devs were more recently in school, which is the last time such knowledge is needed. If you have actual technical challenges relevant to your work, why not take that hint and shift the interview to something that might possibly come up on the job and that isn't trivial for a junior dev? Instead of finding out what that candidate was good at, you just found out which academic trivia he doesn't remember, and that he has a low tolerance for irrelevant bullshit.

tinalumfoil 10y ago

> It needed to run in less than 1 second I've always wondered how these competitions measure the program's runtime consistently. I guess the easiest way would be to specify the CPU the program will run on and use the bash `time` builtin, but that seems inconvenient for participants to obtain that CPU and controlling for the cache might be difficult (maybe a kernel module that clears the cache before the program runs and make sure the program runs fully in cores dedicated to that program and is consistent enough with memory accesses so L3 is comparable). On the other hand they could just count instructions run, which would be completely deterministic, but might lead to some "optimizations" that don't make sense like using `rep movs` to zero memory instead of loops. Using a higher-level bytecode would have the same problems. They could also give different values to each instruction and possibly memory access, but even then students would be ignoring important real-world cache or pipeline optimizations. But maybe I'm just overthinking this. This type of problem would be better suited for GPUs anyway.

ludamad 10y ago
The time limits are overkill except if you chose the algorithm wrong.
- ufo 10y ago
  In fact, you can often get a good ballpark-estimate of what big-O runtime your algorithm needs to have, just from the time limit. This can work as a hint on how to solve the problem.
deleted 10y ago
[deleted]
squeaky-clean 10y ago
The other commenters are right, the time limits were a non-issue if you chose the right algorithm. It might be the difference between solving it in 30 years and 300ms. I'm probably misremembering that specific problem, but they were typically very easy problems, but with a huge n and some small 'gotcha' to the scenario that allowed an algorithmic or dynamic programming trick. Not realistic at all, but they were lots of fun. All of the problems weren't like that, but those were the hardest to get.