Introduction

Getting ready for an AEM Senior Technical Lead interview? This role usually tests four things at once: your depth in Adobe Experience Manager (AEM) architecture, your hands-on JavaScript and HTML/CSS skills, your ability to lead a development team, and your real-world troubleshooting experience.

Below is a complete list of AEM interview questions with answers and simple examples, written so anyone — fresher or experienced — can actually understand the “why” behind each answer, not just memorize it.

Section 1: AEM Architecture Interview Questions

Q1. What is AEM and how is it different from a normal CMS?

Answer: AEM (Adobe Experience Manager) is a content management system built on Apache Sling and Apache Felix (OSGi). Unlike a traditional CMS where content and templates are tightly bound to a database, AEM stores everything — pages, components, assets — as nodes in a JCR (Java Content Repository), similar to a file-folder tree.

Simple example: Think of JCR like a computer’s file system. A page is a folder, and each component on that page (banner, text, image) is a sub-folder with its own properties. This is why AEM content can be copied, versioned, and rolled back so easily — it behaves like files, not database rows.

Q2. Explain the role of OSGi in AEM.

Answer: OSGi lets AEM’s code be split into small, independent bundles (like plugins) that can be started, stopped, or updated without restarting the whole server.

Example: If you update one custom bundle (say, a PDF-generation service), OSGi reloads just that bundle. The rest of the AEM instance — workflows, other components — keeps running without downtime.

Q3. What is the difference between AEM as a Cloud Service and AEM 6.5?

Aspect AEM 6.5 (On-Prem/AMS) AEM as a Cloud Service
Deployment Manual/IT managed Fully automated via Cloud Manager
Repository access Direct CRX/DE access Abstracted, no direct repo browsing
Updates Scheduled patches Continuous, automatic
Scaling Manual Auto-scaling
Code rules Flexible Strict (no sudo sessions, mandatory code quality gates)

Example: In AEM 6.5, a developer could open /crx/de and directly inspect nodes. In AEM Cloud Service, that path isn’t available the same way — everything goes through Cloud Manager pipelines and code quality checks before deployment.

Q4. How does the Dispatcher work, and how would you debug a caching issue?

Answer: Dispatcher is AEM’s caching and security layer. It stores rendered HTML pages as static files on the server, so repeat visitors don’t hit AEM’s backend every time.

Simple example: Imagine a popular news homepage. Instead of AEM rebuilding that page for every single visitor, Dispatcher serves a saved static copy — much faster, much less server load.

Debugging steps when cache isn’t working:

  1. Check cache rules in dispatcher.any — is the URL pattern even allowed to cache?
  2. Look at response headers — cookies or auth headers often force a bypass.
  3. Confirm the page was actually “activated” (published) — cache clears on activation.
  4. Check filter.any — a blocking rule there stops the request before caching logic runs.

Q5. What are Sling Models? Why are they preferred over older approaches?

Answer: A Sling Model is a plain Java class that automatically pulls data from a page or component using simple annotations, instead of writing that logic by hand every time.

Example:

@Model(adaptables = Resource.class)
public class BannerModel {
    @ValueMapValue
    private String title;

    @ValueMapValue
    private String imagePath;

    public String getTitle() { return title; }
    public String getImagePath() { return imagePath; }
}

In the HTL file, you simply call ${bannerModel.title} — no manual resource-reading code needed. This is cleaner, testable, and reusable compared to older WCMUsePojo classes or JSP scriptlets, where logic and markup often got mixed together.

AEM Technical Lead Interview Guide

Q6. What is HTL (Sightly) and why is it considered more secure than JSP?

Answer: HTL is AEM’s official templating language. Its biggest advantage is automatic contextual escaping — it looks at where a value is being printed (inside an HTML tag, a URL, a script, an attribute) and escapes it correctly to stop injection attacks.

Example: If a user-submitted field contains <script>alert(1)</script>, HTL automatically converts it to safe text rather than letting it run — unless a developer specifically disables that protection with context='unsafe' (which should almost never be done).

Q7. How would you design Multi-Site Manager (MSM) for a company with 20+ country websites?

Answer: Use a Blueprint (master structure) with Live Copies for each country. Decide upfront which parts are “locked” (shared navigation, legal footer) and which are “free to edit” (local promotions, images).

Example: A global retail brand keeps its header/footer locked across all 20 country sites through MSM inheritance, but lets each country team freely edit homepage banners — rollout rules push master updates automatically while preserving local customizations.

Section 2: JavaScript Interview Questions and Answers

Q8. What is a closure? Give a simple real-world example.

Answer: A closure happens when a function “remembers” the variables from where it was created, even after that outer function has finished running.

Example:

function createCounter() {
  let count = 0;
  return function () {
    count++;
    return count;
  };
}

const counter = createCounter();
console.log(counter()); // 1
console.log(counter()); // 2

Here, count stays alive and private to each counter instance — this pattern is often used for things like tracking click counts or managing private state in a module.

Q9. Difference between var, let, and const?

Answer:

  • var — function-scoped, can be redeclared, hoisted as undefined.
  • let — block-scoped, can be reassigned, but not redeclared in the same scope.
  • const — block-scoped, cannot be reassigned (but objects/arrays inside it can still be modified).

Example:

const user = { name: "Raj" };
user.name = "Amit"; // allowed — object content changed
user = {};          // ERROR — reassignment not allowed

Q10. Explain the JavaScript event loop in simple terms.

Answer: JavaScript runs one task at a time (single-threaded). The event loop decides what runs next: it always finishes all pending “microtasks” (like Promises) before moving to the next “macrotask” (like setTimeout).

Example:

console.log("1");
setTimeout(() => console.log("2"), 0);
Promise.resolve().then(() => console.log("3"));
console.log("4");

// Output: 1, 4, 3, 2

Even though setTimeout is set to 0 milliseconds, the Promise (3) always runs first because microtasks have priority.

Q11. What’s the difference between == and ===?

Answer: == compares values after converting types if needed (type coercion). === compares both value and type, with no conversion.

Example:

console.log(0 == "0");   // true  (string converted to number)
console.log(0 === "0");  // false (different types)

Best practice: always use === unless you have a specific reason to allow type coercion.

Section 3: HTML/CSS Interview Questions and Answers

Q12. What is CSS specificity and how is it calculated?

Answer: Specificity decides which CSS rule “wins” when two rules target the same element. The general priority order is:

  1. Inline styles (highest)
  2. ID selectors (#header)
  3. Classes, attributes, pseudo-classes (.nav, [type=text], :hover)
  4. Element selectors (div, p)

Example:

p { color: blue; }            /* specificity: 0,0,0,1 */
.intro { color: green; }      /* specificity: 0,0,1,0 — wins over above */
#main p.intro { color: red; } /* specificity: 0,1,1,1 — wins over both */

Q13. Flexbox vs Grid — when should you use each?

Answer:

  • Flexbox — best for one direction at a time (a row of nav links, or a column of buttons).
  • Grid — best when you need rows AND columns together (a full page layout, a dashboard).

Example: A navigation bar with logo-left, links-center, button-right → use Flexbox. A product listing page with a sidebar, header, main content grid, and footer → use CSS Grid.

Q14. Why does semantic HTML matter for an AEM component developer?

Answer: AEM components render into real, public-facing pages. Semantic tags (nav, header, article, section) help search engines understand page structure (better SEO) and help screen readers navigate the page (accessibility compliance — often a client contract requirement).

Example: Instead of <div class="nav">, using <nav> tells both Google and assistive technology exactly what that block is, without extra ARIA work.

Section 4: Leadership & Scenario-Based Questions

Q15. A junior developer’s pull request has architectural issues, but the deadline is tomorrow. What do you do?

Answer: Split the issues into two buckets — “must-fix” (security, broken patterns, data integrity) and “can wait” (style, minor refactors). Get the must-fixes resolved before merging, log the rest as follow-up tickets, and schedule a short pairing session afterward to explain why the pattern matters — so it’s a learning moment, not just a rejected PR.

Q16. How do you plan a large-scale AEM version upgrade or cloud migration?

Answer:

  1. Audit existing custom code against Adobe’s deprecated-API list.
  2. Run AEM’s Code Quality/Cloud Readiness tools to flag risky code.
  3. Categorize components: reusable as-is, needs refactor, or retire.
  4. Migrate low-risk shared components first, high-risk business logic last.
  5. Run a parallel test environment before full cutover, with a clear rollback plan.

Final Tips for the Interview

  • Always explain your answer with a small example — interviewers remember candidates who can simplify, not just recite definitions.
  • For a Senior Technical Lead role, expect follow-up questions on team decisions, not just code — be ready with one or two real project stories.
  • Brush up on recent AEM Cloud Service changes, since Adobe updates release notes frequently.