You wrote: <<many of the algorithms used to solve problems took years to develop>>
I completely agree. Many years ago, I was challenged during a telephone interview to determine if a linked list contained a cycle. At the time, I did not know about Floyd's cycle-finding algorithm. Of course, I failed the interview miserably, but the experience stayed with me for many years.
One way to think about LeetCode is that it helps to expose you to 100+ obscure algorithms that might come up in an "elite-level" interview. Knowing them off the top of your head will either make your look like a robot / genius / both(!). Also, for interviews that require keyboard or whiteboard programming, "kata"[1] is undeniably good for your performance. Like anything, the more you practice, the better your performance will become.
Currently, we are interviewing at my office for software engineers. I always interview as a pair with the same person. We have slowly evolved our interviewed in an attempt to find a "local maxima" during a one hour time slot. No, we don't do whiteboard programming -- everything is f'in Zoom/WebEx these days!
I struggle with this: With the advent of Java and C#, a lot of average programmers know "enough" algorithms and data structures to get through an interview. How can we push harder to find better than average candidates? I don't know a good way without take-home programming assignments. Asking people to memorize 100 obscure computer science algorithms before an interview is just silly.
I would struggle to explain how a sorting algorithm works, but I know all about O-notation for time & space complexity of the best sorting algorithms. (My sort sizes aren't very large, so TimSort[2] works 99% for me.)
> How can we push harder to find better than average candidates?
Just ask them where they needed to solve a problem with an algorithm, why/what they did, how they implemented, tested, validated. What other problems could use the same approach, how could the problem be changed to invalidate assumptions, and so on. etc.
(While writing I realised that this fails in cases where the interviewers are not competent enough to follow along in random directions, which then gives the rationale for a leetcode quiz - basically a battleship-game that the interviewer prepares in advance so that he can pace the discussion and grade the candidate.)
Great follow-up, and great idea! I never considered asking that type of question. To extend further, ask people when they used the wrong data structure, how did they notice, and how did they fix.
I completely agree. Many years ago, I was challenged during a telephone interview to determine if a linked list contained a cycle. At the time, I did not know about Floyd's cycle-finding algorithm. Of course, I failed the interview miserably, but the experience stayed with me for many years.
In 2014, there was a blog post about this exact algorithm and interview question: https://www.nomachetejuggling.com/2014/06/24/the-worst-progr...
I pounded the desk when I read it!
It was even discussed on HackerNews(!): https://news.ycombinator.com/item?id=7953725
One way to think about LeetCode is that it helps to expose you to 100+ obscure algorithms that might come up in an "elite-level" interview. Knowing them off the top of your head will either make your look like a robot / genius / both(!). Also, for interviews that require keyboard or whiteboard programming, "kata"[1] is undeniably good for your performance. Like anything, the more you practice, the better your performance will become.
Currently, we are interviewing at my office for software engineers. I always interview as a pair with the same person. We have slowly evolved our interviewed in an attempt to find a "local maxima" during a one hour time slot. No, we don't do whiteboard programming -- everything is f'in Zoom/WebEx these days!
I struggle with this: With the advent of Java and C#, a lot of average programmers know "enough" algorithms and data structures to get through an interview. How can we push harder to find better than average candidates? I don't know a good way without take-home programming assignments. Asking people to memorize 100 obscure computer science algorithms before an interview is just silly.
I would struggle to explain how a sorting algorithm works, but I know all about O-notation for time & space complexity of the best sorting algorithms. (My sort sizes aren't very large, so TimSort[2] works 99% for me.)
[1] https://en.wikipedia.org/wiki/Kata
[2] https://en.wikipedia.org/wiki/Timsort