Declarative scenarios describe WHAT the user is trying to achieve in business terms; imperative scenarios describe HOW step-by-step (clicks, fields). Declarative style is the BDD best practice; imperative is a common anti-pattern.
An imperative scenario ('click the email field, type x, click password, type y, click submit') couples the spec to UI mechanics, becomes long and brittle, and is unreadable to business. A declarative scenario ('When the user logs in as an admin') expresses intent, hides the mechanics in the step definition, stays stable across UI changes, and reads as documentation. The UI details belong in the step definition/Page Object, not in Gherkin. Writing declarative scenarios is a key skill; imperative Gherkin is a frequent review finding and interview discussion point.
Replacing 10 imperative steps (enter this, click that) with one declarative 'When the customer places an order for 2 items' makes the scenario readable and unaffected when the checkout UI is redesigned.
A teammate writes scenarios full of 'click #email, type..., click #submit'. Why is this an anti-pattern and how do you fix it?