Nubank QA and SDET Interview Questions (2026)

TL;DR

Prepare around customer trust, exact financial state, payment lifecycles, API and event contracts, mobile quality, security, distributed-system failure, and clear coding. Nubank publicly describes a technical assessment or case study followed by online interviews, but the order and names of stages vary by role.

Key Takeaways

• Prioritize customer money, authorization, ledger integrity, privacy, recoverability, and explainability over raw test-case counts.
• Model card payments and transfers as state machines, then attack retries, duplicates, races, delayed events, and reconciliation gaps.
• Prepare contract and focused acceptance testing because Nubank has publicly described moving away from one large staging end-to-end suite.
• Use exact integer or decimal money representations and distinguish ledger truth from cached or customer-facing projections.
• Show runnable automation that controls data and dependencies, asserts business invariants, and produces useful failure evidence.
• Connect release quality to feature flags, controlled rollouts, canaries, observability, abort criteria, and safe recovery.
• Verify the actual process with Talent Acquisition because Nubank states that hiring stages vary by department and position.

nubank qa sdet interview questions should prepare you to reason about software that moves money, makes credit decisions visible, protects identity, and must recover safely from partial failure. A credible answer connects a customer outcome to an invariant, a controlled test, observable evidence, and a release decision.

Nubank's public careers guidance describes a technical assessment, which can be an exercise or case study, online interviews with several areas including leadership, and final stages. It also says the order and names can change by department and position. Use this guide as a realistic practice map, then let the recruiter and current job description define your exact loop and stack.

TL;DR

A useful answer structure is: customer risk -> invariant -> test level -> test data -> fault or boundary -> oracle -> production signal.

1. nubank qa sdet interview questions and the hiring process

Q: What interview stages should you expect at Nubank?

Nubank's careers page names application, technical assessment, online interviews, and final stages, while explicitly warning that the sequence varies. For a QA or SDET role, prepare for a coding or technical exercise, test design, automation discussion, system-quality reasoning, and behavioral interviews without claiming each will occur. Ask Talent Acquisition which language, product area, and exercise format apply to your opening.

Q: How would you prepare from the job description?

Turn every responsibility into a proof matrix with one project, one decision, and one measurable outcome. A mobile-platform role calls for app lifecycle, release trains, observability, and client architecture, while a backend role may emphasize APIs, events, data, and incident response. Any listed language should trigger a short coding drill in that language, not a memorized glossary.

Q: What should your 60-second introduction emphasize?

Lead with the systems and risks you have owned, not a chronological autobiography. Name your strongest automation layer, one reliability or financial-quality result, and the collaboration needed to achieve it. Close by linking that evidence to the role, such as protecting high-volume asynchronous payment flows or improving mobile release confidence.

Q: How do you answer when you lack banking experience?

Translate adjacent experience into transferable invariants rather than pretending domain expertise. Ecommerce refunds teach asynchronous money state, SaaS permissions teach authorization, and logistics events teach idempotency and eventual consistency. Then state the banking concepts you would clarify with product, legal, risk, and engineering partners before encoding expectations.

Q: What should you ask the recruiter before the technical round?

Clarify whether the assessment is live, take-home, algorithmic, or case-based, plus permitted languages and expected duration. Ask which product and quality layers the team owns, because card, lending, mobile-platform, data, and infrastructure work create different interviews. Confirm whether the discussion requires English, Portuguese, or Spanish and whether accessibility accommodations are needed.

2. Financial correctness and risk-based test design

Q: How would you prioritize tests for a digital banking feature?

Rank scenarios by customer asset impact, unauthorized access, regulatory or privacy exposure, reach, time sensitivity, reversibility, and detectability. A duplicated transfer outranks a clipped label because the financial effect is harder to reverse and may spread across systems. Document the choice in a risk table and use the risk-based testing guide to keep scope tied to evidence.

Q: What invariants matter for money movement?

Every accepted business intent needs a unique identity, exact amount and currency, valid state transition, and explainable accounting effect. The sum of postings for a balanced transaction should match the ledger model, and replaying a delivered event must not create value again. Customer-facing balances should reconcile to authoritative records even when projections arrive late.

Q: Why is floating-point arithmetic dangerous in financial tests?

Binary floating point cannot represent many decimal fractions exactly, so an equality check can fail or, worse, a rounded display can hide a stored error. Use integer minor units when the currency permits or a decimal library with an explicit scale and rounding policy. The following Node test is self-contained and validates positive, safe integer amounts and insufficient funds.

// money-invariants.test.mjs
import test from 'node:test';
import assert from 'node:assert/strict';

function transfer(availableCents, amountCents) {
  if (!Number.isSafeInteger(amountCents) || amountCents <= 0) {
    throw new RangeError('amountCents must be a positive safe integer');
  }
  if (amountCents > availableCents) throw new Error('insufficient_funds');
  return { availableCents: availableCents - amountCents, postedCents: amountCents };
}

test('posts the exact requested minor units', () => {
  assert.deepEqual(transfer(10_00, 3_25), { availableCents: 6_75, postedCents: 3_25 });
});

test('rejects an amount above the available balance', () => {
  assert.throws(() => transfer(2_00, 2_01), /insufficient_funds/);
});

Save it as money-invariants.test.mjs and verify it with node --test money-invariants.test.mjs. The expected summary reports two passing tests and no failures.

Q: How would you test a displayed balance?

First identify whether the number represents available, current, settled, statement, or credit-limit state, because those values can legitimately differ. Construct activity involving a pending card authorization, a posted purchase, a reversed transaction, and an incoming transfer, then calculate each projection from its contract. Compare the UI with the owning API and ledger evidence, including timestamp and currency, instead of treating the screen as its own oracle.

Q: What boundary cases belong in a currency test suite?

Cover zero, minimum unit, maximum supported amount, negative input, too many decimal places, unsupported currency, and values near storage or API limits. Add rounding ties only where the product contract permits fractional calculation, such as interest or tax allocation. Include locale display separately, since 1.234,56 and 1,234.56 can represent the same numeric value under different conventions.

3. Card, credit, and statement scenarios

Q: How would you test a card authorization lifecycle?

Model authorization, approval or decline, capture, partial capture if supported, reversal, expiration, and settlement as explicit states supplied by the product contract. Inject late, duplicate, and out-of-order network messages while asserting that captured value never exceeds the allowed amount. Verify the customer timeline, available limit, merchant information, notification, and ledger effect from the same correlation trail.

Q: What happens when an authorization response times out?

A client timeout does not prove the issuer declined or failed to process the request. Query or reconcile by the stable business identifier before retrying, and keep the customer message honest about an unknown state. Test approval arriving after timeout, a genuine decline, duplicated submission, and recovery after the caller restarts.

Q: How would you test duplicate card events?

Replay the identical network event, then send a semantically duplicate event with a different transport delivery identifier. The processor should distinguish transport redelivery from a genuinely separate purchase using the identifiers defined by the integration. Assert one financial effect, a traceable duplicate decision, and no second customer notification unless the notification policy explicitly allows it.

Q: How do reversals differ from refunds in testing?

A reversal usually unwinds an authorization before normal settlement, whereas a refund is a later credit related to a completed purchase. Test them as separate lifecycles with distinct timing, limits, statement labels, and reconciliation behavior. The partial capture and refund testing guide provides additional cases, but the interview answer should follow the exact card contract presented.

Q: How would you validate a monthly statement?

Build an independent expected statement from authoritative posted transactions, fees, credits, payments, dates, and the documented cycle boundary. Reconcile opening balance plus debits minus credits and payments to the closing balance, then check minimum payment and due date only against supplied rules. Exercise timezone cutoffs, corrected transactions, pagination, PDF rendering, accessibility, and consistency with the in-app view.

4. Transfers, retries, and reconciliation

Q: How would you test an instant transfer flow such as Pix?

Start with payer authorization, recipient resolution, amount, limits, risk decision, submission, external acknowledgment, ledger posting, receipt, and terminal status. Partition valid keys and accounts from invalid, blocked, expired, or mismatched destinations according to the current product contract. Add concurrency, timeout ambiguity, duplicate requests, delayed callbacks, reversal or return flows, and reconciliation with the external network.

Q: What does idempotency mean in a transfer API?

Repeated submission of the same authorized intent with the same idempotency key must not move money twice. The API should define key scope, retention, response replay, payload mismatch behavior, and concurrent-request semantics. Test the first response being lost, simultaneous retries, changed amount under the same key, and reuse after the documented retention window.

Q: How would you test an event consumer for duplicate delivery?

Use a pure reducer with event IDs so the business state is deterministic and easy to replay. This runnable Node example credits a completed transfer once, even when Kafka-like at-least-once delivery repeats an event. Production persistence would need an atomic transaction around the processed ID and ledger write, which the in-memory example intentionally does not simulate.

// transfer-events.test.mjs
import test from 'node:test';
import assert from 'node:assert/strict';

function applyEvent(state, event) {
  if (state.processedIds.has(event.id)) return state;
  const processedIds = new Set(state.processedIds).add(event.id);
  if (event.type !== 'transfer.completed') return { ...state, processedIds };
  return { balanceCents: state.balanceCents + event.amountCents, processedIds };
}

test('applies a completed transfer once under redelivery', () => {
  const start = { balanceCents: 5_00, processedIds: new Set() };
  const event = { id: 'evt-17', type: 'transfer.completed', amountCents: 2_50 };
  const once = applyEvent(start, event);
  const twice = applyEvent(once, event);
  assert.equal(twice.balanceCents, 7_50);
  assert.equal(twice.processedIds.size, 1);
});

Run node --test transfer-events.test.mjs and expect one passing test. During an interview, also describe the database uniqueness constraint and transaction boundary that make the deduplication durable.

Q: How do you test eventual consistency without arbitrary sleep?

Poll the authoritative read model for a defined terminal condition with a bounded deadline and useful diagnostics. Keep the polling interval modest, record the latest observed state, and fail with correlation identifiers rather than a generic timeout. Test both convergence and deliberate non-convergence, then expose latency as a metric instead of hiding it behind a larger wait.

Q: What is your reconciliation strategy after partial failure?

Join the customer intent, external network record, internal event history, ledger postings, and customer-visible projection by stable identifiers. Classify discrepancies into missing, duplicate, amount mismatch, wrong account, and stale projection, with a safe remediation path for each. Re-run reconciliation to prove that recovery is idempotent and that every automated correction leaves an audit record.

5. API, contract, Clojure, and event-driven testing

Q: Why should you prepare contract testing for Nubank?

Nubank has publicly described replacing a large shared staging end-to-end suite with schema compatibility checks and focused in-memory acceptance tests for critical behavior. That history makes consumer impact, HTTP and event schemas, and service boundaries valuable discussion topics. Explain the trade-off accurately: a contract can catch structural incompatibility, but behavior across a critical flow still needs targeted verification.

Q: How would you test an API schema change?

Classify the change as additive, restrictive, semantic, or removal, then identify all consumers and supported versions. An optional field can still break strict deserializers, while an unchanged type can acquire a meaning that violates business expectations. Run compatibility checks in CI, add consumer examples, and follow the API versioning test guide when coexistence is required.

Q: What should a Kafka contract include?

Capture topic or event identity, key semantics, schema, required fields, units, timestamps, ordering assumptions, and compatibility policy. Test unknown additive fields, missing required data, invalid enum values, duplicate delivery, partition-key changes, and old consumers reading new events. Compare schema tools and behavior tests with the Pact versus AsyncAPI guide instead of claiming one artifact validates every runtime guarantee.

Q: How would you test a Clojure service if Clojure is new to you?

Start from pure functions and immutable data, where input-to-output examples and property tests provide quick leverage. Learn maps, vectors, sets, keywords, sequence transformations, and clojure.test, then read the team's schemas and service boundaries before changing framework code. Be candid about your ramp-up while showing that functional testing habits transfer from another language.

Q: What does Datomic change about your test thinking?

An immutable database encourages questions about facts over time, transaction boundaries, uniqueness, and queries against a chosen basis. Validate both the current projection and historical explanation, especially for corrections that add facts rather than overwrite an old row. Do not assume Nubank's exact schema; ask which attributes are unique, how time is modeled, and what consistency the reader receives.

6. Mobile, Flutter, accessibility, and customer experience

Q: How would you test a Flutter banking app?

Use Dart unit tests for rules, widget tests for view state and interaction, and a narrow integration suite for journeys that require the real app shell or platform channels. Add API contract checks below the UI and test on representative physical devices for biometrics, camera, notifications, and lifecycle behavior. Nubank publicly identifies Flutter and server-driven UI as important mobile-platform technologies, but the current role description remains the authority for scope.

Q: Which mobile lifecycle failures are highest risk?

Interrupt a transfer during confirmation, background the app while authentication expires, kill it after submission, rotate or resize during data entry, and restore after an operating-system eviction. On return, the app must resolve server truth without repeating a financial command or exposing stale sensitive data. Capture the request ID and final account state so the test proves more than screen continuity.

Q: How would you test biometric authentication?

Separate device enrollment, app permission, local biometric result, server session, and step-up policy because they fail independently. Cover success, user cancellation, lockout, newly added biometric data, unavailable hardware, fallback credentials, expired session, and rooted or compromised-device handling defined by policy. Never automate by weakening production controls; use platform-supported test mechanisms and dedicated non-production accounts.

Q: What accessibility checks matter in a finance app?

Verify meaningful names, roles, values, focus order, dynamic announcements, text scaling, contrast, touch target usability, and alternatives to gesture-only actions. Money amounts and transfer status must be spoken with unambiguous currency and state, not as disconnected digits or color alone. Test destructive confirmations and timeout messages with a screen reader, keyboard or switch navigation, and the platform's largest supported text settings.

Q: How do you validate server-driven UI safely?

Contract-test component names, required properties, action allowlists, fallback behavior, and supported schema versions before rendering. Feed unknown components, malformed payloads, stale cached configurations, and actions that the client must reject. A safe client fails closed for privileged operations, remains diagnosable, and preserves navigation and accessibility when optional content is unavailable.

7. nubank qa sdet interview questions on automation strategy

Q: What automation pyramid would you propose?

Put financial rules and reducers in fast deterministic tests, schemas at service boundaries, component tests around owned dependencies, and focused acceptance tests across a critical subset. Keep only a small set of mobile or browser journeys for rendering, navigation, and integration risks that lower layers cannot expose. The shape follows failure economics, so measure defect detection, runtime, stability, and ownership rather than enforcing a fashionable percentage.

Q: How would you automate a retrying transfer UI?

Control the network response, preserve one idempotency key across retries, and assert both the customer result and request history. The example below uses real Playwright APIs against a self-contained page and an illustrative endpoint, not a Nubank interface. It proves that a temporary 503 causes one retry without changing the business identity.

// transfer-retry.spec.ts
import { test, expect } from '@playwright/test';

test('retries with the same idempotency key', async ({ page }) => {
  let attempts = 0;
  const keys: string[] = [];

  await page.route('https://bank.test/', route => route.fulfill({
    contentType: 'text/html',
    body: `<button>Send</button><output></output><script>
      const key = 'intent-42';
      document.querySelector('button').onclick = async () => {
        let response = await fetch('/api/transfers', { method: 'POST', headers: { 'Idempotency-Key': key } });
        if (response.status === 503) response = await fetch('/api/transfers', { method: 'POST', headers: { 'Idempotency-Key': key } });
        document.querySelector('output').textContent = response.ok ? 'Submitted' : 'Failed';
      };
    </script>`
  }));

  await page.route('https://bank.test/api/transfers', route => {
    attempts += 1;
    keys.push(route.request().headers()['idempotency-key']);
    return route.fulfill({ status: attempts === 1 ? 503 : 201, body: '{}' });
  });

  await page.goto('https://bank.test/');
  await page.getByRole('button', { name: 'Send' }).click();
  await expect(page.getByText('Submitted')).toBeVisible();
  expect(attempts).toBe(2);
  expect(new Set(keys).size).toBe(1);
});

Install with npm install --save-dev @playwright/test, then verify with npx playwright test transfer-retry.spec.ts --project=chromium. A passing run reports one test passed; a changed retry key fails the final assertion.

Q: How do you decide what not to automate?

Avoid automating a scenario when the oracle is undefined, the feature is about to be removed, or a lower-level test gives faster and more precise protection. Exploratory work remains valuable for unfamiliar workflows, confusing language, and interactions that have not stabilized. Record the decision with expected frequency, impact, maintenance cost, and the signal that would justify automation later.

Q: How would you reduce flaky tests?

Classify failures by synchronization, shared data, dependency instability, environment drift, nondeterminism, or product defect before changing retries. Replace sleeps with observable conditions, isolate test identities, freeze clocks and random seeds, and virtualize only the dependency behavior outside the test's purpose. Quarantine can protect the pipeline briefly, but assign an owner, preserve failure evidence, and set an expiry so ignored risk does not become permanent.

Q: What test data strategy supports parallel execution?

Generate a unique namespace per worker and create accounts through supported APIs or fixtures with explicit starting state. Keep sensitive production data out, mask any approved sample, and make teardown idempotent so a failed run can be cleaned safely. For shared reference data, make tests read-only or version it; for stateful financial cases, prefer isolated ephemeral environments as covered in the Testcontainers integration guide.

8. Distributed systems, observability, and safe delivery

Q: How would you test a service during dependency failure?

Enumerate dependency outcomes such as timeout, connection refusal, throttling, malformed response, slow success, and partial availability. Assert bounded timeouts, retry budgets, circuit behavior, queueing or fallback only where designed, and an honest client status. Recovery testing must prove the backlog drains without duplicate financial action after the dependency returns.

Q: Which observability signals should a payment test verify?

Check structured logs for safe identifiers and outcomes, metrics for request rate, errors, latency, retries, queue age, and reconciliation gaps, plus trace propagation where supported. Ensure dashboards distinguish business declines from technical failures because combining them creates false alarms. Deliberately cause a known failure and confirm the alert links responders to actionable evidence without leaking account or card data.

Q: How would you test a canary release?

Send a small, representative cohort to the candidate while keeping the control comparable. Define abort criteria before rollout using technical and business guardrails, then verify automated stop, rollback or flag disablement, and post-rollback recovery. The feature-flag percentage rollout guide helps test deterministic assignment, but cohort safety and state compatibility still need domain analysis.

Q: What would you include in a load test for transfers?

Model arrival patterns, account distribution, hot keys, payload mix, dependency capacity, and daily or event-driven peaks using synthetic funds and isolated routes. Measure end-to-end completion, queue age, error classification, resource saturation, and reconciliation lag rather than reporting requests per second alone. Set safety limits and abort conditions, and never point uncontrolled load at production financial rails.

Q: How do you test disaster recovery?

Choose a documented failure such as region loss, database unavailability, or consumer restart, then state the recovery and data-loss objectives supplied by the system owner. Exercise failover with in-flight operations and verify durable events, deduplication, ledger consistency, secrets, DNS or routing, and customer status after recovery. Finish with reconciliation and evidence that normal processing resumes without a hidden duplicate wave.

9. Security, privacy, and multi-country quality

Q: How would you test authorization between two customer accounts?

Create two users with different accounts, roles, sessions, and resource identifiers, then attempt reads and writes by swapping IDs in path, query, body, and nested references. The server must derive ownership from the authenticated principal rather than trust a client-supplied owner field. Verify denial, unchanged state, a safe response, and an audit signal, then study the OAuth authorization code flow guide for token boundaries.

Q: What sensitive data must automation protect?

Treat credentials, session tokens, personal identifiers, card data, bank-account details, biometrics, and financial history as restricted according to policy. Use synthetic values, secret stores, redacted logs, least-privilege test accounts, encrypted artifacts, and short retention. Add a scanner assertion that failed tests, screenshots, traces, and CI output do not publish those values.

Q: How would you test rate limiting without harming service?

Use an approved environment and a dedicated identity, then probe just below, at, and above the documented threshold with bounded concurrency. Validate scope by account, token, device, IP, or endpoint as specified, including reset behavior and a standards-consistent response. Confirm legitimate users are not globally blocked by one abusive actor and that monitoring sees the simulated abuse.

Q: What changes when a product operates across countries?

Currency, language, timezone, identity formats, holidays, payment rails, disclosures, limits, and regulatory workflows may vary by market. Keep rules in versioned configuration and test country-specific contracts rather than copying a Brazil expectation into Mexico or Colombia. Pair local subject-matter review with automated invariant tests so translation accuracy and legal interpretation are not guessed by engineers.

Q: How do you test audit logs?

Generate an authorized action, a denied action, a correction, and an administrative operation, then compare their records with the audit schema. Each entry should identify actor, action, target, outcome, time, source, and correlation context while omitting prohibited secrets. Verify append-only retention and access controls separately from ordinary application logs, including clock skew and failed log delivery.

10. Coding, SQL, and behavioral ownership

Q: How should you approach a coding exercise?

Restate input, output, constraints, invalid cases, and complexity before writing code. Build the simplest correct representation, walk through a normal and boundary example, then add focused tests and improve names. Nubank's public technical-exercise guidance emphasizes logic, data-structure transformation, readable organization, and avoiding unnecessary complexity, so narrate those decisions clearly.

Q: Which data structures are useful in SDET exercises?

Use a set for duplicate event IDs, a map for constant-time lookup by account or transaction, a queue for ordered work, and a heap when only the next highest-priority item matters. Explain why order, memory, and duplicate semantics fit the problem instead of naming structures at random. For a reconciliation task, maps keyed by stable business ID often make missing and mismatched records explicit.

Q: How would you write a SQL reconciliation check?

Aggregate debits and credits by business transaction, then return only groups that violate the ledger's balancing rule. Include currency in the grouping so unrelated units never cancel each other numerically. The following PostgreSQL script is self-contained and should return only tx-bad.

CREATE TEMP TABLE ledger_entries (
  business_id text NOT NULL,
  currency char(3) NOT NULL,
  side text NOT NULL CHECK (side IN ('debit', 'credit')),
  amount_cents bigint NOT NULL CHECK (amount_cents > 0)
);

INSERT INTO ledger_entries VALUES
  ('tx-good', 'BRL', 'debit', 500),
  ('tx-good', 'BRL', 'credit', 500),
  ('tx-bad', 'BRL', 'debit', 700),
  ('tx-bad', 'BRL', 'credit', 650);

SELECT business_id, currency,
       SUM(CASE WHEN side = 'debit' THEN amount_cents ELSE -amount_cents END) AS imbalance_cents
FROM ledger_entries
GROUP BY business_id, currency
HAVING SUM(CASE WHEN side = 'debit' THEN amount_cents ELSE -amount_cents END) <> 0;

Verify with psql -f ledger-reconciliation.sql; the result should contain tx-bad, BRL, and 50. In a real system, adapt the sign convention and posting model rather than assuming this illustrative schema.

Q: Tell me about a time you blocked a release.

Choose a case where evidence, not job title, changed the decision. Describe the customer risk, reproduction, affected scope, telemetry or test results, options discussed, and the accountable owner's decision. End with the fix and prevention mechanism, while acknowledging any delivery cost created by the delay.

Q: Tell me about a defect you missed.

Select a genuine miss and explain the mistaken assumption or missing signal without blaming another team. Quantify the impact safely, show how containment and diagnosis worked, and name the lasting control added at the correct test layer. A strong reflection distinguishes a personal learning from a systemic improvement such as a contract, monitor, review rule, or safer rollout.

Q: How do you challenge a developer who disagrees with severity?

Align first on observed behavior, affected customers, financial or privacy impact, frequency, reversibility, and workaround. Run a small experiment or inspect production-like evidence to resolve factual disagreement, then let the agreed decision owner accept or reject the risk. Preserve the rationale in the ticket and avoid turning severity labels into a contest over authority.

Q: How do you show smart efficiency in QA?

Remove repeated manual coordination, move precise checks closer to the code, and reserve expensive environments for risks that require them. Track whether the change shortens feedback, reduces escaped defects, or improves diagnosis without weakening meaningful coverage. Efficiency is not simply fewer tests; it is more decision value per unit of maintenance and execution cost.

How Interviewers Grade Your Answers

Interviewers usually reward reasoning they can inspect. For test design, they look for prioritization, explicit invariants, meaningful partitions, failure modes, data control, and an oracle. For coding, they assess correctness, clarity, complexity, boundary handling, tests, and communication rather than language trivia alone.

For system quality, name the authoritative state, service boundaries, asynchronous behavior, observability, and recovery path. For behavioral answers, connect your individual action to team decisions and customer outcomes. When information is missing, ask one precise question, state a bounded assumption, and continue.

Practice aloud in QAJobFit interview practice, and keep each answer structured enough to finish before adding optional depth. Use the resume upload workspace to align your project evidence with the actual requisition rather than memorizing company keywords.

Common Mistakes

• Treating Nubank as a generic ecommerce app and ignoring exact money, authorization, reconciliation, privacy, and recovery.
• Repeating rumored interview stages as fact after Nubank explicitly says stages can vary by department and position.
• Assuming every historical public engineering practice is an exact description of the current team.
• Using floating point for financial assertions or comparing formatted strings without currency and scale.
• Calling a timed-out transfer failed, then retrying without resolving the ambiguous original result.
• Proposing one giant end-to-end suite while skipping contracts, focused acceptance tests, and service-owned checks.
• Adding sleeps, global test accounts, or blind retries to hide nondeterministic automation.
• Reporting only HTTP status or screen text when ledger state, events, and audit evidence determine correctness.
• Giving behavioral answers with no decision, outcome, learning, or acknowledgment of trade-offs.
• Revealing confidential employer data, production identifiers, internal thresholds, or customer information in examples.

Conclusion

The best preparation for nubank qa sdet interview questions combines fintech rigor with practical engineering. Be ready to protect exact financial state, reason through asynchronous payment and transfer lifecycles, choose contracts and focused acceptance tests wisely, automate deterministic evidence, and make releases observable and reversible.

Build five concise stories, run the three code exercises in this guide, and rehearse one system-design scenario from intent through reconciliation. Then confirm the current interview format and supported product area with Talent Acquisition so your final preparation matches the role in front of you.

Interview Questions and Answers

Frequently Asked Questions

Related Guides

• Chime QA and SDET Interview Questions (2026)
• CRED QA and SDET Interview Questions (2026)
• Klarna QA and SDET Interview Questions (2026)
• 500+ QA and Manual Testing Interview Questions and Answers (2026)
• Adyen QA and SDET Interview Questions (2026)
• Airtable QA and SDET Interview Questions (2026)