No, the most useful impacts of competitive programming has to do with actually teaching you how to program effectively. The most important advice I got for competitive programming was walk away from the computer. The biggest trap when programming is to write code before you know how to solve a problem, as this will tend to encourage you to spend all of your time making no progress towards actually getting a solution. The tale of the Sudoku solver [1] is salutatory here.
Another useful skill is how to debug algorithms. Debugging a competitive programming problem usually amounts to taking an input that fails and trying to understand where in the algorithm (as expressed in poorly written and commented code!) the mistake is. Doing so under the time pressures of a competition also requires being able to rapidly decide if the algorithm is wrong, or it is the implementation is wrong, as well as figuring out where the most likely places for errors are likely to creep in. This kind of experience translates very usefully into professional programming, and debugging is a skill that seems to be poorly acquired by most young programmers.
When competitive programming hits the tier where you need to memorize all of the advanced data structures and algorithms to do better, that's where further improvement in the leaderboards no longer translates to better programmers IMHO. But there's still a lot of skills that need to be acquired to move up competitive leaderboards before you reach that point.
[1] https://ravimohan.blogspot.com/2007/04/learning-from-sudoku-...
It will teach you bad practices, like abusing of dangerous programming constructs or data structures to optimized the code or just save some typing while writing the code (like one letter variable names, macros, etc), global variables and state in the program, not using common design patterns, not using OOP, not documenting the code and in general writing code that is difficult to maintain because it's not well engineered. You would say that a person would do that only in competition, but in my experience I saw that is not true, because if you learn to program a particular way, you would do the same also in other contexts.
Also, the competences that you will acquire by doing competitive programming are next than useless: in the real life I've yet to encounter a situation in which I have to use an algorithm used in a competitive programming competition (yes, I did them with even good results). And if you need them, you don't implement them yourself, but you use a library that manages all the work. The Dijkstra implementation that most competitive programmers use is a toy implementation, not something that you would never use in any sort of enterprise software.
The fundamental skill that competitive programming doesn't teach you, that to me is the most important thing for a good software engineer, is using Google to find documentation online. Most of the errors I see by young software engineers could easily been prevented if they did a simple Google search and read the official documentation (not a random blog post)! And yet in competitive programming you are forbid to use the internet, to me it's stupid, it's like requiring to write code with a typewriter just because in the past keyboards and monitors didn't exist.
If someone can't weigh up the pros and cons before using a particular technique, they're going to be a bad software engineer anyway. The field is all about making the right tradeoffs in particular situations, and blindly following current generalised "best" practices without really understanding what they're meant to be better than is going to get you into trouble too.
Breadth of knowledge and experience is a great thing. If you follow from the start that OOP is the right and only way to do things for example, you're not going to have a feel for when it gets in the way. Actually knowing what it's like and what happens when you do something the "bad" way is very valuable experience too e.g. you're going to be a better coder if you'd had to battle with buffer overflows and memory leaks in C in the past even if now you only use Java and Python.
This kind of logic really bugged me after moving from academia into industry. In academia for example, it's usually the right choice to make quick and dirty prototypes to get the results you need for a paper and not burn time over-engineering it. This doesn't mean I don't how to clean up code. I would also say it gives me more experience on avoiding over-engineering compared to someone that tries to copy best practices all the time.
These are not “bad practices”. Many of them are bad in certain common contexts, but literally none of them are bad in throw-away code used in the course of root-cause-analysis of problems in other code basis, and most are useful in many parts of proof of concept code. In working on production systems, most of the volume of code I produce isn’t production code, and has a very different set of constraints than production code.
And given history on HN, whether “not using OOP” is ever a “bad practice” is probably a whole discussion of its own.
There is not proof of concept code to me. Every line of code that I write professionally I write it to the higher standards. That doesn't mean over engineering it, but it means writing it in a way that is maintainable and understandable by others. I can compromise on functionality, of course in a proof of concept I implement only the things that I need, but not on code quality.
Even if I have to write a script that I know it will have to be used once and never again I will write it in a good way, you never know if you need it again, if a coworker does need to do a similar thing and you can just give to him as reference, or if you can take pieces to do other things.
on the otherhand, they can also encourage messy and hard to maintain code, or super efficient implementation can be brittle which you dont want in production unless there is a really really good reason...
if "competitive coding" also judge on other criteria such as clarity, readability and maintainability, in addition to efficiency and "correctness" that would be great imo
I don't think it's reasonable to use a library for most things one implements in competitive programming, because the work of getting your problem instance in and out of the library is probably greater than the work of writing the solution yourself, in code length and in runtime. As an example, the only time I ever needed to use A* was on a state space that was larger than the main memory of any computer on Earth. I don't expect that I can download a library that does A* on abstract state spaces not fully present in RAM for me, but I can just bash out my own A* that's fused with the definition of the state space. Maybe this is so easy to do partially because I did a bunch of programming contests in which I wrote BFSes that were fused with the definitions of graphs.
I'm sure this does exist! A functional library where you pass in, not a pointer to the set of all nodes, but some functions to get the node with the current lowest distance and to update the distance of a node.
Not saying it was the right thing for your use case, but don't rule it out. Even in languages that aren't strongly FP - eg it happens a lot in Go due to the lack of generics, and if you squint, the C++ STL is kind of like this.
Agreed, everything that makes good contest code is a bad thing for production code. In a contest you just want to hack together something as quickly as possible, it only needs to work once, will never be maintained or documented.
It's all good fun as a sport, but nobody should consider it relevant to working on production code.
Developers who have no interest towards algorithms will not even have the skills required to identify opportunities where algorithms should be used, much less the skills required to identify which algorithm should be used. For example, I had a conversation here on HN a few weeks back where somebody said that they will not need to learn anything about sort algorithms, because they can just google bubble sort and copypaste it if they need sorting at work. And that's how you end up with 5-minute load times for GTA.
In this example, the missing skillset is not memorizing a book of algorithms as you seem to imply.
If performance isn't good for the use case, they should be profiling the code for root causes. Which will lead them to identifying the sort operation as a problem. At which point they can search for faster sorting algorithms which will quickly lead them to a better solution and libraries containing them (or even how to implement, if they're operating in a constrained environment where no libraries exist).
I don't want to hire software engineers who have memorized the algorithm book, that's not useful to me. I want to hire those who can apply discipline to the work, such as (in this example) be aware of performance and know how to analyze it and find solutions.
No it's not. As I said in the sibling comment, competitive programming (or algorithm skills in general) isn't about memorizing algorithms, it's about developing skills that allow you to understand and create algorithms to solve problems. In this case, it would be sufficient to understand why looking up a phone number in a phone book should inherently be a O(log n) operation, not a O(n) operation.
> I don't want to hire software engineers who have memorized the algorithm book, that's not useful to me. I want to hire those who can apply discipline to the work, such as (in this example) be aware of performance and know how to analyze it and find solutions.
So we're discussing a hypothetical developer who has "no interest towards algorithms", and you're imagining that this person is going to run a profiler to troubleshoot a performance issue and subsequently optimize algorithms to fix said performance issue? This sounds like a fantasy to me. If you want skilled software engineers who have the ability to troubleshoot and optimize algorithms, you probably need someone who has some kind of interest towards algorithms.
was it actually the reason?
It was fairly simple to get significant performance gains (without changing AI behavior or results) just by applying straight forward changes. Eliminating macro's hiding chained method calls. Saving the result of nested calls, e.g. save a pointer to the game map instead of making the same call repeatedly in a tight loop.
There's a huge difference between "premature optimization" and just sloppy coding. Too many take the idea too far that the (C++) optimizer is better than you'll ever be and that you should let it do it's job. Yes, the optimizer is/can be very good and can make surprising and unintuitive changes to make code faster. But, it's not a miracle worker. Optimizers work best on clear, concise, code with minimal data dependencies.
FWIW, back on my Core I2 Duo, a single late-game turn on a huge map could take upwards of 30 minutes to complete, most of that spent in AI's turns. I was able to get it down to about 5 minutes without too much effort. Along the way, RAM usage also plummeted. If I had full access to the source, I could have made even greater gains that would have broken the DLL ABI...
Sadly, I never released my changes anywhere (and I only had local SVN at the time), and they haven't survived my PC upgrades since.
There was an article [0] and subsequent discussion on HN [1] about reverse engineering and patching the binaries.
[0] https://nee.lv/2021/02/28/How-I-cut-GTA-Online-loading-times...
tl:dr; O(n^2) string parsing and O(n^2) duplicate removal
I found this post [1] by the current rank 5 competitive programmer on codeforces to be an interesting take on this perspective. It's not as much about knowing the fancy algorithms, as being able to derive their ideas when needed, that makes you really move up.
That's not the point of competitive programming. If you talk to anybody who is good at competitive programming, they will tell you it's _not_ about memorizing algorithms and datastructures. It's about developing algorithmic problem solving skills; skills that you can leverage to design (create) algorithms, in order to solve problems.
Yes, they had also algorithmic problem solving skills. But they learned huge amount of algorithms and datastructures so that they don't have to derive them each time. And they spend time literally training how to write them fast without mistake.
It was not just about problem solving skills. It was a lot about knowledge base.
You can read one moderate length book and know all of the DSes and algorithms you'll need for 99.9% of the time. cses.fi/book is a good one with a free version if you're curious.
https://github.com/kth-competitive-programming/kactl may also be of interest, it contains a good amount of the algorithms/DSes you'd ever need on a few printable pages (20ish).
I can't really recall any scenarios where a stdlib datastructure was slightly too slow, but re-implementing your own version was just fast enough to get by. The problems were typically created in a way where using any common algorithm was 1000x too slow, and you needed something like dynamic programming to make things run in a reasonable amount of time. Or they were a math problem masquerading as a programming problem.
> Competitive programming is a good tool for building the programming muscle. An extreme pursuit of competitive programming is worse than useless.
This undercuts your claim a bit as someone has to be able to write the library in the first place. Yes it’s rare, but the software engineering industry is big enough that “rare” can be a “this happens all the time in domain X”.
Overall though I’d agree that it’s not useful for the majority of engineers and isn’t a good judge of programming ability just like math competitions aren’t either. They are “something” though.
It’s not often that you’re writing such code “in anger”, under time-pressure to ship to fix downtime, with no time to get peer review.
This is in large part because the downstream client of an algorithms/data structures library, would almost-always prefer a robust but less-efficient option, over an alpha-quality implementation of a more-efficient option. Dataset-size scaling challenges that recommend algorithmic efficiency increases can, almost always, be temporarily put off by “throwing machines at the problem” until the more-efficient library becomes high-quality enough to be fully relied upon. Until then, the business logic will make do with the simpler/more naive algorithm.
And in most language runtimes, there’s a simpler/more naive algorithm or data structure to solve every problem already laying around in the core stdlib; so it’s not like you, as the library writer, have to implement that code “in anger” either. Your internal customers can upgrade from depending on stdlib types, to depending on your lib’s types, when using your lib becomes an unalloyed win for them; and until then, do nothing.
I'll be honest, I think you're vastly overestimating how well these things are actually developed :) I agree with what you said, I just found this part a little bit funny.
Interviewer: How do you swap two variables without using a temporary variable?
Candidate: x = x + y; y = x - y; x = x - y!
Interviewer: You're hired!
... two months later ...
Boss: What the hell is this code you wrote?
Programmer: I swapped two variables without using a temporary variable!
Boss: You're fired!
I've been looking around at jobs, and was advised to start practising on HackerRank for the technical interviews.
I've been coding professionally for 30-ish years. There is very little that I've seen on HackerRank that comes anywhere close to a "real" software problem that I've faced developing actual software.
Why is this being used to do technical interviews? What's the thinking here?
It never made sense to me, I always just do a technical conversation and if for some reason a muggle has gotten an offer it's easy to detect and deal with. People don't last long in coding jobs if they can't do it anyway.
Back during Y2K I was working as a contractor for a large organisation. I was hired by a recruitment company, who were hired by the customer to provide a large number of contractors. Evidently someone messed up, and we had a guy join the team who couldn't code. He'd heard about the money to be made in Y2K, had done some simple exercises, and slipped through the screening process. But once he started it was obvious he had no idea what he was doing. We pushed back at the recruitment company, but apparently they couldn't fire him because they'd have to admit to the customer that they'd hired someone who couldn't code, and politically that wasn't acceptable. We were told to cover for him. So this guy clocked in every day and did nothing, literally nothing, all day, earning really good money for it. We disabled his login, so he couldn't do anything on the PC sat in front of him. If anyone from the customer organisation came by he had to look busy somehow - it was on him if he failed to do that and the customer started asking questions about him. He couldn't even read a book at his desk in case he got caught doing it. It must have been hell for him. We ended up feeling that he deserved the money just for being able to do that day in day out for months. I would have gone crazy. In the end, I moved on before he did so I don't know how it ended. I often think of that guy when pondering how life in a stable-but-boring job would be.
Let’s discuss it now: they are NOT ‘less smart.’
Compare that to our local community college, which seemed to have a much more well-rounded course and taught the fundamentals in a way that made much more sense.
Anecdotal of course but certainly defies the "rule".
Another anecdote: I did maybe 100 interviews while I worked at Uber. If I had to guess, I'd say 30% were from university grads (or soon-to-be grads).
Of those, most couldn't hardly write a line of code. Several candidates in the same age group came from a non-college/-university background and usually outshone those who did.
Is it the students? How many people are going into CS because they've had a taste of programming somewhere outside of school and decided they want to be a software engineer, and how many of them just get into CS because they heard that CS grads have very good employment prospects (Low unemployment, high salaries)? Anecdotally, I can tell you that during my senior project for my CS degree, someone in my group admitted to hating coding, but was pushed into CS by family, and that he couldn't code worth a damn.
Or is it the schools? In my school, the first two years were much heavier on the code, where the latter two years were heavier on CS theory. But in both cases, the quizzes and tests were on syntax and other things that could be answered with a short answer, or they were multiple choice. The only time your coding ability was tested was in the homework, which is easily plagiarized with Google and Stack Overflow.
Tests were basically all theory. Practical knowledge came from labs and everyone did the majority of their homework on lab computers that had no network connection. Not everyone was a rockstar of course, but as I recall pretty much everyone was at least a passable programmer in the end. Of course that was the early 90s...
CS contains more disciplines than just software engineering. Some people get into CS but have no interest/knack for coding: it just doesn't "click" for them the way it does for others, and they will fallback to rote memorization/copy-pasting from StackOverflow to scrape over the line.
I did Calculus 1 & 2 as part of my CS; but today, I don't think I'd be able to solve the FizzBuzz of Calculus, Linear Algebra, (or even the finer points of OS process schedulers if I'm being completely honest). I'd be alarmed if Software Engineering graduates weren't able to solve FizzBuzz
Uber's hiring pipeline was a mess.
Community colleges serve a smaller area, typically one county and its neighbors. Community colleges often have a much higher emphasis on trades and job prep. They will often offer more 2 year associate degrees, trade certifications and less 4 year degrees. They are rarely universities.
In the USA Community College can mean a private or publicly funded 2 year university, college or trade school. A state university is pubicly funded and can be a community colleges. See the New York State SUNY system for an example. There is also the New York City CUNY system which is publicly funded by the city at the local level.
I went to "Queensborough Community College", a CUNY university in NYC. So I tend to define "community college" as a publicly funded 2 year university/college.
Community College: no application, no traditional degrees, no prior learning required. Often vocation in focus. Adult classes. Anyone can attend (dropouts, elderly, anyone). You even just sign up for individual classes. You, 8589934591, could likely sign up for an online class next semester/quarter. Some are highly regarded, Foothill College in SV for example.
And I actually think I can speak to this with some amount of personal experience. I've been at both a lower tier college and a best-in-the-country university. When I was 11 I wanted to learn how to write software so I took courses nights, weekends and summers at the near by college until I was 14. I know how smart the class was and it was no where near as smart as the engineering students at the top tier university.
But that is ok! I think we overvalue intelligence in modern society, but to pretend that there are no differences is undervaluing the truth for the sake of political correctness or ideology.
On average smarter, but that more has to do with population size than anything. If you limit the comparison to the top N from state schools so that you were looking at the same population size, state schools would end up out in front on the "smarts" scale but lose on the "ambition" scale.
My take is, if you are interested in academic research and theory study, going to ivy leagues makes sense, or if you're into law/business/medical majors, school ranking matters a lot. For a high paid IT job at undergraduate degree level, ivy league makes absolutely no sense, the extra $200K tuition is also really just a net loss.
Of course one is better than the other.
As someone who went to a state school this does not bother me at all. CS education is not locked behind some door in a secret location - its open to anyone with internet access.
What makes one programmer better than the next is the extent to which he invests in educating himself.
This is true, but most of them don't go to top tier schools. Which is not at all the same thing as saying most people who go to top tier schools aren't smarter than average. This fact is the root of a lot confusion in the area.
I don't think anyone out of college for more than a few years thinks the "tier" of college you went to is the ultimate arbiter of how competent you are and can ever achieve.
IMO to compete in the "college admissions race", smart/motivated students will often compete like crazy to get into the prestigious university system. So because so many very smart/motivated students compete to get into the programs, the prestigious universities get their pick of top tier students who will end up graduating who could turn out to be smart/competent programmers regardless of the actually quality of the program.
I'm not saying these top schools have crap programs, I'd imagine they do have great programs as well, but I'd guess those same students would become good/competent programmers coming out of any program.
Which is it, statistical or anecdotal?
you can see the difference in which textbooks the school uses. It would be impossible to teach real analysis with Rudin at an average school or community college.
Or the math 55 sequence at Harvard, which basically gives students more mathematical training in a year than the average university student will get in an math entire degree.
My opinion is that nurture affects nature, so yes if we optimize childhood development it would naturally lead to better outcomes.
However I do believe people have a “natural” ceiling based on genetics. Meaning that no matter how great your nurture environment is, you could never become a top NBA basketball player or a Nobel prize winner.
Now I’m not saying MIT is either of those things, but it’s certainly difficult to get in and not simply a by-product of your “nurture” environment but some interplay with your “nature”. Although I’m sure with a timely $20M gift from your parents your chances of getting in would increase substantially, regardless of your qualifications.
To be clear I grew up fairly poor myself with no support system, but not that bad with violence, just trailer park poor, you can tell smart children at a very young age, kindergarten it will be obvious if a student is mathematically gifted(for whatever that is worth, it is certainly not the end all be all indicator of future success).
my point is that MIT will have a higher percentage of mathematically gifted students, because it isn't something that can be prepped for.
I guess I would be curious on how much a difference it really is , if you could completely control for environment, but even then the difference still exists.
In my experience, the average student of a prestigious institution is just as good as an upper decile student from a decent university. That said, the top end of those at top colleges are truly world-class. At the end of the day, these universities have historically educated the elite: there is discussion to be had on legacy admissions and paper-mill research groups that pad the resumes of high school applicants with research of little merit.
Maybe we have different definitions of average, which seems to be a hacker news bias, schools in the top 40 are not average by definition
, but many many schools offering math degrees don't even offer classes beyond that level.
There is a kind of pleasure in connecting the pipes and optimizing the loops and building a sick dynamic programming recurrence relation or whatever; we desire these flows. Who cares what skills they build?
Are we not allowed to do things for fun or just to pass the time anymore without someone writing that we’re wasting our time since it isn’t boosting our career?
Teamwork is tested very well by contests like the ACM ICPC programming competition: teams of 3 people, one computer, and 7 or so problems to solve in 5 hours.
Speaking from first hand experience, my team won the ICPC (many years ago...) based totally on coaching on our teamwork. Essentially, we arrived in the competition city 5 days early and somehow got adopted by the coach of another country's team (which said they didn't need her help). She spent those 5 days observing us approach each phase of the contest, and gave feedback on every aspect on how we worked together: triaging the problems in the first minutes of the contest, who to allocate which problems to, optimising sharing the single computer, when to switch when stuck, helping each other debug, etc, etc. Right down to how to lay out our stationery and stack our working notes on the table.
After doing 2-3 prior competition problem sets a day for 5 days, we became an amazingly efficient machine. Not because we were individually better problem solvers (thought there was some improvement there). But because we all instinctively did the right things in the right order, there was no dead time, no miscommunication, and no stress about our performance versus others.
Thanks to Raewyn's coaching, we converted probably a 5th place into a convincing 1st place. And she'd already won 1st place with her own country's team two years earlier.
So the focus on teamwork paid off. Both in our contest, and in work situations subsequently...
The HN crowd will know Adam D'Angelo (IOI Gold) - cofounder of Quora and Nikolay Durov (IOI ICPC Gold) - cofounder of Telegram. My personal examples are Singlestore (billion dollar company) which I cofounded and Near Protocol - 5Bln market cap crypto company cofoundered by Alex (ICPC Gold). There are also numerous fantastic engineers that have competitive programming under their belt working for tech primes and startups.
People who win are usually very very smart. AND they learn to work hard - you can't win without great work ethics. Skills wise you learn many algorithms and data structures cold. Plus you learn how to write small program with very few bugs from the the first try. Do they come out as complete package of a well rounded engineer - no, but there are years ahead to learn and they are trained to learn fast.
Bottom line is I can't disagree more. People familiar with the subject are often lucky to have the team and come with great network of nerd friend. Of course you will find people from this world who don't succeed, but more plenty become fantastic engineers.
What actually happens at all levels below the gold medalist level is completely different. People memorize leetcode and think they're gods of CS. Ultimately, you have to agree, these competitions come down to learning a vast repo of tactics. A guy who is generally good at CS or math can't show up and do well. You have to burn a lot of midnight oil so to speak.
IMO such data structure and algo mastery is largely illusionary. It mainly depends on the trends in the game at that point in time. If you see people who do well in such competitions, they have embedded themselves in these communities and think about it all day. Why should every programmer be held to this arbitrary standard? What if I want to learn ML, compilers and programming languages or study distributed systems? They are as much CS as anything else but you don't get a cookie every time you navigate a tricky situation. There is no gamification so you have to tread your own course. That IMO takes a lot more originality than what these rat races foster.
> A guy who is generally good at CS or math can't show up and do wel
this is also not true. While you won't get like first places without practice, you still will be able to solve basic problems (if your cs degree has any substance behind it). And during interview it certainly shows. Nobody will give you hard problems which you can solve only by having some very specific knowledge of this particular problem. If you don't know some algorithm by hard but still can work out some approach using you background knowledge, you will pass almost any interview.
I'll also contradict myself on how important smart and works hard actually is. I'm just a normal programmer who has had a few normal programming jobs. The vast majority of my career has been about doing relatively low-key programming and data munging. When I think back on software engineers "in the trenches" of standard corporate jobs I don't see any deep need to be particularly smart and hard working. Maybe "doggedly stubborn" about not giving up and making some progress each day instead.
I don't think it's worth a detailed response so I'll just respond to the reductio ad absurdum in their tl;dr, that competitive programming has been taken to extremes (implicitly by employers).
This is plain untrue. Sure a lot of interviews I've been through ask for a coding exam, but in this day and age that's just a wise precaution and no company that I've heard of would hire based purely on that outcome.
I've met (interviewed) too many candidates who can sweet talk their way through any technical matter but barely know how to use a couple of for-loops. This isn't a surprise---the push toward driving down the cost of software engineering labor means that there's a massive volume of people churning through the bootcamp machine.
The ones who want come to solve a few riddles (this is a nation-wide competition), food and drinks are provided, we have the opportunity to chat a bit and I can claim my last place, live every year.
This allows people who like these kind of things to get together in a relaxed environment.
So if both companies and students are heading in that direction then it's not that useless, isn't it?
This is a low effort anti programming interview difficulty inflation rant.
But anyway, competitive programming is one thing, tech interviews are another thing if you want to get technical about it. Mostly different set of skills are cultivated by each.
Finally, saying competitive programming is useless is equivalent to saying golf is useless (for example). Some people really enjoy competitive programming.
OOP is kind of topic that everybody is expected to know, yet for some reasons there are huge gaps between people when it comes to proficency at it, at modeling systems and domains correctly.
A typical comment or interview experience on Leetcode is that they take 3 months to prepare and do algorithms questions for FAANG interviews to pass the interview. In the process, some individuals skip class or other things. I don't think that is right personally.
Until then everyone will agree or disagree but some science will prove a definitive answer. It is very much worth doing such science given the prevalence of testing a programmer for such competitive skills and the fact that many consider such skills useless against the actual daily tasks of a programmer.
"Mathematical textbook problems are useless, because scribbling mathematics in a notebook is not best practice! Real mathematicians exclusively spend their time writing academic papers."
When you don't include the people you rejected in the statistic, the correlation is useless.
Would you please get in touch with me via Instagram @jesse.brill or Snapchat jessebrill55 or Facebook (search for Jesse Brill in Atlanta, GA) or via email Jesse.brill@gmail.com
I would appreciate talking to you and maybe you can help me.
On a side node, it was in competitive coding that I first ran into students using Ritalin for performance enhancement. Until then I had never run into it before.
I wish they had just asked more pertinent questions and saved everyone some time and me the humiliation.
---
> As a response, college students now pursue competitive programming obsessively to stay on top. In this weird arms race against prospective hires, companies keep asking harder and harder questions in a misguided attempt to raise the bar.
You should understand that more students pick it up because of the higher salary offered in the tech industry in your country (India) and this is one of the best bets to lift themselves and their families economically. To be fair, I don't blame them, majority would pick up ~CP~ <job/skill> because it has the highest returns for the effort put in. It's a fault in the system, not the students.
Personally I would be wary of anyone who says only competitive programming excites them. I feel that testing algorithms and data structures in some slightly realistic situation is the only way to weed out the pretenders.
Anecdotally, I have interviewed screening rounds from junior to senior. The juniors who pretend to like programming are usually filtered out when I change the application of the data structure slightly as compared to a leetcode/geeksforgeeks question. Something as simple as "reverse a paragraph/sentence" as opposed to "reverse a string".
Mid level candidates are the most difficult to filter out and this is exactly where the leetcode type questions come into the picture. They are able to talk about their projects as if they designed the entire stack. I have seen them draw the system design diagrams, tell me pros and cons of the stack/tech chosen, but they would usually fail in easy/medium level leetcode questions.
Seniors are the easiest to filter. We give them the easiest question possible and ask them to solve it. This is done with a huge disclaimer that this is a screening round and that the intention is to see you can actually write code and answer questions about it in real time. Questions are easy array/string leetcode setting them up for success. The good ones just finish it up in hardly 10 mins and move on the the design round following immediately. The bad ones just beat around the bush saying they wont code despite the disclaimer. The really bad ones are ones who cite N yoe so they shouldn't be tested on coding (this is when the senior dev steps in and recommends not to proceed with the interview anymore).
Coming back to the article, unless you have candidates/people who are actually interested in building software, and only when other jobs around you on avg pay a decent amount of salary for the place you live in, I am positive people will do everything they can to get the best ROI to become more sustainable in life. This is evident in > 5 yoe hires when people are in a more stable posn in tech economically and as interviewees they realise what they like/dislike and as interviewers you can discern whether they can actually do the job properly.
However, I am an undergrad myself and sometimes I take pride in being a generalist, spent my fair share of time on every abstraction layers of CS possible. Now that I'm in my final year, I'm concentrating to know more about *nix system internals, doing a thesis on Computer File Systems and occasionally doing Competitive Programming to be a better problem solver.
I understand the rant.
You shouldn’t be so opinionated before you’ve entered the work place. If you find, after a few years of experience, that this is true then fine.
I'm not opinionated. If there is any other way of proving that someone is good at these tactics, I'd love to work with them.
I think I read too much into deep. Certainly I'd expect any non-junior dev I work with to understand those concepts! But I wouldn't assume someone who published several papers on knot theory is any better at development that someone who hacked together a couple startup side-businesses, except in very very specific domains.
Aren't we talking about CS here. I understand your point ofc. As a CS undergrad, what other options you have to prove that you are capable and know different strategies and tactics (brute forcing, divide and conquer etc) to handle and maybe solve a problem?
Oh you're using it to pick who to hire to write mostly CRUD apps? Yeah, don't do that.
