Most "leetcode" questions they ask are just easy level programming puzzles. The fact that many developers seem to hate it and even struggle with it says more about the developers applying than it does about Google.
The fact that there are whole industries built on training these puzzles is a big signal that you're wrong.
Also it's funny that engineers leaving Google, Amazon, et all NEED to practice these skills in order to get other roles because it just shows that these skills aren't needed (read: exercised, grown) working in their day-to-day jobs.
> The fact that there are whole industries built on training these puzzles is a big signal that you're wrong.
I'm not sure that logic alone is a compelling: It's conceivable that this secondary industry addresses a real gap in university curricula, or a need for ongoing training of experienced developers.
But I think your overall point still holds, because there's a consensus that a large number of Leetcode-like puzzles require familiarity with problems and solutions that hardly every come up in real professional software development, and aren't even good proxies for the abilities that do matter.
>The fact that there are whole industries built on training these puzzles is a big signal that you're wrong.
Wrong about what? That they are easy? If you know binary search, sorting, sets, hash tables, recursion then it is easy. If you wanted to make it more aligned with what a developer does day to day the alternative is doing a small project in your own time which is more time consuming for everyone.
Leetcode "easy" questions are just common sense application of everyday algorithms and data structures. These might make sense for an automated screening test of "is this candidate lying about knowing the language".
But, then there's the ones that are all about specific techniques such as dynamic programming + memoization, or specific graph algorithms etc, etc. Any decent programmer can learn how to do these harder problems under time pressure (interview) through practice, but this is really about Leetcode grinding prep... these are not problems you would likely encounter in most jobs, and in the real world you'd just Google for algorithms or ask a colleague if you needed help.
> Most "leetcode" questions they ask are just easy level programming puzzles.
As a senior developer currently looking for work, I have mixed feelings about leetcode-like questions. Here's my take:
Pro: They rule out most/all applicants who lack basic programming competence.
Con: Any timed or live programming test can make some applicants fail because of performance anxiety.
Pro/con: Some of the problems require (a) very high intelligence or (b) familiarity with how people have solved that specific problem in the past.
I think (b) is a major source of complaints, because for most people the only solution is Leetcode grinding, which outside of the interview process isn't a good use of one's professional development time.
Con: At least for timed problems on Hackerrank, you have a dilemma: A simple, straightforward solution takes little time to code, and is easy to explain. But it might also take too long to run on some of the test cases, which then requires you to guess at the source of slowness, and try to fix it.
But in multi-problem Hackerrank tests, you don't necessarily know if you have enough time to do that, because the other problems in the set might or might not require lots of time as well. And you can't revisit an earlier problem once you've submitted a solution.
Your assertion is that Google asks “just easy level programming problems.” Assuming we accept this argument, that probably tells most of us more about Google than it does about some straw-man developer.
But I’ll give Google a bit more credit than you and guess that they ask questions that are at least above the “easy” level.
