Live data from Hacker News

A Competitive Programmer's Handbook

cses.fi

111–120 of 171 posts

Re: A Competitive Programmer's Handbook

#111

Positive correlation between Competitive Programmer’s Handbook and software engineer interviews? Yes. Positive correlation between being a strong competitive programmer and a strong software engineer? Doubtful.

Being good at programming competitions correlates negatively with being good on the job - Peter Norvig http://www.catonmat.net/blog/programming-competitions-work-p...

Very interesting. Although I think he's speaking specifically about competition winnners, not just being good at them.

Re: A Competitive Programmer's Handbook

#112

Earlier quoted context omitted.

Not doubtful at all. You can expect a positive correlation between being an good driver and a good software engineer. Definitely some random person with the CS fundamentals, coding fluency, and creative problem solving ability to be good at competitive programming is more likely to be good at software engineering than some random developer. You're basically saying, high intelligence isn't correlated with being a stro…

>> Or maybe you think people doing competitive programming are damaged. This is nuts. I don't see how that is implied by GP's comment. It is one thing to read between the lines, but now you are reading between the characters.

Yup. More mental "shortcuts" that seek magic "signals" to avoid both evidence and pragmatic interviewing effort testing both business problem-solving critical thinking and cultural fit. There are no shortcuts. Furthermore, "competitive" programming has little to do with the real world, and it's more about showing off and ego inflation.

Re: A Competitive Programmer's Handbook

#113
post #100

Earlier quoted context omitted.

It sounds like it may have been awhile since you've interviewed. The modern "good" interview is all data structure and algorithm white boarding nonsense. For me, who is not a competitive programmer, the standard interview prep is spending a couple of hours on Hacker Rank every day and making sure I can delete a node in a binary tree on a white board without so much a missing semicolon. For some reason that signals "g…

From my experience i'd rather work with programmers with strong CS skills. They put out better code

I'd rather work with the ones who actually care about the people they're solving problems for vs the ones who can write bubble sort with no reference material, which happens in the real world precisely never. Employers pay developers to solve problems, not necessarily to write the most efficient code possible. I get that it's a craft and it's good to understand what happens under the hood, but you can get pretty damn far solving actual business problems for people without having to care which brand of sort ES2016 uses. These skills in micro-optimizations / textbook CS don't help much with understanding customers and solving their problems at the end of the day, so they're really not that valuable for many business scenarios. I think that a lot of engineers in this industry forget that they're not generally paid to write the most efficient data structures and algorithms for 40 hours a week, and that ironically, attempting to do so would very likely not be the most efficient means of increasing shareholder value. Can't see the forest for the B-trees, if you will.

https://github.com/poteto/hiring-without-whiteboards has a list of companies who don't participate in this particular flavor of shenanigans.

Re: A Competitive Programmer's Handbook

#114

Positive correlation between Competitive Programmer’s Handbook and software engineer interviews? Yes. Positive correlation between being a strong competitive programmer and a strong software engineer? Doubtful.

I observed a correlation between competitive programmers and those who come across as just hacking at it until it works in interviews. If your interview system is looking for people who think about things then it probably already biases against many competitive programmers correctly.

Re: A Competitive Programmer's Handbook

#116
post #55

Earlier quoted context omitted.

Sadly the proliferation of sites like HackerRank (YC funded shamefully) means competitive programming is the first "filter" stage for interviews these days.

I'd love it if there were more opportunities from companies like HackerRank. It's other "filters" that I'm worried about; companies that filter out degree-less candidates, companies that filter out depressed candidates, companies that filter out transgender candidates, etc.

>>degree-less candidates, companies that filter out depressed candidates, companies that filter out transgender candidates, etc.

Sorry, these are completely different things and frankly sounds like nonsense.

Re: A Competitive Programmer's Handbook

#117

Earlier quoted context omitted.

Sadly the proliferation of sites like HackerRank (YC funded shamefully) means competitive programming is the first "filter" stage for interviews these days.

Is that sad? It's a better filter than college degrees.

So your ability in a pressured limited-time environment come up with an O(N) dynamic programming algorithm for a fictitious scenario is a testament to your ability as a software engineer versus a competitive programmer who can pattern match scenarios?

Re: A Competitive Programmer's Handbook

#118

Positive correlation between Competitive Programmer’s Handbook and software engineer interviews? Yes. Positive correlation between being a strong competitive programmer and a strong software engineer? Doubtful.

I have had a lot of experience with competitive programming (competed in NWERC and NCPC multiple times) and this idea that competitive programming makes you worse at software engineering comes up every now and then. From what I've noticed your statement holds a bit of truth, but I just wanted to add from my own experiences. To me it seems like those that have done a little bit of competitive programming are good coders. They can code a FizzBuzz in 2 minutes without blinking, they are people that will reach the magic 10K hours of coding quicker than most. However, those that excel at competitive programming can code FizzBuzz in 30 seconds but you will have a hard time understanding what they have actually written. I think that there is a point in competitive programming you pass where you actively have to sacrifice the understandability of your code (and your algorithm library) for increased implementation speed. I also think that in order to excel at competitive programming you have to devote a lot of time to learning algorithmic theory and training on problems which can be solved in <1K lines of code. (Most solutions I've written are less than 300 lines) The hypothesis I have is that in order to be a great competitive programmer you will have to routinely write bad code and put a lot of effort into solving problems which you will later throw away the solution to and never look at again. Two properties that do not help with software engineering skills. However, if you are only moderately devoted to competitive programming, then you can earn the practical experience (hours of coding) without reducing the quality of your code.

Re: A Competitive Programmer's Handbook

#119

Positive correlation between Competitive Programmer’s Handbook and software engineer interviews? Yes. Positive correlation between being a strong competitive programmer and a strong software engineer? Doubtful.

I have had a lot of experience with competitive programming (competed in NWERC and NCPC multiple times) and this idea that competitive programming makes you worse at software engineering comes up every now and then. From what I've noticed your statement holds a bit of truth, but I just wanted to add from my own experiences. To me it seems like those that have done a little bit of competitive programming are good code…

    write bad code [...] which 
    you will later throw away
Implementing a quick & dirty prototype, throwing it away and reimplementing it from scratch is not such a bad software engineering techique: first time to understand the problem, second time to make the implementation nice.

A lot of bad software comes from not throwing the prototype away, but insteat trying to refine it into a product. Result = spaghetti.

Re: A Competitive Programmer's Handbook

#120

Positive correlation between Competitive Programmer’s Handbook and software engineer interviews? Yes. Positive correlation between being a strong competitive programmer and a strong software engineer? Doubtful.

Being good at programming competitions correlates negatively with being good on the job - Peter Norvig http://www.catonmat.net/blog/programming-competitions-work-p...

This is relative to other people who had been hired at Google - there's probably still a positive correlation between those two variables amongst the general population.
Post reply on HN