Capital One Frontend Interview Questions

What this measures

Component decomposition, form state and validation strategy, handling of sensitive data, and how you communicate a design without writing full code.

Clarify first

• Ask which fields and steps are required, whether the application can be saved and resumed, and what happens after submit: an instant decision, a pending review or an error.
• Confirm accessibility and device expectations, and whether the design covers only the page or also the follow-up messages.

Strong answer should cover

• Split the page into steps or sections with one owner for form state, and say where validation runs: on blur, before moving to the next step, and on the server.
• Keep sensitive fields out of logs, URLs and long-lived client storage, and mask them on the confirmation page.
• Design every submit state: idle, submitting, success, decline, review pending and failure, with a retry that cannot submit twice.
• Make it accessible: labels, an error summary tied to fields, focus moved to the first error, and keyboard support across steps.

What this measures

Turning requirements into structure, choosing where state lives, and collaborating while you code.

Clarify first

• Ask which screens and data come first, and what the API returns.
• Agree on the framework and whether a state library is expected or optional.

Strong answer should cover

• Sketch the routes and the component tree first, then name the source of truth for each piece of data: server, URL or local state.
• Use a state library only for data many screens share, and say why the rest stays local.
• Build one vertical slice end to end, including loading and error states, before adding screens.
• Narrate trade-offs and invite the interviewer in, since one account describes this round as more pair programming than interview.

What this measures

Angular forms fluency, validation design, and the data flow from form control to list.

Clarify first

• Ask whether to use reactive or template-driven forms, and which rules apply to each field.
• Confirm when errors should appear: on blur, on submit or as the user types.

Strong answer should cover

• Use reactive forms with a form group, built-in validators and one custom validator where a rule needs it.
• Disable submit while the form is invalid or submitting, and reset the form after a successful add.
• Show errors next to their fields and announce them to screen readers.
• Test a valid add, each invalid case and the reset.

What this measures

Reading unfamiliar code, reasoning with concrete numbers, and explaining a fix clearly under time pressure.

Clarify first

• Restate the business rule in your own words and agree on one worked example before reading the code.
• Ask which language the code is in, since accounts mention Java, C++, Node.js and Python.

Strong answer should cover

• Trace the function with your example values and write down each variable as it changes.
• Name the bug precisely: the line, the input that triggers it and the wrong output it produces.
• Propose the smallest fix, then one test case that would have caught it.
• Mention a second risk you notice, such as rounding or an empty input, without derailing the main fix.

What this measures

Code comprehension, risk spotting and safe refactoring, which the case round tests in the accounts.

Clarify first

• Ask what the function is supposed to do before judging how it does it.
• Confirm whether you may change its signature or only its body.

Strong answer should cover

• Summarize the behaviour in one sentence, including side effects such as mutating its input.
• List the risks in order: wrong results, hidden mutation, unreadable logic, performance.
• Refactor in small steps that keep behaviour, and say how you would test each step.
• Use clear names and extract small pure functions so the result reads like the requirement.