Doing a bunch of leetcode problems (something like 20-30 hours over a few weeks) certainly made it easier to answer questions quickly, largely by becoming more fluent in the language and libraries.
This is the only LC hard I've ever been asked in an actual interview https://leetcode.com/problems/shortest-path-in-a-grid-with-o...
Pretty sure all the others were easy or medium.
They say the maximum length of the input digit string is 10, so there are at most 9 places where an operator can be inserted. At each possible insertion point there are 4 possibilities: insert one of the 3 allowed operators or do not insert anything.
That's only 262144 possible expressions. Just brute force evaluating all of them, filtering out the ones that do not equal the target, and then filtering out those that violate the no leading zeros requirement should be fast enough even on a slow computer.
The other hard ones I've seen have all allowed inputs large enough that brute forcing would be way too slow, and so cleverness is required. E.g., that shortest path in a grid problem that was posted a comment or two above. My first thoughts on that one were to just generate all possible paths with the obstacles ignored, and then find the shortest path(s) that do not cross more than the number of obstacles we are allowed to eliminate.
But the grid can be up to 40x40. By 10x10 we're already up to 41044208702632496804 possible paths [1], so brute force is not an option.
*Fair meaning there's no crazy tricks to it or any obscure algorithms just applying DSA fundamentals.
I wouldn't expect more than brute force. But being able to reason about this, having some working familiarity with graphs etc, is not an unfair bar.
I am sure I would have done better at those with practice, entirely because I would have seen lots more fiddly dynamic programming problems and not because I would have picked up any general-purpose skills or knowledge I don't have as-is.
Lot of people claimed they got "Leetcode Hards" after failing an interview, but none of them could ever point to the actual question they failed, or even remember it!
I'm sure some interviewers somewhere like to mix LC Hards into the interview loop, but it doesn't appear to be as common as internet comments make it sound.
When companies use such a problem do they usually include the time and/or space constraints from Leetcode or are they usually fine with O(n^2)?
The problems come when a company overestimates that threshold, either by selecting too hard a task, or believing their work requires more than it does. Then the question selects for (a) savants and (b) people who study for interviews. Unsurprisingly (b)s outnumber (a)s, and then get pissed when they realize how disconnected the material they studied is from the job, and write things like TFA.
if we cant talk about the problem together from first principles and make some progress, and you cant demonstrate that you're tracking the discussion at all then we cant work together on that database.
sure, for devops, who cares.
Describing that as selecting for "obedience" is rather dramatic and provocative, but it's directionally right.
That's what the article is about, it isn't about the sort of basic programming test that anybody should be able to pass without explicit preparation.