Salesforce Marketing Cloud Interview Questions & Guide

Look for a clear mental model: Email Studio (email creation/sending), Journey Builder (orchestration), Automation Studio (scheduled/triggered backend automation), Contact Builder (the data model — data extensions, contacts, attributes), Mobile/Advertising/Web studios for channels. The signal is understanding that the data layer underpins everything.

A Data Extension is a relational table (typed columns, primary keys, can be related to others); Lists are the older, flat subscriber model. Strong candidates explain why DEs are preferred for scale and segmentation, sendable vs non-sendable DEs, and the role of the Subscriber Key.

It's the unique identifier for a subscriber across the account. Getting this wrong causes duplicate contacts and broken suppression. Senior candidates discuss choosing a stable key (often a CRM ID rather than email) and the consequences of changing it later.

Look for AMPscript and dynamic content: %%=Lookup()=%% / LookupRows() to pull related data, conditional blocks, and dynamic content rules. The strongest answers mention falling back gracefully when data is missing and testing with multiple subscriber profiles.

AMPscript is the primary inline scripting language for email/landing pages; SSJS (server-side JavaScript) handles more complex logic and API calls; GTL (Guide Template Language) is used for content blocks/handlebars-style templating. Knowing when to reach for SSJS vs AMPscript is the senior signal.

Strong answers: store recommendations in a Data Extension keyed by subscriber, use LookupRows() + a loop in AMPscript to render them, and handle the empty case. Bonus for mentioning Einstein recommendations as an alternative and the trade-offs.

You're looking for comfort with SFMC's system data views (_Open, _Click, _Sent, _Subscribers) and a join/anti-join: opens in the window, excluded where a click exists for the same job/subscriber. Exact syntax matters less than knowing the data views exist and how tracking data is structured.

A SQL Query Activity writing to a target DE on a schedule, chained with import/file-drop or filter activities. Strong candidates mention overwrite vs update vs append, primary keys to avoid duplicates, and error handling/notifications.

Filtered DEs are a UI-based subset that auto-refreshes from a source DE; SQL Query Activities are more powerful (joins, aggregation, multiple sources) but run on a schedule via Automation Studio. Knowing when the simpler filtered DE is enough shows good judgement.

The entry source defines how contacts enter (DE, API event, etc.); criteria/filters refine who proceeds. Re-entry settings determine whether a contact can re-enter. Mistakes here cause contacts to get stuck or double-messaged — a great candidate raises that risk unprompted.

Look for: suppression logic, a central send-frequency/contact-fatigue strategy, Einstein Engagement Frequency, and journey entry exclusions. The mature answer treats cross-journey governance as a design problem, not a per-journey fix.

Strong answers walk through authentication (SPF/DKIM/DMARC, dedicated IP/SAP warming), list quality and engagement, content/spam-trigger checks, and using Return Path/seed tests. They separate reputation issues from content issues methodically.

Gradual volume ramp starting with the most engaged subscribers, monitoring bounces/complaints, and not blasting the full list day one. Demonstrates that they've actually launched a sending program.

Audit the data model in Contact Builder, map active automations and journeys, review sending domains/IPs and deliverability, and identify business-critical sends before changing anything. Methodical discovery over heroics.