As an engineering manager this is a difficult one.
A developer who's excellent at leetcode really shines; it's a strong positive signal that correlates more often than not with someone who writes clean, easy-to-read and fast code. Furthermore, huge bonus points if they find learning algorithms fun because learning and enjoying code is, obviously, a big part of our work.
It also saddens me that so many developers (especially late in their careers) are stubborn about not learning these techniques ("I didn't get to be where I am now mastering recursion therefore it's stupid") which too often comes from an established position of privilege... This is very apparent when you compare to developers fresh out of university with little commercial experience; for them being good at algorithms is one of the few things - other than enthusiasm and side-projects - at their disposal. For that reason, leetcode is also fair you could argue; everyone gets the same treatment regardless of level.
However... a great many outstanding developers get flustered and tie themselves up in knots under interview pressure. If I went purely by "can this applicant perfectly solve this problem in 50 minutes" then I would be ruling out lots of really talented people. It also saddens me that early-career developers are being trained to just leetcode grind when what makes for a good hire (at any level) is someone who's endlessly curious and humble as opposed to being an algorithm beast.
It's tempting to think the solution should be a practical "make this app" test, but most highly-experienced developers can kick out excellent apps from muscle memory which tells me little about their ability to think on their feet, collaborate or learn new things. Furthermore if it's a take-home exercise, it significantly privileges those who have the freedoms to spend lots of time on it: e.g this could be a struggle for single parent families.
I recommend you watch Dan Abramov's fake interview on YouTube along with the two Ben Awad did to get some perspective on all this.
What we're currently experimenting with at Tipalti is pairing on a mix of some practical challenges and some algorithm challenges. The expectation is set that we don't care about completing, but more about how to solve the problem together. Everyone - including the hiring panel - are allowed to get confused and stuck and in a good interview session we'd all solve it together. The two sessions act as complementary bookend that gives a good feel for the candidate's range and approach.
Of course, it's not perfect by any stretch but like most things with engineering we keep an open mind try something new, get feedback then iterate. Always learning.
A developer who's excellent at leetcode really shines; it's a strong positive signal that correlates more often than not with someone who writes clean, easy-to-read and fast code. Furthermore, huge bonus points if they find learning algorithms fun because learning and enjoying code is, obviously, a big part of our work.
It also saddens me that so many developers (especially late in their careers) are stubborn about not learning these techniques ("I didn't get to be where I am now mastering recursion therefore it's stupid") which too often comes from an established position of privilege... This is very apparent when you compare to developers fresh out of university with little commercial experience; for them being good at algorithms is one of the few things - other than enthusiasm and side-projects - at their disposal. For that reason, leetcode is also fair you could argue; everyone gets the same treatment regardless of level.
However... a great many outstanding developers get flustered and tie themselves up in knots under interview pressure. If I went purely by "can this applicant perfectly solve this problem in 50 minutes" then I would be ruling out lots of really talented people. It also saddens me that early-career developers are being trained to just leetcode grind when what makes for a good hire (at any level) is someone who's endlessly curious and humble as opposed to being an algorithm beast.
It's tempting to think the solution should be a practical "make this app" test, but most highly-experienced developers can kick out excellent apps from muscle memory which tells me little about their ability to think on their feet, collaborate or learn new things. Furthermore if it's a take-home exercise, it significantly privileges those who have the freedoms to spend lots of time on it: e.g this could be a struggle for single parent families.
I recommend you watch Dan Abramov's fake interview on YouTube along with the two Ben Awad did to get some perspective on all this.
What we're currently experimenting with at Tipalti is pairing on a mix of some practical challenges and some algorithm challenges. The expectation is set that we don't care about completing, but more about how to solve the problem together. Everyone - including the hiring panel - are allowed to get confused and stuck and in a good interview session we'd all solve it together. The two sessions act as complementary bookend that gives a good feel for the candidate's range and approach.
Of course, it's not perfect by any stretch but like most things with engineering we keep an open mind try something new, get feedback then iterate. Always learning.