Back

CRED — Product Analyst Interview Questions

The Product Analyst at Prefr owns measurement — not just reporting what happened, but forming a clear, opinionated view on what it means and what should happen next. You are the analytical voice in every PM conversation, the person who turns a vague "the numbers look off" into a specific diagnosis and a testable fix. The interview tests whether your SQL can hold up, whether your experiment intuition is sound, and whether you can communicate a recommendation to someone who has 10 minutes and no patience for ambiguity.

CRED's Interview Process for Product Analyst

SQL and Python practical assessment on real fintech scenarios, a product analytics case (typically a conversion funnel investigation or an A/B test result requiring interpretation), and a stakeholder communication round where you present findings to a simulated PM under time pressure. Fintech or BFSI exposure is a strong plus.

Question 1: Feature Impact Measurement (L0/L1/L2)

Prefr launched a new loan application UI on June 1. You're asked to measure its impact. Walk through the L0, L1, and L2 metrics you'd track and how you'd structure the full measurement plan.

Why interviewers ask this

Directly maps to the L0/L1/L2 framework called out in the job description and tests whether candidates understand layered measurement — the difference between a business outcome, a product flow metric, and a feature-level event — versus looking at one top-line number and concluding something worked or did not. Weak candidates describe tracking impressions and clicks. Strong candidates sequence the metrics logically, flag the measurement readiness requirements before launch, and define what a meaningful change looks like at each layer.

Example strong answer

The measurement plan needs to be in place before June 1, not after. The most common failure mode in product analytics is launching a feature and then deciding what to measure — by which point the data instrumentation is either missing or unreliable. So my first action would be a data readiness audit a week before launch: confirm with engineering that every L2 event is tagged and firing correctly in staging, and run a spot-check on the data pipeline to confirm events are landing in the warehouse without schema errors.

With that confirmed, here is how I would structure the measurement at each layer. L0 is business outcomes: disbursement rate (completed loans divided by applications started), revenue per application, and approval rate. These are the metrics the risk lead and CFO care about. L0 metrics require a 30-day measurement window because disbursement lags application by days or weeks depending on the user's document submission pace — a two-week read on L0 will systematically undercount completions and produce a misleading early conclusion.

L1 is the product flow: application start rate, step completion rates across each screen in the funnel (personal details, bureau consent, offer screen, accept and submit), and drop-off rate at each step. I would track L1 daily for the first two weeks and flag any step where drop-off changes by more than 5 percentage points relative to the pre-launch baseline. L1 is where I would identify if the new UI is helping or hurting specific steps, independent of the overall conversion rate.

L2 is feature-level micro-events: time spent on each screen, form field error rates (how often users submit incorrect data formats on the personal details screen), help tooltip clicks, back-button tap frequency, and any UI-specific interactions like the new eligibility calculator if one was introduced. L2 is diagnostic — it tells me why an L1 drop-off is happening, not just that it is.

Reporting cadence: weekly L1 summary with a red/amber/green status per funnel step, a day-14 L0 interim read with a clear caveat that the 30-day window is not yet complete, and a final L0 report at day 30. For the PM, I would present the L1 funnel side-by-side with the pre-launch baseline, not just the new numbers in isolation.

Follow-up questions

  • The approval rate improved by 4% but disbursement completion dropped by 6%. What is your interpretation and what do you investigate?

Question 2: Funnel Drop-off Investigation

The bureau consent step in the loan application has a 38% drop-off rate — up from 24% four weeks ago. A PM says "users are scared of sharing their credit data." How do you respond?

Why interviewers ask this

Tests whether the analyst separates hypothesis from data before accepting a PM's narrative and acting on it. Weak candidates agree with the PM's framing and suggest adding copy explaining why bureau data is safe. Strong candidates treat the PM's hypothesis as one of several, run the diagnostic before accepting any of them, and flag that a jump from 24% to 38% over 4 weeks looks more like a technical event than a gradual behaviour shift.

Example strong answer

The PM's hypothesis might be right, but a 14 percentage point jump in drop-off over 4 weeks is a large, fast change — and in my experience, gradual shifts in user trust or behaviour do not move that quickly. A change of this size and speed is more consistent with a technical event or a product change than with an organic shift in user sentiment. So before accepting the behavioural hypothesis and recommending a UX intervention, I would run a structured diagnostic.

The first question is: did anything change at the bureau consent step in the last 4 weeks? I would pull the deployment log for that specific screen and check for any UI changes, copy changes, new consent language (especially anything required by a regulatory update), or changes to the API call that fetches bureau data. If drop-off spiked on a specific date rather than climbing gradually across the 4-week period, that is strong evidence of a discrete change rather than a gradual behavioural trend. A step-function spike is a technical signal; a gradual curve is a behavioural signal.

The second question is whether the drop-off is concentrated in a particular segment. I would slice the drop-off by device type — Android versus iOS — partner channel source, bureau score band, and geographic region. If, for example, 90% of the increase is coming from Android users on version X of the app, and the iOS drop-off is unchanged, that is definitively a technical issue on the Android build, not a trust concern. If the drop-off is uniform across all segments, the hypothesis space broadens.

The third question is error rates. I would pull the error event logs for that screen: are users hitting API timeouts when the bureau consent call fires? Are they seeing error messages? An invisible error that causes the screen to freeze or reload would appear as a drop-off event in the funnel even though the user did not voluntarily abandon — they were blocked. I would check the bureau API's response time distribution for the same 4-week window, looking for increased latency or error rates.

Only after ruling out technical causes would I seriously engage with the trust hypothesis. And even then, the right test is an A/B on consent copy — not a unilateral UX change. I would propose testing a variant that explains in plain language what Prefr checks in the bureau report and why, versus the current consent language, and let the data confirm whether copy changes the completion rate before redesigning the whole step.

Follow-up questions

  • Your investigation reveals the bureau API timeout rate increased from 0.8% to 4.2% over the same period. What do you do with this information?

Question 3: SQL — Cohort Conversion

Write a query to find the 30-day loan application-to-disbursement conversion rate for users who applied in May 2026, broken down by whether they were referred from a partner channel or applied directly.

Why interviewers ask this

Tests practical SQL in a real Prefr context — not academic joins but business-logic queries that a PM or finance partner would actually need in a weekly review. Strong candidates write correct SQL, explain the key assumptions they are making (user-level vs. application-level counting), and flag edge cases without being prompted.

Example strong answer

The core logic here is a LEFT JOIN from applications to disbursements, joining on user_id with a date constraint to capture only disbursements that happened within 30 days of the application. Grouping by channel type gives the split the PM is asking for.

SELECT
  CASE
    WHEN a.source_channel = 'partner' THEN 'Partner'
    ELSE 'Direct'
  END                                                     AS acquisition_type,
  COUNT(DISTINCT a.user_id)                               AS applicants,
  COUNT(DISTINCT d.user_id)                               AS disbursed,
  ROUND(
    COUNT(DISTINCT d.user_id) * 100.0
    / NULLIF(COUNT(DISTINCT a.user_id), 0),
    2
  )                                                       AS conversion_rate_pct
FROM applications a
LEFT JOIN disbursements d
  ON  a.user_id          = d.user_id
  AND d.disbursement_date BETWEEN a.application_date
                               AND DATEADD('day', 30, a.application_date)
WHERE a.application_date >= '2026-05-01'
  AND a.application_date  < '2026-06-01'
GROUP BY 1;

Two implementation choices I would flag before running this. First, I am counting at the user level using COUNT(DISTINCT user_id) on both sides. If a user submitted two applications in May — one partner-referred and one direct — and they were subsequently disbursed, which channel gets credit? This query attributes the disbursement to the first application it matches via the join, which may not reflect the actual last-touch attribution logic the business uses. If multi-application users are a meaningful volume, I would clarify the attribution rule with the PM before finalising.

Second, the NULLIF wrapper around the denominator prevents a division-by-zero error if either channel has zero applicants — unlikely in May but worth adding for robustness. I would also run a quick count of multi-application users in the May cohort as a quality check before presenting the results, to confirm the conversion rates are not being distorted by repeat applicants who submitted through multiple channels.

Follow-up questions

  • The partner channel shows a 22% conversion rate and direct shows 31%. The PM says "partner channel is underperforming." What context would you add before accepting that conclusion?

Question 4: A/B Test Read

An A/B test ran for 10 days on the loan offer screen. Variant B (EMI amount shown prominently vs. total loan amount) had 9.2% higher offer acceptance. Sample: 12,000 per arm. p-value: 0.04. The PM wants to ship. What is your recommendation?

Why interviewers ask this

Tests statistical literacy and the ability to give a clear recommendation rather than a list of caveats. Weak candidates either sign off without checking downstream metrics or hedge so much the PM gets no useful guidance. Strong candidates confirm the statistical validity, identify the one downstream risk worth checking, and give a specific "ship with this condition" recommendation rather than a binary yes or no.

Example strong answer

The test is statistically valid on its face. With 12,000 users per arm and a p-value of 0.04, the result clears the standard 95% confidence threshold, and 10 days is long enough to dilute most novelty effects on a familiar loan offer screen — this is not a brand new UI element, it is a layout change to a screen users have seen before. So my starting position is that this result is real.

But offer acceptance is a proxy metric, not the business outcome. What Prefr cares about is disbursements and repayments — and there is a specific risk with an EMI-forward layout that needs to be checked before shipping. By making the monthly payment amount the most salient number, Variant B may attract a different mix of users: specifically, users who anchor to the EMI amount and find it acceptable, but who have not fully processed the total cost of credit or the full loan term. If these users disproportionately abandon at the documentation step, default earlier, or request restructuring more frequently than Variant A users, the 9.2% acceptance lift is generating the wrong kind of conversion.

I would therefore recommend shipping conditionally. The condition is a 30-day downstream check: pull the disbursement completion rate for both arms (of users who accepted the offer, what fraction completed document submission and received disbursement?) and the day-30 repayment rate for the first cohort of disbursed users in each arm. If both metrics are within 2 percentage points of Variant A, ship to 100% with confidence. If either metric is meaningfully worse in Variant B — say, more than 3 points lower on disbursement completion — hold the rollout and investigate whether the EMI framing is creating a mismatch in user expectations downstream.

I would communicate this to the PM as: "The test is valid and the result looks real. I recommend a staged rollout — ship to 20% of traffic today and use the next 30 days to confirm the downstream disbursement and repayment metrics hold. If they do, expand to 100%. This adds 30 days but protects against a meaningful downstream risk that the offer acceptance metric alone cannot catch."

Follow-up questions

  • The PM says the 30-day check will delay the roadmap by a full sprint and asks you to approve full rollout now. How do you respond?

Question 5: Outside-in Competitive Signal

Your PM asks: "Are we losing loan applicants to competitors?" You don't have competitor data. How do you build an outside-in view?

Why interviewers ask this

Directly from the job description — "outside-in signals, share-of-wallet benchmarks" — and tests analytical creativity and resourcefulness beyond internal data. Weak candidates describe sending a user survey. Strong candidates identify four or five concrete, actionable data sources that would give a real signal within days, not weeks.

Example strong answer

I would build the outside-in view from four sources, each of which can be actioned within the current sprint without any new tooling or vendor procurement.

The most direct signal is bureau enquiry data. If our bureau partner — CIBIL or Experian — provides individual-level enquiry logs, I can check whether users who were declined by Prefr in the last 60 days subsequently appear with hard enquiries from other lenders — KreditBee, MoneyTap, CASHe, Navi — within 7 to 14 days of their Prefr decline. That is a direct, measurable rate of competitive leakage: "of the users we declined this month, 34% applied to a competitor within 2 weeks." If the bureau partner does not share enquiry data at that granularity, this is a vendor conversation worth having.

The second source is app store reviews. A scrape of the last 90 days of 1 to 3 star reviews for Prefr mentioning competitor names, or reviews on competitor apps that mention switching from Prefr, would give qualitative signal on why users leave and what they find at competitors. This is a one-day analysis using any review scraping tool and a basic keyword filter.

The third source is Google Trends and search volume data. Comparing search interest for "Prefr loan" versus "KreditBee loan," "MoneyTap app," and "instant personal loan India" over the last 6 months would show whether competitor intent is growing faster than ours. A rising competitor trend concurrent with a decline in our application volume would be a meaningful corroborating signal.

The fourth source is a targeted exit question in the application funnel. Adding a single optional question after a user abandons at the offer screen — "Did you apply for a loan somewhere else recently?" with three response options — would give us direct, first-party data on competitive leakage at the most critical drop-off point. This can be implemented in a week and generates ongoing signal rather than a one-time snapshot.

Taken together, these four sources give the PM a credible, data-grounded answer within 2 to 3 weeks: the volume of competitive leakage (from bureau), the reasons users leave (from reviews), whether competitor intent is growing (from search), and where in our funnel the leakage is happening (from the exit question).

Follow-up questions

  • The exit question data shows 40% of abandoners at the offer screen say they applied to a competitor. The PM wants to immediately reduce our interest rates to compete. What is your analytical response?

Preparation tip

The single most important habit for CRED's product analyst interviews is ending every answer with a recommendation and a measurement plan. Candidates who present findings without a point of view — "the data shows X, so it could be A or B" — do not advance. The interview is designed to test whether you can be the voice in the room that says "here is what I think is happening, here is how we fix it, and here is how we will know if it worked."

Back