good though

basically if true return true

This doesn't seem like the most practical approach.. don't know why it has most clever votes..

Yes, but my point was that this isn't best practice.. just clever.

the description says the input will be all positive integers

Good, but if they were to pass negative numbers as an input and it would fail..

I really dig the way the alphabet array was created here.

Yes, I did exactly what you say ,But in a more stupid way

if the specified substring ( a - z ) is not present in the given value ( string ), the indexOf() returns a negative value.

.

Theoretically, it's true

But in practical...

Yes, something that runs in 26n is 26 times slower than something that runs in n.

However, when talking about big O notation, that doesn't make a difference. There exists a C>0 for which they are both always faster than C*n. This means that by definition, they are both part of O(n).

This is why big O isn't always the be all end all. It's applicability always depends or your application. If n+26 would run in a day, 26n would need 26 days, but a n^2 algorithm could very well need a year to accomplish the same and 2^n could take a millennium.
If you compare something up to infinity, "26 times slower" is insignificant and can be neglected.

Oh I see,
but still O(26n) is much worse than O(n+26)

No it isn't. indexOf is called a fixed amount of times. The length of the alphabet does not increase when the input length increases.

In terms of big O notation, this has the same performance as basically all other solutions: O(n).