11–20 of 120 posts
I think that what the author calls "divide and conquer" is actually "recursion". Also the complexity of naive fibonacci is exactly the fibonacci sequence so O(2^n) is correct but less precise than O(phi^n)
I think that what the author calls "divide and conquer" is actually "recursion". Also the complexity of naive fibonacci is exactly the fibonacci sequence so O(2^n) is correct but less precise than O(phi^n)
For example, consider the bottom-up implementation of merge sort [1]. This implementation is not recursive, but merge sort uses divide and conquer regardless of whether or not you implement it top-down or bottom-up.
On the other hand, the naive fibonacci implementation that runs in exponential type is recursive, but it does not use divide and conquer.
[1]: https://en.wikipedia.org/wiki/Merge_sort#Bottom-up_implement...
The ratio of importance placed on these algorithm design in interviews vs the amount of times they actually come up in real world problems seems skewed IMO.
I would argue that it's a pretty good measure of programming and CS problem solving skill with weak alternatives.
The ratio of importance placed on these algorithm design in interviews vs the amount of times they actually come up in real world problems seems skewed IMO.
I think that what the author calls "divide and conquer" is actually "recursion". Also the complexity of naive fibonacci is exactly the fibonacci sequence so O(2^n) is correct but less precise than O(phi^n)
That means all divide and conquer algorithms can be implemented without recursion.
Earlier quoted context omitted.
I would argue that it's a pretty good measure of programming and CS problem solving skill with weak alternatives.
Most of these types of algorithms already have tons of research available online as people try to figure out what the lower bound of optimization is. It's far more telling to just talk about previous projects the person has worked on to gauge their level of competence. Asking them to explain why they made the choice they did vs trying to see how much they can memorize tests two different skill sets. The person who ma…
Earlier quoted context omitted.
Most of these types of algorithms already have tons of research available online as people try to figure out what the lower bound of optimization is. It's far more telling to just talk about previous projects the person has worked on to gauge their level of competence. Asking them to explain why they made the choice they did vs trying to see how much they can memorize tests two different skill sets. The person who ma…
How does someone talking tell you if they can actually do basic programming... I think you would be surprised at the number of people that apply for software engineering jobs but barely know how to program.
Earlier quoted context omitted.
How does someone talking tell you if they can actually do basic programming... I think you would be surprised at the number of people that apply for software engineering jobs but barely know how to program.
To be fair, I know a fair number of people who are good at competitive programming but are absolutely awful at writing maintainable code.
The ratio of importance placed on these algorithm design in interviews vs the amount of times they actually come up in real world problems seems skewed IMO.