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

Competitive Programmer's Handbook (2017) [pdf]

cses.fi

Post reply on HN
Print view View original

51–60 of 127 posts

Re: Competitive Programmer's Handbook (2017) [pdf]

#51

Post by photoJ »

ctlby wrote: post #26
chillee wrote: post #22

Earlier quoted context omitted.

Well, I think you're kind of misrepresenting his point as "competitive programming doesn't improve your programming abilities". It's not that competitive programming correlates poorly with job performance; it's that, given you've been hired by Google, being a competitive programmer correlates poorly with job performance. Hypothetically, let's say there's 2 dimensions for a programmer's ability, competitive programmin…

Berkson’s paradox

Do you think there is no correlation or the correlation is in fact positive? I wondered if they every AB test with lower standards for new hires.

Re: Competitive Programmer's Handbook (2017) [pdf]

#52

Post by bitL »

banachtarski wrote: post #45
bitL wrote: post #21

Earlier quoted context omitted.

He's not joking though. I've experienced 3 rounds of stupid tricky questions followed by a 4 hour "take home" project at a UK startup in Deep Learning before they were willing to even send flight tickets to London, and the feedback I've received was so comical that I almost wrote a blog post about it (I still might). Another robotic startup in SV grills with 6-hour stupid codility tests as a first phase (i.e. waste 6…

The problem is, for every person like you, there's a person like me that actually likes those types of challenges and wouldn't actually mind being thrown into that type of gauntlet. My years of experience be damned.

Sure, that might be the case. But for those funny needs I have a "crazy algorithm course" from a top 10 university, ACM ICPC and Kaggle or other paid competitions I can attend. I am not going to go through such an interview doing simple silly things I did dozen times before at FB/Goog/etc., when I know I can use that time to work on something more interesting, or just for relaxing after a hard work/enjoying accomplishments. I would advise companies hiring to at least once read CV and click through GitHub code, and then just focus on the only important question - would they like to work with me as a person or not? That would save everyone time and lead to better results.

One self-driving car start-up in SV wanted me to solve a long-standing research problem (Deep Learning) as their week-long take home test. Thanks, but when I do, you can license my tech, I will gladly make it available to you for $.

Re: Competitive Programmer's Handbook (2017) [pdf]

#53

Post by nordsieck »

gaius wrote: post #42
harshgupta wrote: post #40

Earlier quoted context omitted.

I think its more of aptitude test in a domain common to all programmers.

Yeah right. Tell me the last time you built your own red-black tree in real actual code at work. Or did a sort by any other means than tacking “order by” on the end of a query. They are a test of how recently you crammed for your CS finals, that’s all.

There are languages - C and Go, and to a lesser extent, C++ - in which re-implementation of data structures and algorithms is not uncommon.

To your larger point, data structures and algorithms are popular in interviews for the same reason Project Euler is popular - it is very easy to ask a well defined, but interesting question about core CS or math.

Re: Competitive Programmer's Handbook (2017) [pdf]

#54

Post by bradlys »

gaius wrote: post #42
harshgupta wrote: post #40

Earlier quoted context omitted.

I think its more of aptitude test in a domain common to all programmers.

Yeah right. Tell me the last time you built your own red-black tree in real actual code at work. Or did a sort by any other means than tacking “order by” on the end of a query. They are a test of how recently you crammed for your CS finals, that’s all.

Or how much effort you're willing to put into prepping for interviewing and getting a new job. It definitely filters against the casual looker.

Which, to some extent, makes sense. You're basically filtering out people who won't put in the effort to get the job. Whether or not those who put in the extra effort are actually going to be better employees is a different decision.

Re: Competitive Programmer's Handbook (2017) [pdf]

#55

Post by sireat »

gaius wrote: post #31
zerr wrote: post #29

The most irritating thing with these competitive/algo stuff is that no matter how many times you master it - eventually you always forget it, because you don't need it on a daily (or more like yearly) basis in the real world.

That’s the entire point of those kinds of interviews. It’s a strong filter for “recent graduate” while maintaining plausible deniability for ageism. It has a secondary effect of filtering for “willing to do unpaid overtime”.

I do wonder how many 40+ programmers are able to keep up with "young ones" in these contests.

I fear it is like chess, the cognitive decline starts to become noticable in the mid 40s and only gets worse from then on.

There are a few exceptions like Korchnoi was in chess so there must be Fabrice Bellards and Bill Joys who would be able to keep up.

Still looking at completion times for Advent of Code made me feel old.

Re: Competitive Programmer's Handbook (2017) [pdf]

#56

Post by kashyapc »

harshgupta wrote: post #40
gaius wrote: post #31

Earlier quoted context omitted.

That’s the entire point of those kinds of interviews. It’s a strong filter for “recent graduate” while maintaining plausible deniability for ageism. It has a secondary effect of filtering for “willing to do unpaid overtime”.

I think its more of aptitude test in a domain common to all programmers.

Give us a frelling break. Please don't willingly invite derison.

Re: Competitive Programmer's Handbook (2017) [pdf]

#57

Post by tedmiston »

gaius wrote: post #31
zerr wrote: post #29

The most irritating thing with these competitive/algo stuff is that no matter how many times you master it - eventually you always forget it, because you don't need it on a daily (or more like yearly) basis in the real world.

That’s the entire point of those kinds of interviews. It’s a strong filter for “recent graduate” while maintaining plausible deniability for ageism. It has a secondary effect of filtering for “willing to do unpaid overtime”.

That's enlightening. Never thought of it that way.

Re: Competitive Programmer's Handbook (2017) [pdf]

#58

Post by loup-vaillant »

irundebian wrote: post #47
svat wrote: post #24

Earlier quoted context omitted.

Another reason for shortening code in programming contests (apart from being able to type and edit/iterate faster) is that it helps you avoid errors. For example, in the heat of the moment and under intense time pressure (e.g. you have finally figured out the algorithm to solve the problem, but you have only 13 minutes left to implement it or whatever), it's easy to write code like this: for (int i = 0; i instead of…

I'm not sure that you avoid errors by forcing yourself to write short code. With C macros.

Here's a real world example:

https://github.com/LoupVaillant/Monocypher/commit/d7bb73f65a...

So I have this function, `crypto_wipe()` that wipes memory regions with `volatile` so the compiler doesn't optimises it away. In the link above I was using it thus:

  crypto_stuff(stuff_ctx *ctx) {
      // stuff
      crypto_wipe(ctx, sizeof(ctx)); // BUUUG!!
  }
See the bug? I should have dereferenced `ctx` in the sizeof operator. As it was, was only wiping a pointer's worth of data instead of the whole structure. Oops.

Now I write this instead:

  crypto_stuff(stuff_ctx *ctx) {
      // stuff
      WIPE_CTX(ctx); // correct!
  }
The amount of repetition I avoid this way is almost negligible, but that was enough to trigger a mistake (I had quite a lot of wiping to do). With the macro, errors are much easier to spot (so much so that I am willing to give 100€ to anyone who finds such an error, see https://monocypher.org/quality-assurance/bug-bounty)

Re: Competitive Programmer's Handbook (2017) [pdf]

#60

Post by joshvm »

I like this book, but I have some reservations for using it for interview practice. There is no discussion on implementation of some of the algorithms, which may be relevant in an interview (e.g. if you're not allowed to use std::sort).

There are also a lot of topics where there's a brief overview of the algorithm, but no code - e.g. the geometry section is interesting and has some useful ideas, but no implementation. This gets worse as the algorithms get more complicated, and some quite difficult topics get a cursory glance.

For the general categories of problems that you find on e.g. LeetCode or Intervewbit, this book is really useful. It's a good, practical, companion to a proper algorithms textbook.

Perhaps most irritating - if using this for prep - is that there are virtually no case studies, and the case studies that are in there assume a lot of code which isn't in the book (either boilerplate or assistance functions). This book would be incredibly valuable if each chapter had a list of example problems (solved or unsolved) to see how things are applied.

Post reply on HN