I'm a 15 year(ish) engineer-turned-manager who has spent a good chunk of time doing recruiting.
* I confirm that day to day business problems rarely are the sort of problems you find on Leetcode.
* I might ask similar questions in interview. I don't expect the candidate to solve them. As a matter of facts, I don't care if the candidate actually solves them or not. I am observing how the candidate behaves in front of a difficult problem. Will they freeze? Will they jump head in the code? Can they articulate their thoughts and think analytically about it? Can they think on the spot if I challenge their approach? Are they comfortable saying "I don't know"? This sort of things.
In my book, being a "good engineer" is much more about communication, collaboration, familiarity with git/sourcecontrol, clarity of commit messages, pertinent emails, being reliable, being resourceful, etc.
Good grasp of algo is a big plus, of course, but it's not something that all the best engineers excel at.
* I confirm that day to day business problems rarely are the sort of problems you find on Leetcode.
* I might ask similar questions in interview. I don't expect the candidate to solve them. As a matter of facts, I don't care if the candidate actually solves them or not. I am observing how the candidate behaves in front of a difficult problem. Will they freeze? Will they jump head in the code? Can they articulate their thoughts and think analytically about it? Can they think on the spot if I challenge their approach? Are they comfortable saying "I don't know"? This sort of things.
In my book, being a "good engineer" is much more about communication, collaboration, familiarity with git/sourcecontrol, clarity of commit messages, pertinent emails, being reliable, being resourceful, etc.
Good grasp of algo is a big plus, of course, but it's not something that all the best engineers excel at.