Adobe sells most of its creative and document software by subscription, so analysts study how people try an app, start paying, keep using it and sometimes leave. The data comes from apps that may be used offline for days and from very different users, from students to studios. Prepare to discuss trial conversion, signs that a subscriber is drifting away, measuring new features and usage data that arrives late. What to show here: careful reading of how subscribers really use the tools. Each question below has what the interviewer is checking, an answer frame and a sample spoken answer to adapt.
How Adobe hires, in its own words, and its questions for every job →
“The team had built a sharing feature and believed it was popular because of praise on social media. When I looked at usage, a small group used it heavily and most people never opened it. Before saying anything, I checked that the tracking event fired properly, by using the feature myself and finding my own events. Then I showed the team the split, along with the good news: those who did use it stayed subscribed longer. I suggested the problem was discovery, not value. The team moved the entry point into the export step, and your result.”
Weak answers announce that the feature failed without checking the tracking or offering any path forward.
“I had found that new users who finished one export in their first session were far more likely to return. My first draft was a table of rates by group, and I could see it would lose the design team. So I told it as a story of two people: one who opens the app, gets lost in panels and leaves, and one who exports a simple picture and comes back the next day. I showed one chart only. The designers asked sharp questions about what counted as an export, which improved my definition. They then redesigned the first screen, and your result.”
Weak answers blame the audience for not understanding or show every chart they made.
“I would measure by cohort: of the people who started a trial in a given week, what share became paying subscribers by the end of the trial window. The window matters, because counting too early misses late converters. I would split the result by how they arrived, by country and by which app, since a student trying a photo app behaves differently from a studio. I would be careful not to celebrate conversions that cancel right after the first payment, so I would add a second measure: still subscribed some months later. I would also check how many trials were ever opened at all.”
Weak answers divide all subscribers by all trials with no cohort or window, or stop at the first payment.
“I would start from the subscriptions table and keep accounts that are active and paying. Then I would LEFT JOIN to the app-open events, with the date filter placed inside the join condition, and keep rows where no event was found. Putting the date filter in the WHERE clause instead would quietly turn it into an inner join and drop exactly the people I am looking for. I would exclude subscribers who joined within the period, since they have not had a full month. I would also remember that someone working offline sends no events, so I would treat the list as likely inactive, not certainly inactive.”
Weak answers use an inner join, which can never return people with no activity, or ignore offline use.
“Counting how many people tried the feature tells me about curiosity, not value. I would look at what happens next. Of the generated results, how many are kept in the document, how many are deleted straight away, and how many end up in a file that is exported? Then I would look at repeat use: of the people who tried it in their first week, how many use it again in later weeks. A curve that falls and then flattens at a healthy level suggests real value. Where possible, I would compare with similar users who did not yet have the feature.”
Weak answers report the number of people who clicked the feature once and call the launch a success.
“Every event should carry two times: when it happened on the device and when our servers received it. Reports should be built on the first, but that means recent days keep growing as late events come in. I would measure how long it takes for a day to become nearly complete, and mark any day younger than that as provisional in dashboards. Otherwise every week looks like a drop at the end. I would also watch for device clocks that are wrong, by flagging events that claim to be from the future. When numbers are restated, I would say so openly.”
Weak answers use the arrival time as the event time or treat the most recent days as final.
“First I would check whether the rise is real. I would separate people who chose to cancel from subscriptions that ended because a payment failed, since a problem with one local payment method can look like a wave of cancellations. Then I would narrow it down: is it one plan, new subscribers or long-standing ones, one app? I would line up the timing against anything that changed in that country that week, such as a price change, a renewal reminder email or an app release. I would also read the reasons people gave when cancelling. Then I would report what I know, what I suspect and what to check next.”
Weak answers jump to one explanation without splitting chosen cancellations from failed payments.
“I am interested in behaviour that unfolds over months. With subscription software, the question is not only whether someone bought, but whether the tool became part of how they work. That is hard to measure, because creative work is irregular: a person may do nothing for two weeks and then work all night. In your project I analysed repeat use, and I enjoyed defining what active really means. Adobe sells tools like Photoshop and Acrobat by subscription to very different people, from students to large teams, so the segments are rich. I want to learn to measure whether a feature helps someone create.”
Weak answers say they like data in general and cannot name a question particular to subscriptions or creative tools.
No figures on this page: pay depends on the level, the city and the offer in front of you. When the offer comes, the free salary negotiation script helps with that part.
ClapAssist is an AI interview assistant for Mac and Windows. It listens to the interview on your computer and shows you what to say, in short lines you can read while you talk. Your live interview audio and screen are never stored. Your resume and notes are saved to your account so the app fills them in on any computer. It is hidden from screen share on every plan, including Free; only you can see it.