Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Competitive Programmer's Handbook

cses.fi

Post reply on HN
Print view View original

131–140 of 171 posts

Re: A Competitive Programmer's Handbook

#131

Post by bogomipz »

aisofteng wrote: post #128
bogomipz wrote: post #126

This seems to be horribly written. Example: >"In the German Lotto you have to select 6 numbers from the set {1,2,...,49}. A popular strategy top lay Lotto - although it doesn’t increase your chance of winning — is to select a subset S containing k (k > 6) of these 49 numbers, and then play several games with choosing numbers only from S. For example, for k = 8 and S = {1, 2, 3, 5, 8, 13, 21, 34} there are 28 possible…

The problem is your reading comprehension. That reads just fine to me. Pretty standard writing.

Your snide comment is completely uncalled for.

My reading comprehension is just fine, the following statement is full of ambiguity:

"subset S containing k (k > 6)"

A more articulate way to express that would be "subset S that contain k elements where k is greater than 6"

Re: A Competitive Programmer's Handbook

#133

Post by nneonneo »

bogomipz wrote: post #126

This seems to be horribly written. Example: >"In the German Lotto you have to select 6 numbers from the set {1,2,...,49}. A popular strategy top lay Lotto - although it doesn’t increase your chance of winning — is to select a subset S containing k (k > 6) of these 49 numbers, and then play several games with choosing numbers only from S. For example, for k = 8 and S = {1, 2, 3, 5, 8, 13, 21, 34} there are 28 possible…

First, the parent poster was referring to the book being well written, not to the set of practice problems from an entirely different book. Thus, your "horribly written" comment comes off as a non sequitur.

Second, the subset contains k elements. The phrasing "select a subset S containing k of these elements" is standard mathematical terminology. I'm not sure how you read this as meaning that each element needed to be less than k.

Re: A Competitive Programmer's Handbook

#134

Post by boltzmannbrain »

jodooshi wrote: post #98
boltzmannbrain wrote: post #83

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...

Oh cool, I was hesitant to say "positive correlation" without data. Thanks for the link!

Re: A Competitive Programmer's Handbook

#135

Post by detaro »

bogomipz wrote: post #131
aisofteng wrote: post #128

Earlier quoted context omitted.

The problem is your reading comprehension. That reads just fine to me. Pretty standard writing.

Your snide comment is completely uncalled for. My reading comprehension is just fine, the following statement is full of ambiguity: "subset S containing k (k > 6)" A more articulate way to express that would be "subset S that contain k elements where k is greater than 6"

"subset S containing k (k > 6) of these 49 numbers", don't cut something important out of the statement and then argue it is "full of ambiguity".

Re: A Competitive Programmer's Handbook

#136

Post by boltzmannbrain »

thr0waway1239 wrote: post #94
SamReidHughes wrote: post #91

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.

Reading between the lines: Problems that are typical of software engineering interviews and in competitive programming are poor evaluation of one's capabilities as a professional software engineer.

Re: A Competitive Programmer's Handbook

#137

Post by kazarov »

goostavos wrote: post #99
kazarov wrote: post #90

Earlier quoted context omitted.

I'm pretty sure there is a positive correlation, just because people who tend to be good at competitions usually do them because they like computer science in general, so they learn other stuff too (and they are likely smart). And this is also a reason why this side is tested so much in interviews - it is easy to test and the result is somewhat significant. Now, most good software engineers would probably not be very…

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…

I interviewed this week. While there were a few whiteboard coding questions that I personally wouldn't ask, most of the interviews were quite reasonable (mostly algorithmic still, but it was in robotics, so understandable). But yeah, I actually don't understand why people insist on using a whiteboard so much. Everybody has a computer these days and typing is much faster.

At my previous company (not robotics) I conducted a lot of interviews and I think we hit a good balance between algorithmic problems and design/architecture ones. Then again, even algorithms questions can be formulated as real world problems - it help weeding out obvious brain teasers. We also didn't asks people to write code on the whiteboard - there was a separate coding exercise.

I don't even think that asking about algorithms is such a bad thing if you do it correctly and it's not all what you do. But perhaps too many people just throw a problem at the interviewee without and help or guidance.

Overall, conducting a good interview is hard and it is not a primary job of most engineers who do it, so it's not surprising there are quite a few bad interviewers out there.

Re: A Competitive Programmer's Handbook

#138

Post by bogomipz »

detaro wrote: post #135
bogomipz wrote: post #131

Earlier quoted context omitted.

Your snide comment is completely uncalled for. My reading comprehension is just fine, the following statement is full of ambiguity: "subset S containing k (k > 6)" A more articulate way to express that would be "subset S that contain k elements where k is greater than 6"

"subset S containing k (k > 6) of these 49 numbers ", don't cut something important out of the statement and then argue it is "full of ambiguity".

I didn't cut anything out I actually reposted verbatim the entire problem description in my post. Or did you choose not to read that part?

Re: A Competitive Programmer's Handbook

#139

Post by detaro »

bogomipz wrote: post #138
detaro wrote: post #135

Earlier quoted context omitted.

"subset S containing k (k > 6) of these 49 numbers ", don't cut something important out of the statement and then argue it is "full of ambiguity".

I didn't cut anything out I actually reposted verbatim the entire problem description in my post. Or did you choose not to read that part?

I specifically meant the post I replied to (where I'd agree, just that piece would be ambiguous. The full one as quoted in your initial post is not, because the part I highlighted clarifies the meaning)

Re: A Competitive Programmer's Handbook

#140

Post by hashhar »

mafribe wrote: post #119
catears wrote: post #118

Earlier quoted context omitted.

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.

I agree. I got into the practice after I picked up F#. I used to create simple solutions in the interactive REPL as mainly proof of concepts. Once I had the basics down, I sat down and wrote a list of possible edge cases, expected user inputs, the format of output and the command line interface for the tool. Then I started coding from scratch and had a good and clean working solution ready. Helped me a lot.
Post reply on HN