Damn it, I feel stupid for forgetting the Italian round after spending so many hours to solve it (and not without hints).

I'm happy that the experience with C was as intended at least for some people :D

Actually I often participate for Getting something new as AGCs are too awesome if we see their problems getting a blend of concepts. May be I am wrong! As I don't know much about what other mindsets.

Thanks for the feedback! AB aren't really interesting, I agree. I see some other issues but I disagree with those you described.

B: write trie(or hashes)

The problem is: understand the described process, figure out that's TRIE after reversing strings, put things in TRIE, do something extra in a created tree (either dp or going up through paths). I would say that implementing TRIE is the smallest/easier out of these 3-4 steps. Is trie even harder than segment trees? It's 10 simple short lines, takes 2 minutes. It's only one-fourth of my whole code. (While it's bad and I would prefer B with shorter solution, I'm arguing that TRIE here was just a simple tool to use.)

vector<string> in(n);
vector<vector<int>> paths(n); // extra thing needed in B
for(int who = 0; who < n; ++who) {
	string& s = in[who];
	cin >> s;
	reverse(s.begin(), s.end()); // extra thing needed in B
	int node = 0;
	for(char ch : s) {
		paths[who].push_back(node); // extra thing needed in B
		if(child[node][ch-'a'] == 0) {
			child[node][ch-'a'] = nxt++;
		}
		node = child[node][ch-'a'];
	}
	is_end[node] = true;
}

C: write FFT

If an AGC participant wants to solve C-F problems, they most likely just copy-paste FFT. Doing convolution was supposed to be the easiest part of this problem. Again, steps are: figure out that it's convolution after reordering with primivite root, find primitive root, do convolution, avoid double counting. Copy-pasting FFT takes 1 minute. Thoguh, I'm sad and surprised that it was obvious for people that we should use primitive root in this problem.

E: easy part requires no ideas at all, hard part requires one idea: check all pairs of bits. Other than that you just need to write annoying function that checks if the i-th bit is 0 or 1.

The idea of what to do is easy. It's difficult how to do it. If it's easy and codes are relatively short, how do people spend 1 hour on average in this problem? It shouldn't be about off-by-one errors or corner cases. I would say that once you figure out the next tool/blackbox/trick, it's very easy to implement it and run on on sample input values to check if it works. I would say that this problem can be solve by spending one hour with pen and paper, then 10 minutes with computer. And that makes a nice problem.

D: unordered_map gets TL. Usually I'd say it's my fault, but after other 4 problems about implementation having one about constant optimizations was too much for me.

I partially agree that it's bad and so does rng_58. He hates situations with too-slow-solutions being slightly too slow and I agree with him. We heavily discussed TL and ML in this problem and he even considered removing the problem just because of this. In your solution, using a map with $$$O(L \cdot H^3)$$$ time complexity is hopeless and using unordered_map isn't significantly faster. I think that your solution is at least 5 times too slow and it needs more than 1GB of memory. It was just not a good approach.

so basically, I expected CDEF to be very nice problems and for sure I misjudged C (the part about coming up using primivite root)

Well, I think i same quite simple implementations for both B and D. But I'm not sure if thinking on implementing B without trie was worth time spent on it.

I quite liked problems, they have some balance on thinking/writing you can move in diffrent ways. Probably, only problem looks strange for me is C. fft solution is quite obvious, and most time I spent on this problem was thinking if there is something easier.

I do not understand why you distinguish top ranked contestans here, still don't get what is harmful here and you can omit all implementation problems with:

long double f;
cin>>f;
int a = int(1e9 * (f + 1e-12));

Yup, it's the same dp.

The first part of the intended solution is basically getting nodes of permutation tree but it's much easier in this problem because we can stop whenever non-monotonic pattern occurs, e.g. children $$$(3,1,4,2)$$$. This makes the implementation easy: starting from any maximal monotonic block, keep expanding alternately with brute force: bottomLeft+topRight and bottomRight+topLeft. Thinking about permutation tree is one of possible ways to prove the amortized linear complexity.