Adobe Product Manager — Interview Questions

Adobe Product Manager Interview Questions

Product management at Adobe means owning software that professionals have used daily for two decades and that a new generation expects to use free in a browser tab. Every meaningful decision sits between those two audiences. Do you optimise Photoshop for the retoucher who knows four hundred keyboard shortcuts, or for the fifteen-year-old who wants a background removed in one click? Do you price Firefly generations to grow adoption or to cover GPU cost? Adobe PM interviews are built almost entirely out of that tension, and the strongest candidates refuse to pretend it resolves cleanly.

Adobe's Interview Process for Product Managers

The loop is typically four stages over four to six weeks: a thirty-minute recruiter screen, a forty-five to sixty-minute hiring manager screen that is largely behavioural and focused on why Adobe and why this team, an onsite of four back-to-back interviews of roughly thirty minutes each with senior PMs and cross-functional partners, then a decision over one to two weeks.

The onsite mixes formats. There is usually a product sense round, a panel round that can be heavily behavioural and communication-focused, and in many loops a case or presentation round where you walk several interviewers through a product or go-to-market strategy — candidates report being asked for a detailed two-year roadmap for a specific product. A bar raiser from outside the hiring team may sit in, and the final decision is made by a hiring committee rather than a single manager, so your performance is weighted across product sense, data fluency, collaboration and communication rather than carried by one strong round.

One consequence of the committee model worth planning for: a spiky performance is riskier at Adobe than at companies where a determined hiring manager can push a candidate through.

Question 1: One quarter, no headcount, no new features

Adobe Express is losing first-time creators to Canva. Signups are healthy; second-session return is not. You have one quarter, no new headcount, and you are not allowed to ship a new feature. What do you change?

Why interviewers ask this

The constraints are the question. Removing headcount and features strips away every answer that involves building something, which forces the candidate onto positioning, onboarding, defaults and funnel mechanics. Weak candidates immediately propose more templates or an AI feature and have nowhere to go once reminded of the constraint. Strong candidates diagnose before prescribing and pick one lever they can actually move.

Example strong answer

I would start by refusing to accept "losing to Canva" as the problem statement, because it names a competitor rather than a failure. Healthy signups with weak second-session return tells me acquisition works and the first session does not deliver enough value for someone to come back. That is a much more actionable framing.

So the first thing I would want is the shape of the first session. Specifically: what fraction of new users produce any finished artifact at all, and where the rest stop. My prior, from how these products usually behave, is that a large share never export anything, and that the drop is concentrated in the first two or three minutes — at template choice, at the first edit, or at the moment they realise they need an asset they do not have. I would segment that by intent where I can infer it, because a small business owner making a promotional post and a student making a presentation slide fail for different reasons.

Once I know where they stop, I would pick exactly one lever, because a quarter with no new headcount can do one thing properly or four things badly.

If the drop is at template choice, the problem is that the gallery asks a novice to make a design decision before they have any context, which is a bad first request. The fix without new features is to change what we show and how we ask: replace a wall of templates with a short intent question and a much smaller, curated set. That is configuration and content, not engineering.

If the drop is at first edit, the problem is that the canvas is a professional-grade surface presented to someone who has never used one. The fix is defaults — what is preselected, what panels are open, what the first click does. Again, mostly configuration.

If the drop is at export, the problem is friction at the moment of highest intent, often an account or paywall gate. That is the cheapest thing on this list to fix and the highest leverage, because those users have already done the work.

I would also spend part of the quarter on something that is not the product at all: the gap between what our acquisition channels promise and what the first session delivers. If people arrive from a search for "free flyer maker" and land on a general-purpose canvas, the mismatch produces exactly this pattern — good signup, bad return — and no amount of onboarding polish fixes a promise problem. Aligning landing pages to the entry intent is a content change my team can make without engineering.

For measurement, I would set the target on second-session return within seven days for new signups, with time-to-first-export as the leading indicator so I get a read in days rather than waiting a week per cohort. I would run every change as an experiment rather than shipping to everyone, because with no headcount I cannot afford to be wrong slowly.

What I would tell leadership at the start: the honest ceiling here is meaningful but not dramatic. Configuration and positioning changes typically move an activation number by a relative fraction, not a multiple. If the expectation is that we close the gap with Canva in a quarter without building anything, that expectation is wrong and I would rather say so in week one than in week twelve.

Follow-up questions

Your data shows the drop is spread evenly across the whole first session with no single cliff. Now what?
You get the headcount after all, mid-quarter. Does your plan change, or do you finish what you started?

Question 2: Design something for Acrobat mobile

Acrobat on mobile is used heavily for one thing: signing documents. Most sessions are a person receiving a PDF by email, opening it, signing, and sending it back. Design an improvement to that flow. Tell me who it is for and how you would know it worked.

Why interviewers ask this

This is the product sense round. Adobe interviewers are looking for user intuition and the ability to turn an ambiguous need into a structured, feasible solution. Weak candidates jump to a feature list. Strong candidates pick a specific user, find the real friction in a flow they have actually thought about, and scope to something shippable.

Example strong answer

I would narrow before designing, because "people who sign PDFs on phones" is several different users with different problems.

The one I would pick is the reactive signer: someone who did not plan to sign anything today, is doing it on a phone because that is where the email arrived, and wants it to take under two minutes. This is the highest-volume case and, importantly, it is the case where Adobe's competition is not another PDF app — it is the recipient giving up and doing it later on a laptop, which is where the document goes to die.

Walking that flow honestly, the friction is not the signature itself. It is everything around it. The user has to get from an email attachment into Acrobat, which on iOS often means a share sheet they use rarely. They have to find where to sign in a document that may be eleven pages long. They have to fill fields that are not marked as fields because the sender made the PDF in Word. They have to place a signature at a precise point on a page that is zoomed out to illegibility on a phone screen. Then they have to get the signed file back to the sender, which usually means another share sheet.

The single highest-value improvement, in my view, is automatic detection and sequencing of the things that need the user's input. When the document opens, we identify signature lines, date lines and blank fields — including in documents with no form fields, using layout heuristics and, where available, a model — and present them as an ordered checklist. The user taps Next, we scroll and zoom to the right spot at a readable size, they provide the input, we advance. The document becomes a short guided flow rather than a navigation problem.

Two supporting pieces make it work. First, remembering the user's signature, initials and common values like name and date so the second and subsequent documents are nearly zero-input. Second, closing the loop on return: after the last field, a single primary action that replies to the original email with the signed file attached, rather than dropping the user into a generic share sheet. That last step is unglamorous and I suspect it is where a meaningful share of abandonment happens.

I would scope the first release to documents where field detection is confident, and fall back to today's manual flow when it is not, because a mis-detected field that puts a signature in the wrong place is far worse than no detection. I would rather cover seventy percent of documents excellently than all of them unreliably.

For measurement, the primary metric is completion rate for sessions that begin with a document open, and the key secondary is time from open to signed. I would also watch the fallback rate as a quality signal on detection, and I would track corrections — how often a user moves a signature we placed — because that tells me whether the automation is trusted. If corrections are high, the feature is creating work rather than removing it, and I would rather learn that from the metric than from reviews.

Follow-up questions

Detection puts the signature block in the wrong place on a legal document and the user does not notice. How do you design against that?
The sender is an enterprise using a different e-signature vendor. Does your flow still make sense?

Question 3: Pricing generative credits

Firefly generations cost real money — GPU time per image. Right now paid Creative Cloud plans include a monthly credit allowance, and when users run out, generation slows rather than stops. Sales says the allowance is a blocker in enterprise deals. Finance says heavy users are unprofitable. Design the packaging. You own the recommendation.

Why interviewers ask this

Adobe is a subscription business where a new variable cost has landed inside a fixed-price product, and PMs are expected to reason about unit economics rather than defer to finance. Weak candidates propose a tier list. Strong candidates start from the usage distribution, distinguish the enterprise problem from the consumer problem, and pick a model whose failure mode they can live with.

Example strong answer

Before proposing any packaging I would want one thing: the distribution of monthly generations per user, by plan and by segment. Almost every decision here depends on its shape. If it is the usual heavy-tailed pattern, then a small minority drive most of the cost, most users never approach the allowance, and the design problem is entirely about the tail. If usage is more uniform, the economics are structurally different and the answer changes.

Assuming the heavy tail, I would separate the two complaints, because they are not the same problem and a single change will not fix both.

Finance's problem is a small number of very heavy users. The clean solution is not to raise prices for everyone. It is to make the tail pay for itself: keep the included allowance generous enough that the vast majority never think about it, and offer credit top-ups for those who exceed it, priced above marginal cost. That converts the unprofitable tail into a revenue line and leaves the median user's experience untouched. I would strongly prefer this to lowering allowances, which taxes everyone to fix a problem caused by few and reads externally as a takeaway.

Sales' problem is different and is mostly about predictability, not quantity. Enterprise buyers dislike a per-seat allowance because they cannot forecast whether their design team will blow through it, and an unpredictable overage is harder to get through procurement than a higher fixed price. The fix is pooling: sell credits at the organisation level rather than per seat, so light users subsidise heavy ones inside the account and the buyer sees one predictable number. I would pair that with usage visibility for the admin, because the objection is fundamentally about lack of control, and a dashboard that shows consumption resolves more of it than extra credits would.

On the current behaviour of slowing rather than stopping, I would keep the principle and sharpen the communication. Slow generation is a better failure mode than a hard wall because it degrades rather than blocks, but only if the user understands what is happening. Today I suspect it reads as the product being broken. I would make it explicit, with the remaining allowance visible before it becomes urgent rather than at the moment of failure.

The thing I would be careful about is the message the packaging sends. Adobe has spent years telling customers that generative features are included in Creative Cloud. Any change that reads as metering something previously unlimited carries a reputational cost that does not show up in the pricing model. So I would sequence it: introduce pooling and top-ups as additions first, gather usage data on the new structure, and only revisit included allowances later, with evidence and with notice.

For validation, I would not launch this globally on a spreadsheet. I would test the top-up pricing on a subset to learn the actual conversion rate at the allowance boundary, because the willingness of a user to buy more credits at the moment they run out is the single most uncertain input in the whole model, and it is the one that determines whether the tail becomes profitable or simply churns.

Follow-up questions

Credit top-up conversion comes in at a third of your assumption. What do you change first?
A competitor announces unlimited generation at a lower price point. Does your recommendation survive?

Question 4: Measuring whether Photoshop on the web is working

Photoshop on the web has been available for a while. Leadership asks a simple question: is it working? Give me the metric framework you would present, and tell me what number would make you say we should stop investing.

Why interviewers ask this

Adobe evaluates PMs on being data-driven, and the second half of the question is the real test. Weak candidates produce a dashboard of everything. Strong candidates pick a small number of metrics tied to an explicit hypothesis about why the product exists, and are willing to name a kill condition.

Example strong answer

The question is unanswerable until we agree on what Photoshop on the web is for, because there are at least three strategic rationales and each implies a different measurement.

It could be an acquisition play — bring in people who would never install a large desktop application, and convert some to full Creative Cloud. It could be a retention and access play — let existing subscribers work from any machine, reducing friction and churn. Or it could be a defensive play against browser-native competitors. These are not mutually exclusive but they cannot all be the primary rationale, and measuring against the wrong one produces misleading conclusions.

I would push leadership to name the primary, and I would guess it is acquisition with a strong secondary of access. Assuming that, here is the framework I would present, deliberately short.

The top-line metric is incremental new Creative Cloud subscribers attributable to web. Not web users, not web sessions — subscribers who would not otherwise have converted. That word "incremental" is doing all the work, and it is why I would want a holdout or a geo-based test rather than an attribution model, because self-reported and last-touch attribution will systematically overcredit the newest surface.

Below that, three supporting measures. First, activation on web: the share of new web users who complete a meaningful edit, which tells me whether the product is good, separately from whether it sells. Second, cross-surface behaviour among existing subscribers: how many use web at all, and whether subscribers who do have better retention than matched subscribers who do not — matched, because heavy users adopt everything and the raw comparison flatters web. Third, cost: infrastructure cost per active web user, since running Photoshop in a browser is not free and the unit economics have to clear.

I would explicitly exclude vanity measures. Total web sessions, monthly active web users in isolation, and feature parity percentage are all things people will ask for and none of them answer the question.

On the kill condition, I would name it concretely rather than gesture at it. I would say: if after four full quarters the incremental subscriber number is below the threshold that makes the investment break even against its fully loaded cost, and activation on web is flat or declining across cohorts rather than improving, then the hypothesis is not working and we should either narrow the product to a specific job — say, review and light edits for collaborators — or stop. Flat activation across successive cohorts is the signal I would weight most heavily, because it means the team's iterations are not compounding, and that is usually a product-market fit problem rather than an execution problem.

I would also say what would make me argue to keep investing despite weak top-line numbers: if web is disproportionately reaching a segment we cannot otherwise reach — students, emerging markets, users on managed devices — then it may be an option on a future market rather than a revenue line today, and that is a legitimate reason to fund it. But I would want that stated as the rationale explicitly, not used as a retroactive defence when the primary metric disappoints.

Follow-up questions

Your holdout test is not feasible because web is already fully launched. How do you get an incrementality read anyway?
Activation on web is strong but conversion is weak. What does that tell you, and what do you do?

Question 5: A two-year roadmap, presented to a panel

Take Adobe Express. Present us a two-year roadmap. Assume a team of roughly forty engineers, designers and PMs, and assume the competitive picture stays broadly as it is today.

Why interviewers ask this

Candidates report being asked for a detailed multi-year roadmap in Adobe's case or presentation round, often in front of several interviewers at once. It tests structure, sequencing and communication as much as product judgment. Weak candidates present a feature list sorted by quarter. Strong candidates start from a thesis, sequence around dependencies and learning, and are explicit about what they are choosing not to do.

Example strong answer

I would open with the thesis, because a roadmap without one is just a backlog with dates.

My thesis for Express is that its durable advantage is not being a better design tool than Canva — that is a feature race Express is unlikely to win on volume of templates. It is being the only design tool that is natively connected to where professional creative work already lives: Creative Cloud libraries, brand systems, Firefly, and the assets an organisation already owns. So the strategy is to stop competing on the general-purpose canvas and win the specific job of "make on-brand content quickly, using assets that already exist."

That thesis drives the sequencing.

Year one, first half, is about proving the wedge with the audience most likely to feel it: small marketing teams inside organisations that already have Creative Cloud. The work is brand kit ingestion and enforcement — pull an organisation's fonts, colours and logos in, and make it structurally hard to produce something off-brand. Paired with that, the activation work I would want regardless of strategy: the first session has to produce a finished artifact quickly. I would set a measurable goal for both and treat the half as a validation of the thesis rather than a commitment to it.

Year one, second half, depends on what the first half showed. If the wedge is working, this is where we build the collaboration loop around it: request, review and approve flows, so the designer who owns the brand system stays in control while non-designers produce the volume. That is the multiplayer motion that makes the product spread inside an account rather than sitting with one user.

Year two, first half, is distribution and scale. Integrations into where the content actually goes — social scheduling, marketing automation, the enterprise content supply chain that Adobe already sells into. This is the half where Express stops being a standalone tool and starts being a step in a workflow, which is what makes it hard to remove.

Year two, second half, I would deliberately leave partly unallocated. Two years out in a market moving this fast, committing every engineer to a plan written today is not confidence, it is a failure to admit uncertainty. I would name the two or three bets I expect to choose between and the evidence that would decide.

On what I am not doing, and I would say this explicitly to the panel: I am not chasing template count, I am not building a general-purpose video editor, and I am not pursuing the individual consumer market where acquisition is expensive and willingness to pay is low. Each of those is defensible and each would consume the team.

On risk, the biggest one is that the wedge does not hold — that brand enforcement is a nice-to-have rather than a reason to switch. I would test that early and cheaply with a small set of design partners in the first quarter rather than discovering it in month nine.

I would close by making the resourcing visible: roughly how the forty people split across the wedge, activation, and platform work each half, because a roadmap that does not show what it costs is not a plan.

Follow-up questions

Six months in, brand enforcement is loved by designers and ignored by the marketers who were supposed to use it. What do you do?
The panel disagrees with your thesis. Convince us, or tell us what evidence would change your mind.

Question 6: Removing something people love

An old Photoshop feature is used by about 0.4 percent of monthly users. It is expensive to maintain, blocks a rewrite the team needs to do, and the people who use it use it constantly and are vocal. Engineering wants it gone. Make the call.

Why interviewers ask this

Deprecation is a real and recurring problem for a product with Photoshop's age, and it is a clean test of whether a PM will make an unpopular decision with a plan rather than avoid it or make it carelessly. Weak candidates either defend the users absolutely or defer to engineering. Strong candidates interrogate who the 0.4 percent are before deciding anything.

Example strong answer

Zero point four percent is not a small number in absolute terms for a product this size, and more importantly, percentage of monthly users is the wrong statistic to decide on. I would want three other things first.

Who they are. If that 0.4 percent skews heavily toward long-tenured, high-value subscribers, or toward a specific professional segment such as print production or scientific imaging, then the revenue and advocacy at risk is far larger than the usage share suggests. Photoshop's reputation is carried disproportionately by professionals who teach, publish and set standards, and losing them is not proportional to losing 0.4 percent of seats.

What the feature actually does for them. Vocal, constant use of an obscure feature usually means it sits in the middle of a workflow with no substitute. If there is a good substitute already in the product and they simply have not moved, that is a migration problem. If there is no substitute, removing it does not remove the workflow — it removes those users.

What removal actually buys. "Blocks a rewrite" needs a number. Is it two engineer-months of unblocking, or is it a year? The decision is completely different at each end, and engineering's estimate of the cost of keeping something is often an estimate of their frustration with it.

With those, my default call would be: do not remove it outright, and do not keep it as-is. The middle path is to build the minimum viable replacement path first, migrate the users, then remove. Concretely: identify what the workflow needs, deliver it through whatever the new architecture supports even if it is less capable than the original, reach out directly to the identified heavy users — at 0.4 percent this is a contactable population, which is unusual and worth exploiting — and get them onto it with real support. Then deprecate on a published timeline with the replacement already in their hands.

If the investigation shows there is no viable replacement and the rewrite is genuinely blocked for a year, then I would take the removal, but I would take it deliberately: long notice, a clear explanation of why rather than a changelog line, a supported export path so no one's existing files become unopenable, and where possible a way for the workflow to continue outside the product, such as a script or a plugin. What generates lasting damage in these situations is rarely the removal itself. It is users discovering it without warning and concluding that Adobe does not care about professionals — a narrative that is already available and cheap to trigger.

The one thing I would refuse to do is keep it indefinitely without deciding. A feature that is too expensive to maintain and too politically hard to remove decays quietly, breaks in an update, and produces the worst outcome: the users lose it anyway, and they lose it as a bug rather than as a decision.

Follow-up questions

The heavy users tell you the replacement is unusable and refuse to migrate. Do you still deprecate?
What would change your call if the 0.4 percent were mostly trial users rather than long-tenured subscribers?

Question 7: Engineering says it is not safe to ship

You are two weeks from launching a generative feature that has been announced publicly with a date. Your engineering lead tells you the safety filters are catching most problematic outputs but not all, and they are not comfortable shipping. Marketing has bought placements. Your director asks what you want to do. Walk me through the conversation.

Why interviewers ask this

This is the behavioural and panel round, and it is about judgment under pressure with a real reputational asymmetry. Weak candidates either cave to the date or refuse to ship without engaging with the business cost. Strong candidates convert a vague discomfort into a specific, measurable question and then make a call they can defend.

Example strong answer

My first move is to make "not comfortable" concrete, because I cannot make a decision on a feeling and my engineering lead deserves better than to have their instinct either dismissed or accepted uncritically.

The questions I would ask: what is the measured failure rate, on what evaluation set, and what do the failures look like. There is an enormous difference between a filter that occasionally passes something mildly off-tone and one that can be induced to produce content involving real people, protected groups, or anything approaching the categories that end up in a news story. The first is a quality problem I can ship with and improve. The second is not a launch decision at all — it is a line.

I would also ask whether the failures are random or adversarial. If they only occur under deliberate prompting by someone trying to break it, that changes the risk profile, though at Adobe's scale I would assume someone will try on day one and I would not treat adversarial-only as safe.

Having categorised the risk, I would look for options between shipping and not shipping, because that binary is usually false. Ship to a limited audience — a percentage rollout, or a beta with an explicit label — which gives real-world signal at a fraction of the exposure. Ship with tighter filters that over-block, accepting a worse experience for a safer one, and loosen as confidence grows. Ship with the failing category disabled specifically. Ship with human review in the loop for the highest-risk paths. Any of these lets us honour a date with something real while bounding the downside.

Then I would take a position rather than presenting my director with a menu. If the failure mode is reputational and involves the categories that make headlines, my recommendation is that we do not ship on the date, and I would say so plainly, with the reasoning. Adobe sells to enterprises whose entire purchase decision rests on the content being commercially safe; a single bad output that circulates costs far more than a delayed launch, and it costs it in exactly the segment that pays us most. If the failure mode is quality rather than safety, I would recommend shipping the limited version and being explicit in the product that it is early.

On the marketing spend, I would engage with it honestly rather than dismiss it. It is a real cost and my director will have to answer for it. But I would frame the comparison: the placement cost is knowable and bounded, and the cost of the bad-output scenario is neither. I would also involve marketing early rather than delivering a decision to them, because a two-week notice lets them reposition the campaign around a beta, and a two-day notice does not.

The last thing I would do is make sure the decision does not repeat. If we found this two weeks out, our evaluation process ran too late. I would want the safety evaluation as a gate earlier in the cycle with a defined threshold agreed before the date was announced publicly, so the next launch does not put a director in this position.

Follow-up questions

Your director overrules you and ships. What do you do in the following week?
The engineering lead's discomfort turns out to be based on ten hand-picked examples with no systematic evaluation. Does that change your answer?

Question 8: Competing with free and open

Open-weight image and video generation models are improving quickly and are free to run. A designer with a decent GPU can generate images without paying anyone. What does that mean for Adobe, and what would you do about it as a PM on Firefly?

Why interviewers ask this

Adobe evaluates industry judgment alongside product sense, and this is the strategic question the company actually faces. Weak candidates either dismiss open models or predict doom. Strong candidates identify what buyers actually purchase, which is rarely the raw capability.

Example strong answer

I would start by being clear that the raw generation capability is commoditising, and I would not build a strategy that assumes otherwise. Any plan whose premise is that Adobe's model stays meaningfully better than freely available ones is a plan with a short shelf life.

But raw capability is not what most of Adobe's customers are buying, and I think that is the crux. A designer at an agency producing work for a client is not primarily buying pixels. They are buying: legal indemnification and commercial safety, which matters enormously when the output goes into a campaign; integration into the tools where the rest of the work happens, so generation is a step in a file rather than a separate app producing assets to import; consistency, meaning the ability to produce a hundred images that share a style and a brand; provenance and content credentials, which enterprise and media buyers increasingly require; and not having to manage a GPU.

Each of those is a place where an open model on a local machine is genuinely worse, and none of them get better as the open models improve. So my strategic answer is that Adobe should compete on the workflow and the guarantees, not on the benchmark.

Concretely, as a PM on Firefly, that means a few things. I would invest in the parts of the product that are hard to replicate: style and character consistency across a body of work, structured control so a professional can direct the output precisely rather than reroll prompts, and deep integration into Photoshop, Illustrator and the Creative Cloud asset graph so generation operates on the user's own material. I would treat commercial safety and content credentials as first-class product features with visible surface area, not as legal footnotes, because that is the thing an enterprise buyer's procurement team is actually evaluating.

I would also consider whether fighting the open ecosystem is the right posture at all. There is a defensible version of this where Adobe supports bringing other models into its workflow — the customer gets model choice, Adobe keeps the workflow, the file format, the asset library and the relationship. That trades a defensible claim about model quality for a more defensible position in the workflow layer. It is worth serious analysis rather than reflexive rejection, though I would want to understand the indemnification implications before advocating it, since the commercial safety guarantee is harder to make about a model Adobe did not train.

The thing I would watch as a leading indicator is not benchmark scores. It is whether professional users start doing generation outside Adobe tools and importing the results. That behaviour, if it grows, is the signal that the workflow moat is leaking, and it would show up in asset import patterns well before it shows up in revenue.

Follow-up questions

Supporting third-party models undermines the indemnification story. How would you resolve that?
If open models reach parity on consistency and control within eighteen months, which part of your plan is left?

Preparation tip

Adobe's hiring committee weighs performance across product sense, data fluency, collaboration and communication rather than letting one strong round carry you, so the most useful preparation is closing your weakest dimension rather than sharpening your best. In practice that means: if you are strong on product sense, spend your prep time on metrics and on articulating trade-offs cleanly under time pressure, because the onsite rounds are only about thirty minutes each and a rambling answer costs you the round regardless of its quality. And in every answer, say what you are choosing not to do. Adobe products serve professionals and beginners simultaneously, and the interviewers are looking for candidates who can hold that tension explicitly rather than answering as if one audience did not exist.

Back