Nice, so easy, simple and genious at the moment. Thanks.

oh, and as a suggestion: maybe we need more edge cases here, as it is quite hard to debug 30+ convert events within of 100+ rows

description says

Order the result by conversions_attributed desc. If two or more channels have the same total, order them alphabetically by channel.

but in the tests expected output for a random test seem to be sorted just by channel:

email	2.83
sms	17.33
push	13.83

it's hard to figure out from description whether there could be several 'converted' events for the same user

description says

 Ignore the conversion event itself — we only care about the touches that led up to it.

but it is not clear for me do you mean data in campaign_sends or in engagement_events or both, as that rows could have different timestamps in different fields

thanks, updated 🙏

maybe it would be useful to mention that applicant_ids should be ordered in the text as well

Thank you

From my perspective it's more a form of lazyness, like I don't want to write a lot and it's hard to keep in mind a lot of querries, so I try to make a shorter solution with less selects and joins. Also 'case when then' looks as an awkward construction for me so I try to avoid it as well.

Of course such tricks often is not a good thing in production code.

For me your solution felt like something Ramanujan would have written if he’d been handed SQL - not built from steps, but from some quiet, inner clarity where numbers simply knew where to go - a kind of mystical intuition, an aesthetic sense for numbers. It is not just correct - it is beautiful in a way that can't be taught.

Thank you very much

91

very impressive. I did not think it was possible to avoid join, but you did it! well done.

it would be better to show actual, expected and diff tables for the better user experience. You could look at the other kata that povide such an info. e.g. this one

This is exclusively for PostgreSQL?

in JS message like

Testing for:
pros = ["pros-1","pros-2","pros-3","pros-4","pros-5","pros-7","pros-8","pros-10"]
preferences = [["Code progammer","Computer repair","Cook","Data recovery service","Haircut","Handyman","House cleaning","Pet care","President"],["Code progammer","Cook","Haircut","Handyman","House cleaning","President"],["Computer lessons","Computer repair","Cook","Data recovery service","Handyman","President"],["Computer repair","Data recovery service","Haircut","Handyman","Pet care","President"],["Code progammer","Computer repair","Cook","Data recovery service","Handyman","House cleaning","Pet care","President"],["Code progammer","Cook","Data recovery service","Haircut","Handyman","Pet care","President"],["Computer lessons","Pet care"],["Computer repair"]]: expected [ …(10) ] to deeply equal [ …(10) ]

isn't very useful. I see the input but almost no information about expected answer.
That's in Random tests