It is like any other sport or Olympiad, it involves solving faster, accurately and potentially of problems you haven't seen before. There is no direct correlation between competitive programming like CodeJam/ICPC and leetcode. They don't target the same audience at all. I couldn't get to the top of these but I do admire people who do, they are some of the absolutely brilliant people I have worked with. I have seen how they employ their rapid understanding, breaking down and debugging skills in real world programming as well.
Coming to this argument about even algo/DS interviews, could you suggest an algorithmic interview replacement, that is not time consuming, is objective, language agnostic and scales well with the size of a company? It is not like these companies are not having past experience, system design interviews. They do have them as well but they cover subset of what all you would want to check.
I would have expected to read more reasonable opinion on HN.
What is the difference that you see between these sorts of algorithm puzzle contests?
Is there some reason that people who are good at one contest would be bad at another, similar contest?
Leetcode works like this. Company A is asking these 100 questions with this frequency; let me solve these questions so that when I encounter these in the interview I can solve them then. The whole premise of Leetcode is on giving a question bank to what is already being asked. The aim is to clear the base bar a company has set.
There are some people who basically just do competitive programming to be good for interviews, but they don't get very far - not even to div 1. They reach whatever bar is necessary to clear an interview and quit immediately. The people who seriously compete to go for ICPC World Finals or to get far in CodeJam, they aren't really concerned with interviews.
The problem is LeetCode is SO BORING for anyone ever tried competitive programming so people usually won't do it at all.
Having seen similar problems really helps though.
Just like any sport as well
Firstly the interview should be structured with an aim to maximize correlation between success on the interview and success on the job. If you’re not thinking along these lines you aren’t even playing the game.
For most startups, the right criteria to screen for is pace and quality of code, plus work ethic.
You can ask a relatively easy coding problem, whether it be algorithmic/data structure, or more real world, that 99% of people will be able to solve, but still apply a high bar for what’s considered passing. Can they code the obvious solution quickly and effortlessly? I dont care at all if you’re able to produce a solution, I care about the path to that solution.
Screening for the straight arbitrary algorithmic/design diagram problems has hordes of people who have trained to the test. At scale hiring these people may work through selecting for people with decent work ethic to grind problems, but you’re not going to get consistently great people this way. Lots of false negatives and positives.
Having hired over 100 engineers in the bay area, judging by coding competency first was always more effective than judging based on quick shot leetcode/algorithmic aptitude. You can easily grind canned algorithms to pass a leetcode style interview, but you can’t fake coding proficiency.
If you’re hiring for DB or ML developers, obviously theory is more important. But 90+% of you are not
The kind of interview you describe is something Stripe also does, but I have seen even this resulting in non objective selection criterias. Like one Stripe employee told me that they prefer if someone uses a map rather than iterating on a list, as it is cleaner. While I agree with the sentiment; I don't think it is a good filter to add in the interview.
It's like asking for the difference between an Olympic race and a blue-collar job requiring you to be fit enough to run a mile.
- Can they code quickly?
- Do they know common APIs offhand? (Not have to look up)
- Do they write code in a readable fashion?
- Do they consider tests?
- Do they think more deeply about code structure? Immutability, single source of truth, DRY, not overengineering
You can understand all of this by asking a very easy problem that is written in 50-100 LOC. I tend to ask them to implement a certain data structure, where the naive solution is obvious, but still requires ~50 LOC. Then there’s a better runtime solution so I can assess theory as well, but I dont judge primarily on that, or care too much if they figure it out.
You may be surprised how much signal you can get out of asking somebody to implement a class with a few APIs and basic loops/data structures.
The simple fact that people who don’t train specifically for leetcode, don’t do well at it is effectively proof that it’s weakly correlated with real world work results. Otherwise people who are effective in the real world would automatically do well with leetcode. Speaking more to the harder problems though, the easier problems are much more correlated
>I print out 10-15 code snippets (not just code, but also UNIX commands, regular expressions, SQL queries and many other things). I then go through and ask: what does this snippet do, how does it work, are there any bugs, etc.? Reading code (as opposed to writing) means I can cover a lot of ground extremely quickly, spending no more than a minute or two on each problem.
Similarly, many small questions is going to give you a more accurate view than a single hard algorithm problem. There tends to be a trick or specific process to solve leetcode style problems, thus sessions are more black/white on whether the person makes that observation. Very unnatural to usual dev work.
Interviews should never feel “hard” even if your threshold for success is high. There’s nothing that requires you to ask hard questions to get good candidates.
By definition if your problems are perceived as “hard” then they aren’t assessing people on relevant skills, because a problem that is correlated with real world work shouldn’t be hard for anybody who is coding all day/every day.
(Though somebody who is unskilled may find pretty much any problem hard, speaking more broadly here)
I loved it.
Top level programming competitions are like top level spelling bees. You need to have as many algorithms memorized as possible in code. That’s right. You need to be able to recite code by memory to pump out algorithm functions as quickly as possible since libs aren’t allowed generally. This isn’t a useful skill.
We never won anything, so I would not dare claim we competed at a highest level. As far as I remember, most of our preparation was about "recognition" -- how to tell if a greedy approach is optimal, or how to recognize if a dynamic approach fits. And of course, how to write a program quickly and not forget any corner cases.
I remember having daydreams back then of memorizing a max-flow algorithm or potentially even a linear programming solver and then quickly retyping it at a competition. Flows and LPs indeed solve a lot of stuff (LPs are P-complete). I admit I never did that, and it wouldn't be a winning strategy there anyway.
PS: Oh, and contrary to the poster above, most of my friends from the university days would be and indeed were great hires, judging by their jobs at Google, Microsoft and elsewhere. Some others, such as the actual ICPC winners from our university, ended up pursuing academic careers -- but I dare not say they would have a bad time in the industry.
Yes, I was part of a USA team in an international competition. I won our region.
For what it’s worth, competitive programming isn’t like sports. The playing field isn’t that good, and the amount of work it takes to make it past regionals and to an international competition is waaaay less than any sport or even something like chess I suspect.
I think it helped to have some background in time-constrained thinking from high school math contests, but I was never particularly good at those, either.
That said, sometimes the field really is weak. I finished in the top 1000 on the first Distributed Code Jam and got a t-shirt just because... less than 1000 qualifying contestants were willing to even figure out the novel setup and compete. (Actually I did badly.)
Identifying root applicable algorithms and reproducing them quickly is what you study when competing in programming competitions.
Why are you presuming an algorithmic interview? How many engineering jobs depend on being able to memorise algorithms?
If you mean suggesting an engineering interview: sure. Give someone a task and 40 minutes to build it. Leave them alone. Come back and go through the solution together.
Personally, I would be a much bigger fan of competitive programming if at least one of these were true:
1. The problems at high level programming competitions were harder and maybe mapped more to real-world programming problems. Think of the IMO or the Putnam exam in "competitive math." The "Olympiad" of programming today consists of 5-10 problems that top-level competitors can solve in ~10 minutes each by reading the problem and mapping it to a known algorithm. Speed of typing and information retrieval from your algorithm library is the primary skill here.
2. The scoring method was something other than speed of production of code. Performance of the code is an easy alternative, but also not a great one unless you want to force everyone to use C++ or Rust. Using an objective function of some sort (based on the problem) would be an interesting method, but harder to write questions for.
It is very easy to see the link between leetcode and competitive programming. The problem structure is basically the same, and the big difference is that the leetcode problems that people give in interviews are easier. The problem-solving skills involved are the same.
Also, I can't suggest an interviewing method for you that has all those properties, because one doesn't exist. You aren't going to find one interviewing method that works the same for a cloud provider, a CRUD SaaS startup, and a game studio. This isn't something you can just cargo cult, you have to design it for your own situation. My inclination would be to cut the 5 leetcode interviews from your circuit and put that time into a single 2-3 hour take-home project that has some relevance to your company plus a 1-hour code/design review interview. Alternatively, give a candidate a bunch of small code snippets and ask them to debug the code.
Finally, if you want an IQ test (which is what I suspect hiring based on "spelling bee" competitions like competitive programming and leetcode is really about), you can add a Wonderlic test (or one of their competitors) to your interview circuit - a lot of hedge funds do it, and I honestly didn't hate it when I interviewed with a few of them.
I don't think you've kept up with or watched any "top-level" competitive programmer solve problems. Saying all competitive programmers do is copy-paste is like saying all programmers do is google.
If you looked at the Putnam results this year, a good amount in the top 50 were competitive programmers (let alone top 500 which was filled with names on Codeforces). This is just America and Canada which aren't the strongest countries in the world when it comes to competitive programming. There is a significant amount of medalists in IMO who won gold medals at IOI.
Now 1) is definitely true. In the last ICPC, no team could solve D (including the winning team consisting of an IMO gold medalist, despite 19 tries).
Here is another example of a tough problem. It was so difficult that the solution to this problem was a published math paper! https://codeforces.com/blog/entry/109707#comment-977862
Now to debunk copying and pasting library code. Take a look at this blog. https://codeforces.com/blog/entry/112021
If you think just using some library code is competitive programming that takes 10 minutes to solve and mapping to some well known algorithm you most likely have never done it to any serious extent. In that case, provide more informed opinions then saying it is the same as leetcode.
Do you consider competitive programming a sport?
Everyone says this and then their replacements are time-wasting take-homes or raw credentialism. It's a drag to get ready for interviews but I think the fact that one at least has the opportunity to play on a level playing field regardless of what names are already on their resume is one of the best things about this career.
You demeaning a mind sport just because something similar is used for interviews is the joke.