I'm not able to watch the video at my current computer<p>but its actually really typical that when something becomes an advantage for being selected to a certain pool<p>the success of the those in the pool after the selection will negatively correlate with that thing<p>---------<p>the really obvious example of this is the hockey birthday thing from Malcolm Gladwell's Outliers<p>people with the earlier birthdays were more likely to make it past each selection stage in becoming an NHL player<p>but those with the later birthdays who were able to be selected in spite of their later birthdays, were typically more successful after the selection<p>---------<p>The authors contend that the strategy might actually work against a team's success because they found that players born later in the year and drafted later actually had more productive hockey careers.<p>Deaner said the study showed that men drafted in the second half of the year were about twice as likely to have successful careers in the NHL ??? reaching benchmarks like 400 games played or 200 points scored ??? than those born earlier in the year.<p>"If the team wasn't making this mistake, they probably would have been more successful," he said. "The guys born in the first part of the year are much more likely to be busts."<p><a href="https://www.nhl.com/news/study-suggests-nhl-has-bias-in-favour-of-players-born-earlier-in-the-year/c-657724" rel="nofollow">https://www.nhl.com/news/study-suggests-nhl-has-bias-in-favo...</a>
I'm also a former ICPC world finalist and I'm willing to believe this is the case in a BigCo because:
1) Top ICPC competitors tend to be extremely socially awkward, and may not work well in groups.
2) Vast majority of engineering work is very algorithmically simple, thus these folks don't get a chance to "shine".<p>However, I've noticed that they are popular in prop trading firms, where work tends to be in very small teams or individual. I don't know how their performance correlates to fund performance.<p>If I were hiring, I'd still prefer to hire at least some top ICPC performers. The hard algorithms are rare---but can make or break your product.<p>I also think the knowledge learned from programming contests is invaluable. I'd like to be able to discuss bipartite matching or min-cut with my colleagues without eliciting a blank look.
Just like 'There is no such person as Good CEO', but only 'A Good CEO for a particular company, at a particular point of time', there is no such a person as 'Good Programmer', there is only 'A Good Programmer for a particular job, at a particular point of time'.<p>Context matters a lot. One does not use an AK-47 to kill a mosquito. It is terrible for that job. But that does not make AK-47 a terrible weapon.<p>Good at programming competitions does not equal good at any programming job, is a more appropriate sentence.
In the chapter of his interview in <i>Coders at Work</i>[0], Norvig found that the strongest correlate in the interview process with success at Google was paradoxically to have been given the <i>lowest</i> possible score by one of the interviewers. He surmised that this was because in order for such a person to have even gotten hired at the end of the process, someone trustworthy must have seen so much potential in the prospective hire that he strongly advocated for the person to be offered a position which worked <i>in spite</i> of that other low rating.<p>Kind of ironic for a company whose product values are so tightly tied to quantitive data.<p>[0]<a href="http://www.apress.com/us/book/9781430219484" rel="nofollow">http://www.apress.com/us/book/9781430219484</a>
I once had an online discussion about the difference between competitive programmers and professional programmers, and which were better. Someone argued that competitive programmers were better, because they had to perform in more extreme circumstances. As he put it: they were sent into the forest with a knife to kill a lion.<p>Everybody else ran with that metaphor. Someone asked what a lion was doing in a forest; don't they live on the savannah? I asked whether he was sure there was a lion; plenty of times I've been sent to kill a lion and ended up having to kill a goat or an elephant instead. Are we even sure it needs killing?<p>I think that's the difference between a competitive programmer and a professional programmer. The competitive programmer will be much faster with a solution to the given problem, but the professional programmer will solve a better problem.
I have had a bad experience with an algorthmic topcoder.<p>The guy has a brilliant mind. But he doesn't understand the big picture or why his code would fail when integrated with big codebases.<p>He thinks his work is "done" when he has written his tiny little code with some queues and trees. Then he leaves it for someone else to integrate and thus really solve the problem.<p>The best engineers I found were the ones who took ownership of their projects and had the ethic to dig deep. Not the ones who could solve toy algo problems.
Here's a list of companies that don't do this <a href="https://github.com/poteto/hiring-without-whiteboards" rel="nofollow">https://github.com/poteto/hiring-without-whiteboards</a> I hope it's the beginning of an industry wide trend away from these types of interviews.
Look at programming competitions from an assessment perspective: what are they measuring and is what's being measured good or bad for a job?<p>Ability to work under short time constraints (probably good), to hack out some solution that will work temporarily (good) but probably not solid (bad), to forego much time to consider the implications of design and implementation choices (bad), to develop without communication if solo competition (bad) or without communication outside of the small group of core developers (bad), to build a solution without getting feedback and refinements from stakeholders (bad), and so on.
People who enter programming competitions are looking for some sort of glory: to be stars. When they don't get it from the job, they get bored.<p>I suspect that the people good at programming competitions could easily perform well on the job, if the motivation were there. I don't think it necessarily has anything to do with short-term versus long-term problem-solving focus.<p>There are plenty of short-term problems that you have to solve on the job to be effective. You're not doing them in competition against anyone such that if you procrastinate, you will lose, so the motivation vaporizes.<p>Also, since job interviews are like programming competitions, people who are good at programming competitions figure they can easily get a job anywhere, and to do that repeatedly. They are not motivated into working hard by job security concerns.
I would tend to agree, and while I was never very good at programming competitions, when I saw some of the winning code on Topcoder, I somehow lost interest. If that's the code I would write if I learned to be better at competing, then I should rather spend time learning something else.<p>On the other hand, something like Project Euler or even Advent of Code is very nice, if you do it at your own pace, or for learning a new language.
I haven't done a code competition before but my understanding is that code competitions reward cowboy coding over good engineering practice, i.e. implementing features while paying no heed to maintainability.<p>When you have that mind set and start dealing with a codebase as monstrous as Google's it sounds like a recipe for some serious technical debt.
It continues to surprise and frustrate me that as an industry we continue to highly prize proxy signals for engineering skill, when engineering skill is so directly measurable.<p>Why even bother with measuring things that are N-degrees removed from actual engineering, when you can just get people to engineer things?<p>I know others on HN have been hammering this point home for years, but until something changes it deserves to be repeated ad nauseum: work samples work samples work samples work samples.<p>Stop with the trivia questions. Stop with the contrived algorithms questions. Ask people to design systems, ask people to defend their designs, ask people to write real runnable code that directly relates to the work they will be doing at your job, ask people to review a real piece of code written at your company, ask people to critique real design produced at your company. Anything but what we're doing right now.
As a long-time interviewer, I've learned that a candidate being good at programming competitions means that they're probably good at programming competitions.<p>It's a weak signal either way for success or failure at interviewing and being able to do the job. Part of the problem, as we've discussed on HN so often recently, is that a programming interview has to waste time with FizzBuzz-style questions just to flag the candidates with great resumes, transcripts, and phone screenings who still actually can't program a computer to solve even a trivial problem.
Here are some of the positive qualities I would expect from a competitive programmer compared to the general CS population <i>early in their career</i>:<p>- knowledgeable at algorithms and data structures<p>- good at analyzing correctness and edge cases, even on simple non-algorithmic problems (e.g. FizzBuzz)<p>- accustomed to working hard and learning new concepts. this attribute is not specific to competitive programmer – for example, I'd expect similarly from an open source contributor – but it's higher than for a typical college student.<p>Some negatives I'd expect, which are fixable over the course of the course of their career:<p>- over-confidence in code, under-testing<p>- less skilled in OOP, coding style, version control systems, as well as web development or systems code (unless they have specific previous work in these areas)<p>- sometimes looking down on gruntwork/rote as beneath them (like the view that pure mathematicians have towards applied math or statistics)<p>I think that list of positive attributes often outweighs the potential negatives, especially during an internship or in the first year or two of someone's career. After that, I would expect many non-competitive programmers to have picked up on some of those advantages (code correctness, learning new concepts).<p>I've tried to steer my own interviews away from algorithms (especially DP) and focusing more on giving problems that are relatively straightforward, while still being complicated enough that someone has to write precise code and identify/fix a few edge cases.
Adding to the good points here, I think coding competitions superstars are also potentially more likely to have a diva-complex, while others are more likely to have an impostor complex when they get into a company like Google. The right amount of impostor complex (where it enables you but does not cripple you) is actually very helpful as it helps you learn and better yourself.
Question?<p>Does being good at programming competitions make you good at interviewing for programming jobs?<p>Obviously there's some irony in that question. But I also think there's some truth to it as well.
Also important to remember that good at programming does not necessarily equal good at job.<p>Excelling as a communicator, being an empathetic person, and having great interpersonal skills are just as (perhaps more) important than how well you can code.
<a href="http://ruberik.blogspot.com/2017/07/no-programming-competitions-dont.html" rel="nofollow">http://ruberik.blogspot.com/2017/07/no-programming-competiti...</a><p>It looks like it wasn't "being good at programming competitions" that was negatively correlated with job performance.<p>It was "participated in programming competitions".<p>And there are some more "how to interpret machine learning models" caveats in that blog post.<p>It seems to me the biggest factor in explaining this is that the people who are just below the hiring line but participate in competitions get a bump over the line. Since there are more people just below the line than above it, the "participates" group is bottom-heavy, producing the correlation.<p>I do a lot of interviews, and it seems to me that lots of people with experience perform below how they "should", because they're not practiced at solving problems from scratch, they work all day on modifying larger systems. Programming competitions would fix that for them, as would most open-source hobby projects.
I don't find this surprising. I played around on Top Coder enough to reach the first division but the problems presented were in no way related to my day to day work. While the people that did very well (I never got anywhere once I hit the top grade) might have had an excellent command of very specific data structures and techniques, non of the code would have been very useful in the real world.<p>If I was interviewing someone, a career as a competitive programmer would not be a detriment but it would not count for very much overall. We are looking for creative thinkers that can work as a team.
The market is pretty good at sorting this out and I'm sure programming competition winners are fairly valued. I've seen more Berkeley, Stanford, MIT, CMU and IIT degrees rise to the top than other schools. I haven't seen any <i>top coders</i>. Maybe they're there and I haven't noticed. But I haven't seen them on resumes that I've culled through.<p>It's probably something you might list on a first job resume but further on down the road, you'd just list your work and your education.
All job interviews rely on proxies for whether someone will be good on the job or not, because the only way to know is to actually hire them.<p>All proxies are inaccurate.
My viewpoint is taken from the context as someone who is a reasonably seasoned developer returning to the job market. I never did programming competitions in university, though I surely was someone who fit the profile (computer science guy with a discrete math bent). As part of my recent prep for a job search, I joined one of the programming competition websites and did a couple of contests.<p>I posit that one of the dangers of spending a lot of time doing programming competitions and becoming very proficient at them is that, perhaps, you can come to believe that "true" programming, some sort of Platonic ideal of programming, is about coming up with the clever insight that solves an algorithmic puzzle.<p>But, in fact, a fair bit of _commercial_ programming is down and dirty, with databases, and user interfaces, and a lot of the time is really just shuffling data from one place to another, maybe filtering it or combining it with another set of data.<p>And that's just at the beginning of your career. Later on in your career, success means being able to work at larger scales in a team. That means organizing the code in a way that supports the efficient development of the codebase by individuals like yourself, by your team, by the development group as a whole... And at the architect level, you perhaps are looking at designing the system to support the efficient operation of the entire organization.<p>So I can easily believe that success at a programming competition does not correlate with long-term success as a software engineer in commercial software development. The two are really very different.<p>(Btw, I actually found the competitions that I did to be fun, but mentally exhausting. I'd say go ahead and do them, especially if you have an inclination for those types of problems. Just be prepared to use a different mindset for commercial software development.)
I see a lot of comments speculating that there may be something wrong with programming competition winners, but this result might be a statistical curiousity unique to Google. It's possible that for most companies, good at programming competitions could still be positively correlated with job performance. For example, what if most people whom Google hires could have won some programming competitions if they had wanted to (a situation that most other companies are probably not in)? In this case, 'won programming competitions' could be data that is a lousy filter for Google, yet a good filter for other companies.
Completely agree with Peter. I'm shit at those competitions (maybe not the worst ever) but I think I'm pretty good at my job. But I think there are also some who are good at both.
In general, I think there are a lot of things like whiteboard interviews and coding competitions where employers would <i>prefer</i> "good at X means good on the job", but are reasonably happy to settle for "bad at X means bad on the job."
When I am interviewing:<p>Candidate having competed in programming competitions - big green flag.<p>But, if success in competitions is, in their view, their biggest asset - amber flag.<p>I would extend this to most competitive endeavours.
well if you're not good at programming contests would that entail a contemplating/slow programmer?<p>I'd rather pick an algorithmist and teach him/her to reflect than a so called "reflectionist" / "slow coder" and teach him/her how to solve algorithmic problems.<p>I'd be interested in knowing the guy's (catonmat) own reflections and experiences too.
The title of the post understates the claim in the link, which is that, "being good at programming competitions correlates negatively with being good on the job".
They are two types of business, first type business to business, software made to run internal in a company, the business run on this software, generally in this kind of software you use enterprise frameworks, the second type are business to consumer where anyone can made an account and use application, some software as a service are like that, they are too other types of web applications business to consumer.<p>When you allow that anyone to make an account and use your application sometimes you couldn't rely on enterprise technology and it's better to write everything from scratch or to customize open source solutions.<p>What they are testing in algorithms contests:
1.) the algorithm is correct with various test sets
2.) the performance of the algorithm, running time in milliseconds, there you should to know how to measure time complexity of algorithm with O(N)
3.) memory consumed, there you should know how much memory you are allocating for variables, for example a variable of type byte consume 8 bits<p>I think that programmers which has prizes in algorithms contests are suitable for business to consumer applications because there they will find a challenge, this kind of programmers will be bored to dig in enterprise frameworks.