Solution Architecture and Requirements Analysis
Start every engagement by separating business requirements from technical ones and translating both into AEM capabilities. A candidate must be able to distinguish functional requirements (authoring workflows, multilingual delivery, personalization) from non-functional ones (performance budgets, availability, scalability, security posture). Key concepts: the AEM reference architecture (author, publish, Dispatcher, optional external services), the role of the content repository (JCR/Oak) as the system of record, and the decision tree between Sites, Assets, Forms, and headless delivery. Know when to recommend editable templates over static templates, when content fragments beat page-based content, and when an SPA or external front end justifies the extra complexity.
Traps appear in scenario questions that dangle a shiny feature. A question describing high author flexibility with low code deployment frequency points to editable templates and policy-driven component design, not custom dialogs. A question about delivering the same content to mobile, kiosk, and web points to content fragments plus JSON export, not page rendering. Watch for requirements that conflict: aggressive personalization against strict caching, or heavy client-side rendering against SEO. The architect names the trade-off explicitly rather than picking a favorite.
Rule of thumb: if a requirement cannot be traced to a component, template policy, workflow, or delivery channel, it is not yet a requirement. Worked example: a client wants editors to build landing pages without developer involvement and to reuse copy across channels. Map that to editable templates with layout containers and policies, plus content fragment models for the reusable copy, and a JSON exporter or GraphQL for the channels.