Yes, the theme is Japan. I thought I'd do something a little different for this round, where instead of the theme revolving around a certain data structure (graphs) or problem-solving paradigm (dp, recursion), it's on the topic of the problems themselves. This will make the problems a little more difficult to solve, since it won't be clear right away which technique should be used to solve the problems (which is why I reduced the number of problems to 5 for this round; it would have been 4 but some of the problems are just lukewarm in difficulty), but hopefully it will be more enjoyable as well! I think people will especially like the last one, even though it's also the most difficult.bernds wrote:Is there a theme for this round?
I think that getting good at these programming competitions is just a skill to be learned. I played around with Google code jam before, but never really got into competitive programming that much. I think it's a useful skill, because both speed of development and small perf optimizations matter.peti29 wrote:Yes. I myself was also considering withdrawing from these contests. But, "not today"!
The thing is, I have very limited free time. On the other hand though it really helps "unrusting" my brain!
(I finally managed to complete my iterative solution for Building Dependencies last night - I'll post it in a moment in the other thread. These problems just stick with me... you can guess my astrology sign...)
At the very least, good for interviews.Kirby wrote: It's a very specific type of programming that these contests require, but getting good at that type of programming probably makes you a better programmer overall.
Indeedoren wrote:At the very least, good for interviews.Kirby wrote: It's a very specific type of programming that these contests require, but getting good at that type of programming probably makes you a better programmer overall.
I'm not into astrology either, but this "relentless trying over and over again" trait of Taurus actually fits quite well in my case.Kirby wrote:I think that getting good at these programming competitions is just a skill to be learned. I played around with Google code jam before, but never really got into competitive programming that much. I think it's a useful skill, because both speed of development and small perf optimizations matter.
It's a very specific type of programming that these contests require, but getting good at that type of programming probably makes you a better programmer overall.
By the way, I'm not up to date on astrological signs, so I have no idea what sign you are.
You'd still want to pick those high-level components that are the most suitable for the task at hand, and I think this is where some of the attempts I've seen posted fall down. Choosing the right representation for the problem at hand will provide an immediate performance benefit and cause fewer problems in the long run.peti29 wrote:I'm a professional software developer btw and (to my experience) the focus is considerably shifted in the industrial environment. One is supposed to write easy to understand code, rely on other components, be good at teamwork, follow certain incentives (e.g. the MVVM way of doing things).
The need to come up with (optimal, non-trivial) algorithms to solve complicated mathematical problems seldom arises (again, in my experience).
Premature optimization is even frowned upon as it makes the code more complicated (more difficult to understand for others, more error-prone), costs more time to implement, and may end up totally unnecessary as the part you are to optimize in most cases will not be the performance bottleneck.
I think you're both right, because it depends on what you're trying to solve. Obviously, there's benefit to choosing the right algorithm, and having something that runs fast. It's a very important dimension to software development.bernds wrote:You'd still want to pick those high-level components that are the most suitable for the task at hand, and I think this is where some of the attempts I've seen posted fall down. Choosing the right representation for the problem at hand will provide an immediate performance benefit and cause fewer problems in the long run.peti29 wrote:I'm a professional software developer btw and (to my experience) the focus is considerably shifted in the industrial environment. One is supposed to write easy to understand code, rely on other components, be good at teamwork, follow certain incentives (e.g. the MVVM way of doing things).
The need to come up with (optimal, non-trivial) algorithms to solve complicated mathematical problems seldom arises (again, in my experience).
Premature optimization is even frowned upon as it makes the code more complicated (more difficult to understand for others, more error-prone), costs more time to implement, and may end up totally unnecessary as the part you are to optimize in most cases will not be the performance bottleneck.
I think it's a bit of a double edged sword. Keeps your DS&A sharp, but especially in competitions where you only have a 90 minutes - 2 hours to solve several problems, readability and cleanliness are sacrificed for keystroke reductions (single-letter variables, huge macro lists, and globals seem to be standard on platforms like TopCoder and Codeforces).oren wrote:At the very least, good for interviews.Kirby wrote: It's a very specific type of programming that these contests require, but getting good at that type of programming probably makes you a better programmer overall.
Yes, I also saw that effect, and I'm not terribly interested in that sort of competition. "Mickey Mouse time limits" comes to mindSolomon wrote:I think it's a bit of a double edged sword. Keeps your DS&A sharp, but especially in competitions where you only have a 90 minutes - 2 hours to solve several problems, readability and cleanliness are sacrificed for keystroke reductions (single-letter variables, huge macro lists, and globals seem to be standard on platforms like TopCoder and Codeforces).
Didn't know such things exist.One thing I like about doing these problems though as opposed to problems from interview prep books is that you don't have to deal with any sort of temptation on trying to memorize the solutions rather than trying to deeply understand the technique, and the problems are way less dryer than the problems in those books (does anyone actually enjoy "prepping" by studying those books?).