I said that because you used 15 as a hard-coded magic number to satisfy the problem. If you have variable input size, you should calculate it manually. I think it is not a easy problem to solve, but I can be wrong.

That is not true. I can easily modify my solution so it will take variable array of divisors. In that case the complexity would be O(m), where m is the divisor's count. And your solution would be O (n * m), where n - input number.

World is amazing. Yesterday it was rain and now it's snow. Of course if you prefer snow :)
I made my remark about this solution because it was marked as "Best practice". I assume that "best practice" solutions should be realy best practice and not just an "okey". For example if some task can be done in O(n) time than O(n^3) so it hardly could be "best practice" just because it solves the task.

Well, I see no problem writing readable and maintainable solution that is also fast. Most of the tasks here can be done super easy using bruteforce. However fast solutions requires some time, knowledge, thinking and so on. If someone will be asked question like this one in job interview and writes down bruteforce solution he will be asked to write smth faster or will he be rejected.

:-) That's surely not called "a bug"... So we will see, if the world gets better now;-)?!

Answered in solution above.

Yeah, but using "people" table, when in fact you don't have to, looks like a bug for me :-) Take it easy, I want to make this world better and solutions too as well, that is all.

this is a bug fixing kata, blame timmy.

this is a bug fixing kata, blame timmy. The idea of a bug fixing kata isn't really to create a new solution but to fix the old one.

Not so great solution because we don't need to use people table at all

Not so great solution because we don't need to use people table at all

The problem with your solution is that we can not change the divisors easily.
If the divisors were 3, 4 and 5, the complexity of the solution would grow up. The legibility would be lost easily.

I've just created a new solution focused on performance, but trying to be readable.

Best practices is described here as "good balance of performance, readability and maintainability". In fact, it's relative. But in this case, I think my solution very readable, easy to maintain and the performance is good (it returns in 0.1s for the input 1,000,000). Of course I would try something more sofisticated if the requirement for performance was critical, but not seems to be the case.

Bad solution, we count array keys every iteration