But no one mentioned those things, and the book doesn't seem to either. Why make this book about the crusade against Google's interviewing zeitgeist?
For what it's worth, I work with someone who used to be (is? I think he stopped competing) red on TopCoder. He's one of the best developers I've ever worked with. I don't know about the causation there, but his development process and skill is better than most of what I've seen in many other tech companies (I say this in the context of reviewing other companies' source code for errors and getting an understanding of what their respective SDLCs look like).
That's obviously a sample size of one, but I felt like saying it because I think you're really pushing it with your comment. It almost just seems like you have an axe to grind. I can agree that a good developer doesn't need to be adept at competitive programming, but it does help with understanding things like algorithms, data structures and time complexity.
I think you trying to claim that competitive programming has "nothing to do with getting a better job" is just as egregious as people who only hire engineers that can produce impeccable red-black trees on a whiteboard with little preparation.
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.
I hadn't heard of "competitive programming" before, and at first assumed this was a post exactly about "getting a better job or a better salary" (the most likely alternative interpretation).
So I was grateful for the clarification, and didn't take it as algorithm-hate.
Doing + training for local & ACM programming competitions was easily as valuable for me as the CS classes I took in college. (It helped that our coach was the awesome Eugene Luks.)
There's a lot more than just the core problem solving bits involved in making software, but it's a v. useful skill.
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.
In the sense of "this article has nothing to do with jobs or salaries," I would rate the claim true. The article has not one mention of either.
If you're trying to argue that improving your skillset makes you more employable, sure, but that's such a general statement that I'm not sure it holds up as a retort.
Sure, and I think the comment he replied to means "the term competitive is ambiguous, let me clear it up: this is not talking about advancing your career."
I guess, to the degree that you would assume "competitive programming" could be interpreted as something specifically to advance your career, which I know I didn't, and I'm not sure how you could (but I could easily be missing a common different interpretation).
That is, I wouldn't assume "A Competitive Fisher's Handbook" would apply to my career as a bulk tuna fisherman, and I would find a comment that points out that there is nothing related between the two as as both obvious (colloquially), and overreaching (specifically) to the point I might feel the need to counter-correct as there very well might be links between them that could help in non-obvious ways. That competitive programming and interviews share more than superficial similarities might make me even more likely to do so.
Sadly the proliferation of sites like HackerRank (YC funded shamefully) means competitive programming is the first "filter" stage for interviews these days.
I'd love it if there were more opportunities from companies like HackerRank. It's other "filters" that I'm worried about; companies that filter out degree-less candidates, companies that filter out depressed candidates, companies that filter out transgender candidates, etc.
First, I should warn you that I'm no expert! I'm not the most informed or up-to-date about discrimination in hiring. However, I'll try to provide some helpful links.
First, depression. The correlation between unemployment and depression has been studied since at least the 1980's. One issue that has been considered but never completely explained is the "direction of causality." In other words, does unemployment cause depression, or are depressed people more likely to be left unemployed? Some articles suggest the former, while others suggest the latter; it may well be that both are true. From what I've seen, much of the research focuses on the impact of unemployment on mental health. Here's a Forbes article which is a bit more approachable:
There are probably better sources out there, but as I said, I'm no expert and I'm not up-to-date on the research!
There are several challenges facing research into the relationship between unemployment and depression. For one thing, depression can have a number of other causes, and associated risk factors. It can be hard to pick apart the causes from employment status. Another issue is gathering data. Many companies here in the US will ask for voluntary self-identification when a candidate applies; often, however, depression is considered to be in the same category as other disabilities so that it's impossible to pick apart the rate of depression among candidates from the rate of disability among candidates. Another issue that applicants may decline to self-identify. Some companies are better than others at gathering data about depression among workers, and trying to help those employees.
Next, transgender. Here, the research is less well-developed. The transgender population is rather small, so data-gathering hasn't been a high priority until recently. Most data comes from survey of transgender individuals rather than from employers. There may be some inherent bias as a result, but at the moment it's really the best data we have. I'll point you to the National Transgender Discrimination Survey, which was released in 2016 based on data gathered in 2015:
The report is rather long, but it had several important findings: 1) Transgender employees have double the rate of unemployment as the average. 2) 26% reported being fired due to their gender identity. 3) 90% reported harassment at work. 4) The effects compounded with other factors such as race or poverty.
It's worth noting that many states in the US offer no or few protections against LGBT employment discrimination. Here's a map to show how protections differ across states:
I won't touch the degree issue; it's been discussed plenty elsewhere on hacker news, and there's still the mentality that candidates with degrees are better than candidates without.
Would you say that there is no discrimination along these lines, and that most companies aren't biased against, say, transgender candidates when making hiring decisions? I'm just curious.
I've no doubt that tech is discriminatory - as a minority myself I've definitely experienced odd feedback at interviews "the team were impressed by your abilities but we've decided to proceed with someone else" etc. I just mean to compare rejecting degree-less candidates is not equivalent to discrimination against "non-fit" groups (gender, ethnic, sexuality minorities) as a degree is a technical qualification and not a protected characteristic.
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.
So your ability in a pressured limited-time environment come up with an O(N) dynamic programming algorithm for a fictitious scenario is a testament to your ability as a software engineer versus a competitive programmer who can pattern match scenarios?
But algo questions are usually just part of the interview, not the whole thing. And usually they are fairly simple, so every good software engineer should be able to solve them.
I can do well enough on programming challenges at a place like HackerRank. However, I very rarely actually get to the technical interview in a job application; most commonly, I apply and don't hear back from the company. So as far as I'm concerned, I need better something but that something isn't better skills.
I wish this was true. If you are good at competitive programming, it is more than likely that you will be good on the whiteboard interview questions for a software developer position.
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 interested in this book as it's a remarkably concise list of related things to learn.
I read you. It's funny how it blocked a couple of jobs, and it only took me a few hours to learn enough to pass the basics. I understand the need to filter, but still believe it's a crappy way of doing it.
I wouldn't say he considers it a negative signal considering how he said if he had to pick someone off the street he would prefer the one who is good at programming competitions.
However if you are above the bar required to get hired by google, then a higher success rate in programming competitions correlates negatively with job performance.
I suspect this is because if someone is hired, they were necessarily good at solving Google's interview questions, which are very similar to (easy) competitive programming questions. The fact that someone is good at competitive programming doesn't give you much further information since you already tested for that ability during the interview, and in fact may indicate that this person is spending energy studying competitive programming that they could otherwise be spending accomplishing stuff at work.
I had been practicing competitive programming questions for several months the last time I was out interviewing for a new job, they're very relevant for both of those insofar as they help you pass interviews...
Especially given the importance of teamwork. Competitive people tend towards tedious one-upmanship. It's something you want to screen out in the hiring process.
Programmers participate to ICPC in teams of three. According to my experiences, teamwork is a fairly important part of success since there is only one computer for each team.
I had to compete for my job, in which I get to spend a lot of time working relatively unconstrained on scientific problems of my choosing, as long as they're quite broadly mission-oriented. I like working on questions no one else is asking and avoiding the 'a large debate exists in the community as to whether X or Y' messes that Nature loves to publish.
I had to compete for my wife, who supports me and inspires me and etc. me, with few constraints (such as no others compete for our affections).
I hate games of all sorts (they have rules and the fun is to remember them and play by them?). But nonetheless I realize:
Elon Musk and Steve Jobs never spent time responding to competitors. VC funding is another example. Fundable companies are so rare that VCs never sit around debating whether to fund company A vs company B, it's two separate decisions.
It sounds like what you treasure most about your job is that you're released from competing. Finding a relationship is about fit, and a good relationship is about the investment you make. I've never seen competing to work in any phase of a relationship.
For what it's worth, I work with someone who used to be (is? I think he stopped competing) red on TopCoder. He's one of the best developers I've ever worked with. I don't know about the causation there, but his development process and skill is better than most of what I've seen in many other tech companies (I say this in the context of reviewing other companies' source code for errors and getting an understanding of what their respective SDLCs look like).
That's obviously a sample size of one, but I felt like saying it because I think you're really pushing it with your comment. It almost just seems like you have an axe to grind. I can agree that a good developer doesn't need to be adept at competitive programming, but it does help with understanding things like algorithms, data structures and time complexity.
I think you trying to claim that competitive programming has "nothing to do with getting a better job" is just as egregious as people who only hire engineers that can produce impeccable red-black trees on a whiteboard with little preparation.