5 ms·

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 awkw

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

lordnacho 9y ago
Aren't contests normally under huge time pressure? I would think that a lot of people could solve even quite hard problems given ordinary conditions like having lots of time, colleagues, and reference materials available.
- jmcgough 9y ago
  At the same time, if you've never seen a solution that uses something like DP, you're not going to see a DP problem and think "oh, I can use DP for this". Part of it is ensuring that programmers have awareness of the tools at their disposal, so they can pull them out when they're under a deadline to get something done on time that's performant
joenot443 9y ago
I agree for the most part, but I think it really depends on the product your team is building. I can think of at least a couple companies I've worked at where the hard algorithms weren't rare, they were actually non-existent. The product's success relied on user experience, a solid design, and exhaustively tested and maintained code. The reality with many companies these days is that the algorithmically hard problems are solved in the frameworks and libraries they use, it's simply not necessary for most engineers to understand their inner workings. I'm curious, would you prefer an engineer with solid software engineering and design knowledge, or one with minimal experience building real software, but very in-depth algorithm and CS theory knowledge?
- fatjokes 9y ago
  > I agree for the most part, but I think it really depends on the product your team is building. I completely agree. However, 1) Google---whose CTO is the originator of the claim in discussion---definitely works on hard algorithms and 2) you never know how your product could grow. A feature which could get dismissed as "impossible" might be implementable by the right talent. Presumably these teams don't need to be full of top algorithm folks. > I'm curious, would you prefer an engineer with solid software engineering and design knowledge, or one with minimal experience building real software, but very in-depth algorithm and CS theory knowledge? Depends on the size of my team and what I'm trying to deliver, I suppose. In general I'd aim for a balance in the team, maybe 3/4 engineering/design + 1/4 algorithms. I feel like it's easier to learn design patterns than how to use algorithms creatively.
  - sltkr 9y ago
    > 1) Google [..] definitely works on hard algorithms True, but Google also has over 20,000 engineers working on various things. I think only a tiny minority of those are actually working on hard algorithms.
    - fatjokes 9y ago
      Exactly. They don't just hire programming contest folk. Most of the people they hire are those with engineering experience, etc.
    - jaggederest 9y ago
      It's like only hiring NASCAR drivers to drive taxis because "they might need to go fast".
      - BatFastard 9y ago
        Indeed, for Taxi drivers its better if they go slower and entertain the guests along the way. I have had top algorithm people work for me and they can do make magic happen. But they tend to have the quirky personalities of Wizards. I once had a amazing code ask me if he could so some side work so that he could pay off his credit cards, sure no problem. Next week he came back and told me how he had bought a new 10k telescope....
raverbashing 9y ago
But as much as you need a good algorithm, you need it to be testable, reliable and predictable This involves some team work
pera 9y ago
It depends on what position are you trying to fill: if your business have various hard and general algorithmic problems that you need someone to solve then, hiring an ICPC regional champion would probably be a good thing. But this is not always the case... I wouldn't hire an Olympic medalist runner to do pizza delivery because: 1) the person will probably get really bored (and may quit or perform bad after some time), and 2) the delivered pizzas will probably be a mess inside the box. I believe programming competitions would do itself a favor changing its currently ambiguous name to algorithmic competitions. Then engineers, who are also programmers, would be ok with it and we would stop having this kind of threads every few weeks. That being said, I personally enjoy competitive programming and I do agree that the knowledge you acquire is invaluable :) and I also think that most engineers should practice with online judges now and then to be better at their jobs.
- pizza234 9y ago
  > I wouldn't hire an Olympic medalist runner to do pizza delivery because: 1) the person will probably get really bored (and may quit or perform bad after some time) I think it's a bit more complicated than that. What if Olympic medalists were conditioned to think that delivering pizza is the coolest job that exists? What if their scooters have massaging saddles and 5.1 hifis? I definitely agree this market (segment) has, in a way, a very misled attitude/approach, but definitely, I think there is an (evil) art in marketing such workplaces.
hrktb 9y ago
To add on point 2), most big companies have a strong bias against 'smart' solutions. If something is too complex to be fully understood by half the engineers: a) it won't be trusted b) it won't be maintainable by any random staff, which puts an additional risk on choosing that solution. The maintainability argument will usually be enough to can any idea that only few people are comfortable to make evolve.
- collyw 9y ago
  The interview process would indicate the opposite.
  - hrktb 9y ago
    To be honest I think a lot of company representatives (CTO, hiring managers...) don't acurately understand or voice what they really need. A lot of them say to want 'A players', but the organization is not ready to value people willing to rock the boat, deeply challenge assumptions or willing to put higher people under scrutiny over their decisions. Same with hiring super smart people but not wanting to commit to risky bets or to fail often. In these companies the most demanding people come and go, and more lenient people ('B players' ?) stay to work within the system or try to make things better more incrementally.
_0ffh 9y ago
> Vast majority of engineering work is very algorithmically simple anecdotal_evidence+=1 : Am engineer, only algorithmically interesting task I had the last three months was to quickly find all minimal solutions of a given instance of a certain class of constraint graph problems. That's about average, at my job. Four algorithmically interesting things a year. And I guess I might even be one of the luckier engineers.
- 0xfeba 9y ago
  I just match APIs up 60% of my time. 20% in 75% useless meetings. And another 20% yak shaving.
- kwillets 9y ago
  While these problems don't come up frequently, I've found that in a typical project anything involving a graph has a good chance of being implemented wrong.
YZF 9y ago
I used to spend some time on TopCoder and got to be fairly good but not at the top "red" level... There is some transfer to improved code quality but I think it's generally not something that made a huge difference to what I do as a developer. There are plenty of people who can do really hard algorithms but may need more time or research. Real life doesn't always present you with the same canned problems that are used in competition and you're not operating under the same constraint. A competition problem typically starts from an algorithm, somewhat like a comp-sci exam question. As a competitor you need to quickly recognize the algorithm and then quickly write an implementation. I'm sure a lot of the best competitive people would draw a blank when presented with a problem that isn't a well known algorithm and certainly wouldn't be able to solve it within the time constraints. Basically it's a game. What I'd say is that outstanding performance in programming competition probably correlated to some degree with intelligence. Intelligence correlates to some degree with being a good software developer.
eastWestMath 9y ago
Companies don't have 2 hour time limits on solving their hard problems - if you run into hard algorithmic problems in your problem domain, you should just have someone with a graduate degree in CS theory. Let them work out a solution that's actually correct and they can explain why, and then the engineers can implement said algorithm.
richardknop 9y ago
This is probably true. I agree. I would aim for balanced teams, some top ICPC performers balanced with people who are better at solid design, creating maintainable codebase and working with business people to define requirements.
curiousDog 9y ago
I would disagree that they'd be better at solving hard algorithms as well. The hard algorithms are being solved at the top theory groups at the top 10 schools. I did a bit of programming contests in school as well and most kids practiced hard and got good at the tricks and patterns of solving those problems. The algorithms were mostly undergrad or grad level at best. They were not breaking new ground. As to whether top ICPC talent correlates to IQ and capability, Most likely, although the same can be said about a really high GPA though. People like Tomek Czajka will shine in all areas. I've worked at a couple of the Big-4 companies before and the best programmers I met there were not competitive programmers.
derf_ 9y ago
I am also an ACM ICPC finalist (our team was 2nd in the world, 1st in North America in my final year of eligibility). I think there are a few very specific skills you learn in programming contests that are useful in the real world: 1) Once you understand the problem to be solved, you can simply sit down and write the code to solve it. The ability to turn ideas into code in minutes instead of hours or days is invaluable. It lets you try lots of ideas, because the implementation step is easy. You can pick the ones that work and throw the rest away, and you don't mind throwing them away because they weren't a big investment. You don't realize how useful this is until you start meeting people who can't do it. Our coach always told us that there is at least one easy problem, and someone's job the moment the contest starts is to identify it and bang it out. If we hadn't solved one problem in the first 20 minutes, we were already losing. 2) You learn to write code that is simple and correct the first time. Idioms that avoid special cases. Simple data structures ("No pointers!" was common advice, though of course reality was more subtle than that). Understanding when big-O complexity really matters, and when you can use a sub-optimal solution that's easier to code and reason about. Sure, someone who is smart can write crazy complex code that only they can understand. But crazy complex code doesn't win contests. If you make a mistake you will burn all of your time trying to figure out what you did wrong, and the worse the code is, the worse of a hole you will dig yourself into. Write simple code that doesn't leave much opportunity for mistakes. There's a scene in Jack Reacher where Tom Cruise's character says, "James Barr is a sniper. He's not the best. He's not the worst. But he trained non-stop for two years. What does training like that do? What does any training do? Skills become reflex, muscle memory, you do without thinking. It also makes people who aren't necessarily smart seem smart by beating some tactical awareness into them." That's what contest programming does. 3) You learn to identify your limits. There's usually (but not always) at least one problem you should just throw away as "too hard" for the time allotted. You won't solve it, so any time invested in it is a waste. In the real world, where you can't just decide not to do your job, that means you know the difference between when you can go fast and when you need to slow down and reflect. When you need to write a test to really know if the code you just wrote is correct. When it's better to step back and simplify the problem, rather than beat your head against it. Yes, people like to focus on the "hard algorithms", but really this is not what makes good contest programmers. People aren't deriving Ford-Fulkerson on the fly during a contest. They memorize a set of canned algorithms and apply them when necessary. You learn to recognize and value simple, robust solutions to problems. You carry a toolbox of these wherever you go. This toolbox keeps growing long after you stop competing, and it contains a lot more than fancy algorithms. Now, there is also plenty you don't learn doing contest programming that you still need to know in a real job. But these are the things I learned that have helped me. I'm still waiting for the day I need to compute the coefficients of a rook polynomial, though.

lordnacho 9y ago

Aren't contests normally under huge time pressure? I would think that a lot of people could solve even quite hard problems given ordinary conditions like having lots of time, colleagues, and reference materials available.

jmcgough 9y ago
At the same time, if you've never seen a solution that uses something like DP, you're not going to see a DP problem and think "oh, I can use DP for this". Part of it is ensuring that programmers have awareness of the tools at their disposal, so they can pull them out when they're under a deadline to get something done on time that's performant

joenot443 9y ago

I agree for the most part, but I think it really depends on the product your team is building. I can think of at least a couple companies I've worked at where the hard algorithms weren't rare, they were actually non-existent. The product's success relied on user experience, a solid design, and exhaustively tested and maintained code. The reality with many companies these days is that the algorithmically hard problems are solved in the frameworks and libraries they use, it's simply not necessary for most engineers to understand their inner workings. I'm curious, would you prefer an engineer with solid software engineering and design knowledge, or one with minimal experience building real software, but very in-depth algorithm and CS theory knowledge?

fatjokes 9y ago
> I agree for the most part, but I think it really depends on the product your team is building. I completely agree. However, 1) Google---whose CTO is the originator of the claim in discussion---definitely works on hard algorithms and 2) you never know how your product could grow. A feature which could get dismissed as "impossible" might be implementable by the right talent. Presumably these teams don't need to be full of top algorithm folks. > I'm curious, would you prefer an engineer with solid software engineering and design knowledge, or one with minimal experience building real software, but very in-depth algorithm and CS theory knowledge? Depends on the size of my team and what I'm trying to deliver, I suppose. In general I'd aim for a balance in the team, maybe 3/4 engineering/design + 1/4 algorithms. I feel like it's easier to learn design patterns than how to use algorithms creatively.
- sltkr 9y ago
  > 1) Google [..] definitely works on hard algorithms True, but Google also has over 20,000 engineers working on various things. I think only a tiny minority of those are actually working on hard algorithms.
  - fatjokes 9y ago
    Exactly. They don't just hire programming contest folk. Most of the people they hire are those with engineering experience, etc.
  - jaggederest 9y ago
    It's like only hiring NASCAR drivers to drive taxis because "they might need to go fast".
    - BatFastard 9y ago
      Indeed, for Taxi drivers its better if they go slower and entertain the guests along the way. I have had top algorithm people work for me and they can do make magic happen. But they tend to have the quirky personalities of Wizards. I once had a amazing code ask me if he could so some side work so that he could pay off his credit cards, sure no problem. Next week he came back and told me how he had bought a new 10k telescope....

raverbashing 9y ago

But as much as you need a good algorithm, you need it to be testable, reliable and predictable This involves some team work

pera 9y ago

It depends on what position are you trying to fill: if your business have various hard and general algorithmic problems that you need someone to solve then, hiring an ICPC regional champion would probably be a good thing. But this is not always the case... I wouldn't hire an Olympic medalist runner to do pizza delivery because: 1) the person will probably get really bored (and may quit or perform bad after some time), and 2) the delivered pizzas will probably be a mess inside the box. I believe programming competitions would do itself a favor changing its currently ambiguous name to algorithmic competitions. Then engineers, who are also programmers, would be ok with it and we would stop having this kind of threads every few weeks. That being said, I personally enjoy competitive programming and I do agree that the knowledge you acquire is invaluable :) and I also think that most engineers should practice with online judges now and then to be better at their jobs.

pizza234 9y ago
> I wouldn't hire an Olympic medalist runner to do pizza delivery because: 1) the person will probably get really bored (and may quit or perform bad after some time) I think it's a bit more complicated than that. What if Olympic medalists were conditioned to think that delivering pizza is the coolest job that exists? What if their scooters have massaging saddles and 5.1 hifis? I definitely agree this market (segment) has, in a way, a very misled attitude/approach, but definitely, I think there is an (evil) art in marketing such workplaces.

hrktb 9y ago

To add on point 2), most big companies have a strong bias against 'smart' solutions. If something is too complex to be fully understood by half the engineers: a) it won't be trusted b) it won't be maintainable by any random staff, which puts an additional risk on choosing that solution. The maintainability argument will usually be enough to can any idea that only few people are comfortable to make evolve.

collyw 9y ago
The interview process would indicate the opposite.
- hrktb 9y ago
  To be honest I think a lot of company representatives (CTO, hiring managers...) don't acurately understand or voice what they really need. A lot of them say to want 'A players', but the organization is not ready to value people willing to rock the boat, deeply challenge assumptions or willing to put higher people under scrutiny over their decisions. Same with hiring super smart people but not wanting to commit to risky bets or to fail often. In these companies the most demanding people come and go, and more lenient people ('B players' ?) stay to work within the system or try to make things better more incrementally.

_0ffh 9y ago

> Vast majority of engineering work is very algorithmically simple anecdotal_evidence+=1 : Am engineer, only algorithmically interesting task I had the last three months was to quickly find all minimal solutions of a given instance of a certain class of constraint graph problems. That's about average, at my job. Four algorithmically interesting things a year. And I guess I might even be one of the luckier engineers.

0xfeba 9y ago
I just match APIs up 60% of my time. 20% in 75% useless meetings. And another 20% yak shaving.
kwillets 9y ago
While these problems don't come up frequently, I've found that in a typical project anything involving a graph has a good chance of being implemented wrong.

YZF 9y ago

I used to spend some time on TopCoder and got to be fairly good but not at the top "red" level... There is some transfer to improved code quality but I think it's generally not something that made a huge difference to what I do as a developer. There are plenty of people who can do really hard algorithms but may need more time or research. Real life doesn't always present you with the same canned problems that are used in competition and you're not operating under the same constraint. A competition problem typically starts from an algorithm, somewhat like a comp-sci exam question. As a competitor you need to quickly recognize the algorithm and then quickly write an implementation. I'm sure a lot of the best competitive people would draw a blank when presented with a problem that isn't a well known algorithm and certainly wouldn't be able to solve it within the time constraints. Basically it's a game. What I'd say is that outstanding performance in programming competition probably correlated to some degree with intelligence. Intelligence correlates to some degree with being a good software developer.

eastWestMath 9y ago

Companies don't have 2 hour time limits on solving their hard problems - if you run into hard algorithmic problems in your problem domain, you should just have someone with a graduate degree in CS theory. Let them work out a solution that's actually correct and they can explain why, and then the engineers can implement said algorithm.

richardknop 9y ago

This is probably true. I agree. I would aim for balanced teams, some top ICPC performers balanced with people who are better at solid design, creating maintainable codebase and working with business people to define requirements.

curiousDog 9y ago

I would disagree that they'd be better at solving hard algorithms as well. The hard algorithms are being solved at the top theory groups at the top 10 schools. I did a bit of programming contests in school as well and most kids practiced hard and got good at the tricks and patterns of solving those problems. The algorithms were mostly undergrad or grad level at best. They were not breaking new ground. As to whether top ICPC talent correlates to IQ and capability, Most likely, although the same can be said about a really high GPA though. People like Tomek Czajka will shine in all areas. I've worked at a couple of the Big-4 companies before and the best programmers I met there were not competitive programmers.

derf_ 9y ago

I am also an ACM ICPC finalist (our team was 2nd in the world, 1st in North America in my final year of eligibility). I think there are a few very specific skills you learn in programming contests that are useful in the real world: 1) Once you understand the problem to be solved, you can simply sit down and write the code to solve it. The ability to turn ideas into code in minutes instead of hours or days is invaluable. It lets you try lots of ideas, because the implementation step is easy. You can pick the ones that work and throw the rest away, and you don't mind throwing them away because they weren't a big investment. You don't realize how useful this is until you start meeting people who can't do it. Our coach always told us that there is at least one easy problem, and someone's job the moment the contest starts is to identify it and bang it out. If we hadn't solved one problem in the first 20 minutes, we were already losing. 2) You learn to write code that is simple and correct the first time. Idioms that avoid special cases. Simple data structures ("No pointers!" was common advice, though of course reality was more subtle than that). Understanding when big-O complexity really matters, and when you can use a sub-optimal solution that's easier to code and reason about. Sure, someone who is smart can write crazy complex code that only they can understand. But crazy complex code doesn't win contests. If you make a mistake you will burn all of your time trying to figure out what you did wrong, and the worse the code is, the worse of a hole you will dig yourself into. Write simple code that doesn't leave much opportunity for mistakes. There's a scene in Jack Reacher where Tom Cruise's character says, "James Barr is a sniper. He's not the best. He's not the worst. But he trained non-stop for two years. What does training like that do? What does any training do? Skills become reflex, muscle memory, you do without thinking. It also makes people who aren't necessarily smart seem smart by beating some tactical awareness into them." That's what contest programming does. 3) You learn to identify your limits. There's usually (but not always) at least one problem you should just throw away as "too hard" for the time allotted. You won't solve it, so any time invested in it is a waste. In the real world, where you can't just decide not to do your job, that means you know the difference between when you can go fast and when you need to slow down and reflect. When you need to write a test to really know if the code you just wrote is correct. When it's better to step back and simplify the problem, rather than beat your head against it. Yes, people like to focus on the "hard algorithms", but really this is not what makes good contest programmers. People aren't deriving Ford-Fulkerson on the fly during a contest. They memorize a set of canned algorithms and apply them when necessary. You learn to recognize and value simple, robust solutions to problems. You carry a toolbox of these wherever you go. This toolbox keeps growing long after you stop competing, and it contains a lot more than fancy algorithms. Now, there is also plenty you don't learn doing contest programming that you still need to know in a real job. But these are the things I learned that have helped me. I'm still waiting for the day I need to compute the coefficients of a rook polynomial, though.