AEM Sites Architecture and Component Development
Understand the request pipeline first: a request reaches the Dispatcher, then the AEM instance, where the Sling engine resolves the resource, selects a script/component, and renders. Key building blocks are the JCR content repository, Sling resource resolution, OSGi bundles and services, and the /apps vs /content vs /libs separation. Components live under /apps, are sling:resourceType-addressable, and consist of a rendering script (HTL), a dialog, and often a Sling Model. Know the difference between resource type and resource super type, and how the super type chain enables component extension and overlays without touching /libs.
Common traps: confusing sling:resourceType with cq:Component node type; assuming overlay means copy (it means resolution precedence, with /apps shadowing /libs); forgetting that clientlibs and dialogs also resolve through the same inheritance chain. Another trap is the proxy component pattern: a proxy sets sling:resourceSuperType to a core component so you can customize markup while reusing logic.
Worked example: to extend the Core Text component, create /apps/mysite/components/text with sling:resourceSuperType=core/wcm/components/text/v2/text, add your own HTL override, and reference it from the page via sling:resourceType. Never edit /libs.
Rule of thumb: if a behavior is missing, check the super type chain before writing new code.