| I don't write algorithms on a daily basis, but is does account for a significant fraction of my work time. Some algorithms I have written: - List A and list B have common elements, go from A to B with a single insertion, deletion and reordering operation. - You have two dates/times, get the number of working hours between the two, with business hours and holidays taken into account. - Various forms of dependency management: we need to run an operation, that operation needs other operations to run first, themselves having their own requirements, etc... - Decode a character string where each character is 6-bit wide. - Have a set of data with different periods. Generate a schedule with a major/minor cycles. The algorithm has to understand things like 333ms = 1/3s. - And many smaller things I don't remeber. Most of the time, it fits in a single page, it is no big thing, I am not trying to prove P=NP here. Just that there isn't an already written library for every problem on earth. And even if there is, it may require a truckload of dependencies you'd rather avoid or it may not fit your particular problem without a lot of messing around. Or it might just be poorly written and unsupported, libraries are written by people with a wide range of resources and skill levels. Algorithms are part of the job, if you don't know the basics, it will affect your productivity. I've seen people struggle for days on basic problems, hopelessly struggling with libraries. Or after great effort, come up with a broken solution that will need to be redone eventually. Of course, algorithms are not the whole picture. But if a coder can't do it, there is at least one aspect of the job he lacks. And it turns out that it is easy to test for in an interview. Proper design is more important, but it is usually apparent only after thousands of lines have been written and requirements have changed several times, not something that is easy to test for. |