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

81–90 of 171 posts

Re: A Competitive Programmer's Handbook

#81

Post by fengwick3 »

bogomipz wrote: post #64
joaorico wrote: post #28

Earlier quoted context omitted.

The book I recommend to people getting started is Competitive Programming 3 [1] by Steven and Felix Halim. It's pretty great if you have already a basic grasp of simple algorithms and a bit of C++. And as you say you need to practice, and the book incentivizes it. They accompany the book with precisely problems from UVa Online Judge, some of them solved and with code (in the book and in the site). [1] https://cpbook.…

Are the only difference between CP 1,2 and 3 that each is a newer version? It's hard to tell from the site.

Subsequent versions contain more algorithms and details. Some subtler optimizations are also mentioned in later books.

Re: A Competitive Programmer's Handbook

#82

Post by Omnipresent »

hal9000xp wrote: post #8

There should be references to problems for each topic at online judges. Like this one: https://uva.onlinejudge.org/index.php?option=com_onlinejudge... Learning algorithms per se is only a small part of training. Much bigger part of training is learning how to recognize these algorithms in problems. After reading about some algorithm, I always solve a couple of related problems. P.S. Looks well-written. Bookmarked. I…

are there other good resources for learning how to apply data structures to problems?

Re: A Competitive Programmer's Handbook

#84

Post by Omnipresent »

tagag wrote: post #36
just2n wrote: post #29

Earlier quoted context omitted.

I don't know where you're getting those figures from, but they're off by more than a factor of 2 based on information I have from friends in Google and previous disclosures here on HN by Googlers. Google won't pay most new hires out of school much over $100k in the bay area, and they adjust based on living expense. AFAIK the higher end of junior compensation is close to $200k, which is where you start getting into th…

For new grad (B.S.) software engineers this year, the standard offer is ~160k total compensation amortized over the first four years, including signing/target annual bonus but not including any raises or stock refreshers that may happen. I'm graduating with an M.S., starting this summer. Using competing offers, I negotiated up to 190-195k amortized over four years, including 215-220k in the first year (because of sig…

Any particular resources you'd recommend for getting good at white boarding?

Re: A Competitive Programmer's Handbook

#85

Post by tagag »

Omnipresent wrote: post #84
tagag wrote: post #36

Earlier quoted context omitted.

For new grad (B.S.) software engineers this year, the standard offer is ~160k total compensation amortized over the first four years, including signing/target annual bonus but not including any raises or stock refreshers that may happen. I'm graduating with an M.S., starting this summer. Using competing offers, I negotiated up to 190-195k amortized over four years, including 215-220k in the first year (because of sig…

Any particular resources you'd recommend for getting good at white boarding?

Elements of Programming Interviews until you can do Leetcode mediums with a good success rate. Then grind Leetcode, try to work your way up to hards. Practice EPI problems with a friend on a physical whiteboard throughout. I did this for a month leading up to my interviews and it helped immensely.

Re: A Competitive Programmer's Handbook

#86

Post by mck- »

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.

Agreed. These kinds of competitions or coding interviews may cause over-fitting.

Re: A Competitive Programmer's Handbook

#87

Post by nkozyra »

mck- wrote: post #86
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.

Agreed. These kinds of competitions or coding interviews may cause over-fitting.

Is there really risk in being particularly adept at algorithm design?

Re: A Competitive Programmer's Handbook

#88

Post by aswanson »

nkozyra wrote: post #87
mck- wrote: post #86

Earlier quoted context omitted.

Agreed. These kinds of competitions or coding interviews may cause over-fitting.

Is there really risk in being particularly adept at algorithm design?

No, but by definition, any non-trivial software product (or academic CS paper, for that matter) is the outcome of a collaborative process, not an artificially time-constrained hack-a-thon/competition. You have to put things like this in their proper place, and let them be what they are. (I downloaded the pdf, btw).

Re: A Competitive Programmer's Handbook

#89

Post by [deleted] »

dsacco wrote: post #46
gpawl wrote: post #44

Earlier quoted context omitted.

Relax, parent poster was simply clarifying that the 'competitive' referred to programming "sports" contests, not competing for a programming job.

Sure, but I don't think a good faith interpretation of the title would require that sort of disclaimer, and look at the rest of the thread that resulted.

[deleted]

Re: A Competitive Programmer's Handbook

#90

Post by kazarov »

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.

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 good at competitions, because competitions require certain specific skills that are not useful outside of competitions. And that's why good interviews don't put too much weight on algorithmic skills.

Post reply on HN