Imagine someone who loves system building and design, issues of code reusability and maintenance, and knows many languages, tools and tricks. But he doesn't like pure algorithms, questions about permutations, runtime analysis or the intricacies of sort algorithms.
Can that person still be a good software engineer / developer? If yes, don't these questions come up in all interviews though, so he'd have trouble getting a job in the first place?
I'd say yes, in certain domains. It seems like there's a continuum of programmers from hardcore algorithm people that can write ridiculously efficient low-level code but are totally clueless about how to glue it together into a robust, maintainable and usable high-level app to those who are just the opposite. I'm more in the former category. I love algorithms and designing reusable libraries of them, and write bioinformatics research code as part of my job. On the other hand, I've never assembled a real production application with a decent UI, user error handling, I/O that's not just a kludge, etc. in my life and have little desire to. Someone you describe, who could take my core algorithms and write all the UI code, glue, configuration management, I/O code, etc. necessary for a full-blown app would complement my skills perfectly. In short, there's room for both.
Yes, you can definitely be good at something and not like it. Just the same as you can be a champion chess player and hate the game. Now, if you don't like them to the point that you don't want to learn them then I wouldn't consider that good. If by good you mean get a decent job making a decent amount of money then definitely, most definitely, in fact! However, I really suggest giving it a go. :)
Software / Development jobs have many different roles. If you understand that, then you can realize that depending on the role that you want to be you can avoid algorithms all together.
The reason why they ask algorithm questions during an interview is to figure out how your logical / analytical problem solving skills are.
Here is an example. If you are asked a question "there are three light bulbs in a room and outside the room there are three light switches. you may enter the room only once. how can you tell which light bulb goes to which switch?". These types of questions are only asked to test your ability to solve problems, because in software engineering there are always problems that require you to think outside the box. If you can answer these questions then great you can be a great software developer for most normal tasks.
If the interviewer asks you a question like "Take this recursive tree function that runs in time O(n^3) and optimize it to run O(n^lgn)". Then they are giving you an option right then and there to realize that maybe the position would not be any fun for you. It is not an issue of "can you do it or not" it's an issue of would you like solving these types of problems every day.
Complex algorithm design typically does not happen in most job situations. If you get an interview that would never have the need to optimize on this type of level, and the interviewer still asks you to solve that kind of problem, then you are most likely looking at someone who would rather work with people who went to the same university as they did. In that scenario you are most likely better off thanking them for their time and finding something else.
To answer your question though with everything above in mind. Algorithms are not required for the job of software developer. They are required for very complex and directed tasks that require specific types of optimization. Unfortunately people tend to use it as a way to weed out those who have not had a formal education.
I don't think you can be as effective. Algorithms are clear thinking to solve a problem at a small and big picture.
Edit: Algorithms give legs to great design.
Good software needs to be able to see the big picture of why and how and the small details of why and how at the same time. Good software manages the question, "Where is everything at?"
The more tools and approaches we have the more we'll do right the first time.
Since we know fast is important, making good software usually means getting more done with less effort.
This does not mean the fastest computer processing, but in people spending less time dealing with things and letting the software deal with it more effectively.
Building tools to do more with less effort requires clear thinking and always evolving your ability to implement as efficiently as possible so it runs as effectively as possible.
I'm assuming that you are referring to "algorithms" as they teach in school/university. If so, then you can be superb developer. More important is to enjoy programming.
I think so, because most of them are either in libraries or not needed. What is needed is the right way of thinking. Training algorithms can develop it, but so can math and other exercises.
This is why algorithm competition and marathon match have totally different top players. Even better example is that Google seeks for people with engineering skills.
Well sure. Plenty of folks are perfectly successful as CRUD or line-of-business application programmers without any education or interest in the formal theory of algorithms. However, if you don't like "questions about permutations, runtime analysis or the intricacies of sort algorithms" then there are lots of jobs you had better steer clear of: writing compilers, operating systems, or mass market, shrink-wrap software like word processors and spread sheets among many others. You just won't be able to function at the state of the art.
Just bear in mind that the less you know about algorithms, the narrower the range of jobs that you can tackle.
Well, you can be a good one, yes. But not understanding the full implications of the code you are writing, I think, would lead to code that is simply worse than somebody who knows the running time of each operation they use. You often don't have to write your own algorithms (there are tons of immutable hash table implementations out there in any language), but understanding them should just help.
My argument is very similar to the "you should know pointers and recursion, because it just makes you a better programmer" argument.
Definitely...
I'd say that the majority of software development jobs have almost NOTHING to do with algorithms. Most of the programming work out there is chiefly passing around data, messing with a few strings, and some extremely basic math.
I'd say that the majority of developers out there rarely use anything but library methods.
I think this question is loaded with a lot of ambiguity about what people define to be a "Good Developer".
For my answer, I'm assuming it is someone who can perform the duties of his job, while not actively creating maintenance problems down the road. For this definition, someone who isn't interested in algorithms can definitely be a good developer.