Earlier quoted context omitted.
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).
A Competitive Programmer's Handbook
101–110 of 171 posts
Re: A Competitive Programmer's Handbook
#102Earlier 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 actually don't mind that. The filter works both ways - it tells me the company in question is clueless about hiring tech talent, so I can ignore them.
Re: A Competitive Programmer's Handbook
#103Earlier quoted context omitted.
Is there really risk in being particularly adept at algorithm design?
The risk is that you might be less useful than someone who is particularly adept at system design. It seems most problems are actually not sorting, searching, or finding the optimal whatever. Maybe it's just the bubble I work in, but from my perspective it seems that most programmers aren't addressing a problem of the form, "the obvious solution to this well-defined problem is too slow, please have a clever insight t…
Re: A Competitive Programmer's Handbook
#104Re: A Competitive Programmer's Handbook
#105Earlier quoted context omitted.
Nothing to do with the actual job but it is heavily used for interviews to get that actual job, unfortunately.
This is my understanding as well. Data structures and basic algo comes up in interviews, and if you pass that's probably the last of it too. I never studied them originally, but once I realised it was a blocker to getting a new job I spent some time to learn the basics at least which truly helped a lot. It was also a bit of fun, to be honest - even though they have almost no bearing on the day to day work. So I'm int…
Re: A Competitive Programmer's Handbook
#106Re: A Competitive Programmer's Handbook
#107Earlier quoted context omitted.
...and be outsourced to the fine Bangalorian sweatshops sooner or later. :) And it is not "really well paid". Really well paid is, like, 250k/year, and it is somewhat hard to extract it from just Java in an average bank.
> ...and be outsourced to the fine Bangalorian sweatshops sooner or later. In my experience, the jobs of the mediocre get outsourced to said sweatshops to be done by equally mediocre people for cheaper. I've worked for two big banks as a software dev, and there are plenty of long term, extremely high paid positions for Java engineers that'll never get outsourced. The model seems to be: have a group of on-site, well p…
Re: A Competitive Programmer's Handbook
#108Re: A Competitive Programmer's Handbook
#109Earlier 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?
Re: A Competitive Programmer's Handbook
#110Earlier quoted context omitted.
The same skills used in competitive programming are needed to pass a modern day technical interview at some of the larger companies. So I wouldn't necessarily say it has nothing to do with getting a better job or salary.
Staying fit also helps job performance, as does public speaking. Shall we start a comprehensive list of skills and activities tangentially related to making more money?