1) Gathering requirements.

2) Turning those requirements into data structures.

I think a lot of companies will separate those into different roles, but I strongly believe that's a costly mistake in most situations. There's a feedback loop. Requirements inform your data structures, but your data structures help you contextualize (not pollute) your requirements. If you're working with an existing system, you also want to understand current structures in order to guide requirements. By guide, I don't mean to ignore pain, but if you're building a system to support multiple clients / users, then the real trick is to figure out how to do that in a cost-effective and elegant way.

When these roles are separated, and the requirements are gathered without knowledge of the structures, I believe you're setting yourself for failure in the long term (spaghetti code / everyone gets something different).

Getting these to gel is the puzzle I'm personally passionate about. I don't mind what I would call the math side of programming / code puzzles, but it simply doesn't give me the endorphin rush that building a system that elegantly ties things together does. The best is when you're working towards that or have achieved that and inspiration for further possibilities, improvements, efficiencies start popping up.

I'm not sure how you test for this as part of the hiring process, at least not efficiently. I do think we get better at this with experience, but I doubt it's exclusive to seasoned developers.