A standard engineering loop tests depth in one lane. The FDE loop tests whether you can hold four things at once, because the job does.
System design under real constraints. Not "design a URL shortener" — "deploy this model inside a client with a latency budget, a legacy identity system, and no cloud egress." They want to see you reason about the mess, not the whiteboard ideal.
The client-facing case. Expect a role-play or scenario: scope an ambiguous ask, push back on a bad requirement, or explain a technical decision to someone who won't read the diff. This is the axis most engineers underprepare, and the one that most separates FDEs from strong ICs.
Eval-scoping. Given a fuzzy task, define what "good" means and how you'd measure it. And deployment war stories — have three ready, each about a time you made something survive contact with a real system. Specific, owned, with the mess intact.
Prepare the intersection, not the pieces. Anyone can grind LeetCode; the FDE screen is looking for the engineer clients trust in the room.