Skip to content

Company interview guide

CRED interview process and practice questions

Candidates commonly report that CRED's engineering interviews include problem-solving and machine coding or design rounds, followed by conversations about how they work and why they want to join. CRED publishes its values on its careers site, including play to win, fast & right, high agency and making members win. Members use it to pay credit card bills and more, so questions often touch on trust, security and the quality of the app experience.

As candidates commonly report it; it varies by team, level and year. Last reviewed 18 October 2026.

The interview process

  1. 1Recruiter or hiring team screen
  2. 2Problem-solving / data structures round
  3. 3Machine coding or low-level design round (for many engineering roles)
  4. 4System design (for experienced roles)
  5. 5Hiring manager and culture conversation

What interviewers listen for

  • play to win
  • fast & right
  • trustworthy
  • compounding
  • high agency
  • making members win
  • frugal
  • Care for detail in code and in the member's experience

Behavioral questions

  1. Tell me about a time you moved fast and still got it right. What did you check before shipping?

    A good answer covers

    • Why speed mattered
    • The checks you kept: tests, review, a gradual rollout
    • The result, and whether the decision held up later
  2. Tell me about something you started without being asked and saw through to the end.

    A good answer covers

    • What you noticed and why you took it on
    • The obstacles and how you got past them without waiting for permission
    • The finished result and its impact
  3. Describe a time you gave candid feedback to a colleague or manager. How did it land?

    A good answer covers

    • What you said and why it needed saying
    • How you said it so it could be heard
    • What changed, for them and for your working relationship
  4. Tell me about a time you got more done with fewer resources: fewer people, a smaller budget or less time.

    A good answer covers

    • The constraint and what the expensive option was
    • What you cut, reused or simplified
    • What you delivered and what it saved
  5. Tell me about a bet that didn't pay off. What did you learn, and what did you do next?

    A good answer covers

    • Why the bet looked worth it
    • When you saw it wasn't working and how you decided to stop or change
    • The lesson, and how you used it on the next thing

Role and technical questions

  1. How would you design reminders that tell members a credit card bill is due, without annoying them?

    A good answer covers

    • Where due dates come from and how they're kept up to date
    • Scheduling at scale: timing, channels, and stopping once the bill is paid
    • Frequency limits and preferences, measured by on-time payments and opt-outs
  2. How would you design a rewards system where members earn points on payments and spend them on offers?

    A good answer covers

    • A ledger of earn and spend entries, written once per payment
    • Abuse: rewards on payments later refunded, many accounts for one person
    • Expiry, accurate balances and a full audit trail
  3. How would you keep sensitive financial data safe in a mobile app and its backend?

    A good answer covers

    • Encryption in transit and at rest, and storing tokens instead of card numbers
    • Least-privilege access, audit logs and proper handling of secrets
    • On the phone: no sensitive data in logs or screenshots, secure local storage
  4. A screen in your app feels slow on older Android phones. How would you find and fix the cause?

    A good answer covers

    • Profiling first: dropped frames, work on the main thread, slow network calls
    • Fixes such as smaller images, lazy loading and caching
    • Measuring before and after on a low-end device
  5. How would you decide whether a new feature makes members' lives better or just adds clutter?

    A good answer covers

    • The member problem it solves, checked with research before building
    • Metrics: repeat use, effect on core flows, support tickets
    • A clear rule for removing it if it doesn't earn its place
  6. How would you safely roll out a risky change to a payment flow?

    A good answer covers

    • A feature flag and a small first rollout
    • The metrics you'd watch and the point at which you'd roll back automatically
    • Telling support and other teams before it goes out

Why CRED? Fit and HR questions

  1. Why CRED? Which of its values do you see in your own work?

    A good answer covers

    • A reason tied to the product, its members or the craft, not only the brand
    • One value with a short example
    • What you want to build or learn here
  2. What would you change in the CRED app, and how would you know members liked it?

    A good answer covers

    • A specific flow and the member problem with it
    • Your change, and what you'd keep because it already works well
    • The metric and the feedback you'd look at

Tips

  • CRED's values are short phrases (fast & right, high agency, frugal); prepare a story for each that shows the behaviour without naming it.
  • Use the app before the interview and form a view on one flow you'd improve and one you admire.
  • In design rounds, raise trust and security early: how data is protected and how members know what is happening with their money.
  • For machine coding, care about naming, structure and edge cases; a clean, readable solution matters as much as a working one.

Practise it out loud

A mock interview asks the way CRED's interviewers are known to, follows up on your answers and gives you a report. The warm-up is free, needs no account and checks five of these questions as you answer.

About this guide

Written by Orbit from CRED's own public pages and what candidates commonly report. Orbit isn't affiliated with CRED. The questions are practice questions in the style of its interviews, not questions taken from them. Processes change, so check the job post and what your recruiter tells you.

Sources