CRED Frontend Development Interview Questions & Answers
Curated interview practice questions with answers. These are practice scenarios, not a verified list of past interview questions.
About CRED hiring for Frontend Development roles
CRED is an Indian fintech platform that rewards members for paying credit card bills and offers products such as CRED Pay, rent payments, CRED Mint and CRED Garage. Its engineering and analytics teams focus on payments, rewards, risk and app experience. It hires for software engineers, SDETs, data analysts and data scientists.
For Frontend Development roles, this CRED practice set focuses most on Frontend Architecture (6), TypeScript (6), Frontend Testing (5), CSS Architecture and Accessibility (4). It has 5 easy, 21 medium, 4 hard questions, so you can start easy and work up to the harder ones.
Company type
Fintech
Headquarters
Bengaluru, India
Main India offices
Bengaluru
CRED Frontend Development interview process
Online assessment or assignment
Technical round (coding or SQL)
Problem solving or design round
Hiring manager round
Typical pattern based on public candidate experiences. Rounds vary by role, team and year.
Solved for CREDStart practicing
3 QUESTIONS FREESign up to unlock the full question bank and track your progress.Unlock every question and answer, then continue practising company-wise and package-wise.
Logical properties describe layout relative to the writing direction instead of physical sides. margin-inline-start means left in English but right in Arabic or Urdu, and padding-block maps to top and bottom in horizontal text. Using them, with the dir attribute on html, lets one stylesheet support both left-to-right and right-to-left languages without overrides. Sizes like inline-size replace width in the same way.
02
Write a React custom hook that fetches data and cancels on unmount.
Animate only transform and opacity, which run on the compositor:
.modal {
opacity: 0;
transform: translateY(16px) scale(0.98);
transition: opacity 200ms ease, transform 200ms ease;
}
.modal.is-open {
opacity: 1;
transform: none;
}
@media (prefers-reduced-motion: reduce) {
.modal { transition: opacity 100ms linear; transform: none; }
}
Animating top, height or margin instead would trigger layout on every frame and cause jank on low-end phones.
I would first write characterisation tests that capture the current behaviour, including odd cases, by calling the module with real inputs and recording outputs. With that safety net, I make small refactors to separate logic from DOM or network code, adding focused tests as I go. Then I implement the change. Small commits and feature flags let me release gradually and roll back quickly if something breaks.
06
Model API request state with a discriminated union.
A shared status field lets TypeScript narrow each case:
type ApiState<T> =
| { status: 'idle' }
| { status: 'loading' }
| { status: 'success'; data: T }
| { status: 'error'; message: string };
function render(state: ApiState<string[]>) {
switch (state.status) {
case 'success': return state.data.join(', ');
case 'error': return 'Error: ' + state.message;
default: return 'Loading...';
}
}
Impossible states, like having both data and an error, cannot be represented.
07
Production builds take eight minutes on an old webpack setup. How would you speed them up?
I would profile the build to find slow loaders and plugins. Quick wins include replacing Babel and Terser with SWC or esbuild, enabling persistent filesystem caching, and removing unused plugins. For a bigger gain, I would evaluate migrating to Vite or Rspack, which keeps webpack-compatible config. In CI, caching dependencies and build outputs and running only affected packages in a monorepo cut time further.
08
How do you choose the right image format and size?
Use AVIF or WebP for photos because they are much smaller than JPEG at similar quality, with JPEG as fallback. Use SVG for icons and logos, and PNG only when lossless transparency is essential. Serve sizes that match the display width with srcset and sizes, compress with tools like Squoosh or an image CDN, and always specify width and height to avoid layout shift.
09
What is the same-origin policy and how does postMessage work around it?
An origin is the combination of scheme, host and port. The same-origin policy stops scripts from reading data or DOM of another origin, such as an embedded iframe from a payment provider. window.postMessage lets two windows or iframes exchange messages safely across origins. The receiver must check event.origin against an allow-list, and the sender should specify the exact target origin instead of '*'.
Component-driven development builds UIs from the bottom up as small, reusable, isolated components, such as buttons and inputs, composed into larger patterns like forms and pages. Each component has a clear API through props or attributes and is developed and documented in isolation, often in Storybook. Composition over configuration keeps components flexible. This approach enables design systems, parallel work and easier testing.
11
Editing one item in a copied list also changes the original list. Why?
Copying an array with spread or slice creates a new array, but the objects inside are still the same references. Changing copy[0].qty changes the original object too. The fix is to create new objects for changed items, for example list.map(item => item.id === id ? { ...item, qty: item.qty + 1 } : item), or use structuredClone when a full deep copy is genuinely needed.
12
How do you balance technical debt against delivering new features?
Situation: our team constantly added features while an outdated build setup slowed everyone. Task: I needed time for cleanup without stalling the roadmap. Action: I quantified the cost, about 30 minutes lost per developer daily, and proposed reserving roughly 15 percent of each sprint for debt, starting with the biggest pain points. Result: the product manager agreed, build times halved, and feature delivery actually sped up.
13
Tell me about a time you convinced your team to adopt a new tool like TypeScript.
Situation: our JavaScript app kept breaking after API changes. Task: I believed TypeScript would help but the team worried about slowing down. Action: I converted one small module as a pilot, showed three bugs it caught, and proposed gradual adoption with no deadline pressure. Result: the team agreed, we migrated over two quarters, and production errors related to wrong data shapes dropped significantly.
14
Users report errors you cannot reproduce. How do you set up frontend observability?
I would add an error monitoring tool like Sentry with uploaded source maps, release tags and user context such as browser and route, without personal data. Real user monitoring tracks Web Vitals and slow API calls. Breadcrumbs of clicks and network requests before an error help reproduce issues, and session replay with privacy masking shows what users saw. Alerts on error spikes after a release enable quick rollbacks.
15
Test a DOM form with Testing Library and user-event.
Simulate real typing and clicks:
import { screen } from '@testing-library/dom';
import userEvent from '@testing-library/user-event';
import { mountSignupForm } from './signup';
it('shows an error for an invalid mobile number', async () => {
document.body.innerHTML = '<div id=app></div>';
mountSignupForm(document.getElementById('app'));
const user = userEvent.setup();
await user.type(screen.getByLabelText('Mobile'), '12345');
await user.click(screen.getByRole('button', { name: 'Sign up' }));
expect(screen.getByRole('alert')).toHaveTextContent('Enter a valid mobile number');
});
toHaveTextContent comes from @testing-library/jest-dom.
16
Ten teams work on one large frontend and releases keep blocking each other. What would you propose?
I would first try a modular monorepo with clear package boundaries, code owners, affected-only CI with Nx or Turborepo, and trunk-based development with feature flags, which removes most blocking at low cost. If teams truly need independent deployments, I would introduce micro-frontends along business domains, such as search, product and checkout, with a shared design system and strict performance budgets to control duplication.
17
Where do you see yourself in five years as a frontend developer?
In five years, I want to be a senior frontend engineer who owns complex features end to end and helps shape architecture decisions. I plan to deepen my skills in performance, accessibility and TypeScript, and contribute to a design system. I also want to mentor juniors, because teaching others is how I learned best. I hope to grow within a team where I can take on that responsibility.
18
Describe a disagreement with your team about choosing a tool or framework.
Situation: half the team wanted a heavy state management library for a new app, while I felt it was unnecessary. Task: we needed a decision quickly. Action: I suggested building the same feature both ways in a time-boxed spike and compared code size, learning curve and bundle impact. Result: the data favoured the simpler approach, the team agreed, and we documented criteria for when to add the library later.
19
Write a fetch wrapper that retries with exponential backoff.
Use role-based locators and web-first assertions:
import { test, expect } from '@playwright/test';
test('user can log in and see dashboard', async ({ page }) => {
await page.goto('/login');
await page.getByLabel('Email').fill('student@example.com');
await page.getByLabel('Password').fill('Secret@123');
await page.getByRole('button', { name: 'Log in' }).click();
await expect(page).toHaveURL(/dashboard/);
await expect(page.getByRole('heading', { name: 'My courses' })).toBeVisible();
});
Assertions auto-wait, so no manual sleeps are needed. Save login state with storageState to reuse in other tests.
Vitest reuses the Vite configuration and transform pipeline, so TypeScript, JSX, ES modules and path aliases work without separate Babel or ts-jest setup. It is fast thanks to on-demand transformation and smart watch mode, and its API is largely compatible with Jest, making migration easy. Jest remains mature and widely used, especially in projects not built with Vite. Both support mocking, snapshots and coverage.
22
Create a type where all fields are optional except id.
I would enable project references with composite builds so only changed packages are rechecked, and turn on incremental with build info files cached in CI. skipLibCheck avoids rechecking node_modules declarations. Very complex conditional types and huge unions slow the checker, so I would profile with --generateTrace and simplify hotspots. The bundler can use fast transpilation while type checking runs separately in parallel.
A tagged template is a function placed before a template literal, like html`<p>${name}</p>`. The function receives the static string parts as an array and the interpolated values separately, so it can escape, transform or validate values before joining them. Libraries use this pattern for safe HTML templating, CSS-in-JS and GraphQL queries. Normal template literals simply interpolate values and support multi-line strings.
25
A third-party library you need has no TypeScript types. What do you do?
First I check if types exist on DefinitelyTyped by installing @types/library-name. If not, I write a minimal declaration file, for example declare module 'old-chart-lib' with only the functions I use, in a types folder included by tsconfig. This is better than a blanket any import. If the library is important to the community, contributing those types upstream helps everyone.
26
How do you test code that depends on the current date or timers?
Real time makes tests slow and nondeterministic. I would use fake timers, such as vi.useFakeTimers() and vi.setSystemTime(new Date('2026-11-12T10:00:00+05:30')), then advance time with vi.advanceTimersByTime to test debounce, countdowns or expiry logic instantly. Restoring real timers after each test avoids leaking state. Designing functions to accept a clock or date parameter makes them even easier to test.
27
Explain the utility types Partial, Pick, Omit and Record.
Partial<T> makes all properties optional, useful for update payloads. Pick<T, 'id' | 'name'> creates a type with only selected keys, and Omit<T, 'password'> removes keys, handy for public user objects. Record<K, V> builds an object type with keys K and values V, such as Record<'en' | 'hi', string> for translations. Others include Required, Readonly, ReturnType and Awaited.
WCAG 2.2 level AA requires a contrast ratio of at least 4.5 to 1 for normal text and 3 to 1 for large text, which is about 24 pixels regular or 19 pixels bold. Interface components and focus indicators need 3 to 1 against adjacent colours. Level AAA raises text to 7 to 1. Tools like the DevTools contrast checker help catch light grey text that fails these limits.
29
When a user logs out in one tab, other open tabs stay logged in. How do you fix it?
I would broadcast a logout message using BroadcastChannel, or the storage event as a fallback, so every tab clears its in-memory state and redirects to the login page. The server must also invalidate the session or refresh token, so stale tabs fail their next API call with a 401, which the app handles by logging out. Both client sync and server invalidation are needed.
30
An accordion animation stutters on low-end Android phones. What is wrong?
Most likely it animates height, max-height or margin, which forces layout recalculation every frame. I would check the Performance panel for long layout events. Fixes include animating transform and opacity, using the newer interpolate-size or calc-size features for height where supported, or animating grid-template-rows from 0fr to 1fr, which is cheaper. Testing with CPU throttling in DevTools reveals these issues before users do.
Tips to crack the CRED Frontend Development interview
Learn how credit card bill payments, UPI and rewards economics work, as CRED's products are built around them.
Pay attention to product design and user experience, which CRED is known for emphasising in its app.
For analyst roles, practise cases on member engagement, reward cost and credit risk segmentation.
Keep a one-minute story ready for every project on your CV: problem, your part, tools, result.
Practise the hard questions on this page aloud; CRED interviewers usually ask follow-ups on your first answer.
Frequently asked questions
How many rounds are there in the CRED Frontend Development interview?
Candidates usually go through 4 stages: Online assessment or assignment; Technical round (coding or SQL); Problem solving or design round; Hiring manager round. The exact rounds change with the role, team, location and your experience, so confirm the process with the recruiter.
Which topics should I prepare for the CRED Frontend Development interview?
This practice set leans on Frontend Architecture (6), TypeScript (6), Frontend Testing (5), CSS Architecture and Accessibility (4). Revise those first, then practise explaining one or two of your own projects end to end, because most CRED interviewers ask you to walk through real work.
Are these the exact questions asked at CRED?
No. These are curated practice questions that match the skills and difficulty usually tested in fintech interviews like CRED's. They are not a leaked or verified list of past questions.
Where does CRED hire Frontend Development professionals in India?
CRED has large teams in Bengaluru. Openings and locations change often, so check the CRED careers page and filter by city and experience.
Frontend Development questions for similar companies