same idea , wow

Whenthereisnospaceitsbetterforreading =)

who knows? maybe it's op grandma age?
https://stackoverflow.com/questions/47882/what-is-a-magic-number-and-why-is-it-bad

Damn, beat me by 4. Nice!

can spot an emoji in there, does that reveal how you feel about this kata

I'm all for "fix the bug" type katas, but usually bugs arise from expecting a certain result and being greeted with something seemingly random instead. I don't think I've ever gotten myself into a situation outside of this kata where I needed to debug code to find a result I didn't even know I was looking for. This would've been a lot better if the description was clear on what the function should return rather than leaving us to wonder why we even started it in the first place.

See if my edition is good enough for you.

I would reinforce that the goal of the program is to find denominational change rather than numerical change. Maybe add a specific example to clarify further. Something like:

"Be sure to count change by denomination. For example [25, 25, 100] will result in 'NO' because you cannot make 75 with 2 25 dollar bills"

Or you could always extend your current example explanation to say:

"NO. Vasya will not have the right combination of bills to give change for 100 dollars"

That's what the examples are for:
tickets([25, 100]) // => NO. Vasya will not have enough money to give change to 100 dollars
But what text do you suggest to add in the instructions anyway?

I'm completely aware of the logic and the math associated with the second interpretation, hence why I actually laid it out to show the expected outcome in my initial question. What I'm saying is it needs to be clarified in the description whether it is to be programmed via denomination or numerical value. Many times the 'logical assumption' has been completely thrown out the window when it comes to challenges on codewars, which means every challenge should lay out exactly what it is asking for, not expecting the coder to make an assumption. It seems to be an issue that a few people are misunderstanding as they try to work it out, myself included.

You can't break a 100 bill to obtain a 25 or a 50 bill. So the only logic interpretation is the second one.
Let's review your math in the first case:
One customer gives you a 25 bill, you have only one of them.
Second customer gives you another 25 bill, you have two of them now.
The third customer comes with a 100 bill, you have not 75 dollars (only 50 in two 25 bills), so the answer is NO.
If you're selling tickets unless you didn't sell any, you can't end with no bills.

Thanks for clarifying, but that statement in no way specifies which of the two senarios would play out. I interpreted that statement as "you don't have to worry about 5 dollar denominations or 10 dollar denominations" not "count bills instead of numerical value"

So... it is an issue and leads to lots of misunderstanding when testing, as it seems to have based on the 'suggestions' tab that I just read.

It's not broken. And you should return No, I'll explain why:
[25, 25, 25, 25, 25, 25, 25, 50, 50, 50, 100, 100, 100, 100]
For the 3 50 bills you have to return 3 25 bills (then you have 4 25 bills left)
For the 4 100 bills, you need 4 50 bills and 4 25 bills (or 3 50 bills and 6 25 bills) and you haven't enough.

Don't mark that as a kata issue, it's not. The correct interpretation is the second one, it's clear in the kata description:
Each of them has a single 100, 50 or 25 dollars bill

Another issue: is the change to be given back per numerical value or per each received dollar bill? For example:

[25, 25, 100]

The above would evaluate 'YES' if you were counting only numerical value. Starting is $0, then you have $25, then you have $50, then you have $75 (from the $25 from the 100) and you give back $75 as change. Your final total is $0.

The returned log would be:
0
25
50
0
'YES'

The above would also evaluate as 'NO' if you were counting actual bills. Starting is $0, then you have a $25 bill, then you have 2 $25 bills, but when the guy with the $100 bill comes in, you can't break it with your current bill set, therefore, you can't give him his change of $75.

The returned log would be:
0
25 - 1
25 - 2
'NO'