Excuse me. If I could find a delete button I'd press it, but I can't find one so an edit will have to do.

Your code won't work for {25,25,50,50,100}. It should return no, but yours will return yes.

One way of optimizing your time is to make something abstract only when it is expected to change. So, if the requirement changes once or twice, abstract it out. Otherwise, a simpler specific solution will save you time and reduce project complexity.

Thanks for pointing this out :)

Oh, I'm a beginner programmer (working about 1 year) and I couldn't agree more on the requirements when dealing with people, you're absolutely right about it and sadly, it will never change. People in general will always change their minds whenever they can, that's why I love doing open source projects and just dealing with this annoying chattering when I have to. Don't let your hopes go down tho, there are awesome places to work and they'll minimize this kind of situations.

I think you're half right. You've said things that I agree, but sometimes you just have an answer that fits your demands. You know your parameters and they won't change, but most importantly: you don't have to think about scalability on a common solution like this one.

"WAIT, are you SAYING that scalability or abstraction SOMETIMES isn't a good thing?"
Hell no, but if we would stop to think about an ideal solution for everything, we would end up stuck extra minutes/hours finding, creating or adapting a design pattern on top of a solution that is much smaller and simple.

There are a lot of higher level KATAs that need a generic or abstract code, that are full of random tests and it will break your code if the mindset is slightly distorted. My purpose here was to find the smallest and quickest solution to this KATA, I see by your answer that you aimed for a more generic solution, that's indeed better than the most solutions on this KATA, but again, that doens't make our solution - by any means - horrifying.