Nubank Pair Programming Interview: Format, Tasks & How to Pass

Last updated: September 2026

Quick Answer

The Nubank pair programming interview is a live 60 to 90 minute session where you write code alongside a Nubank engineer in an existing codebase rather than a blank editor. Candidates most often report it as an extension of the take-home they submitted: you explain your code, then add a feature or fix a defect live. Interviewers score collaboration, feedback handling and how you navigate unfamiliar code, not algorithm speed. Rehearse thinking aloud in OphyAI Interview Practice.

Element	What candidates report
Format	Live coding with one engineer, often on your own take-home submission
Duration	Around 60-90 minutes
Interviewers	One senior or staff engineer, sometimes two
Tasks	Explain your submission, add a feature, fix a bug, refactor a module
Language	Your choice in most loops; Clojure is not required, functional habits are noticed

What Nubank Is Testing in This Round

Nubank is testing what it is like to work with you for an afternoon. Other rounds established whether you can code and design. This one asks whether you can be handed code you did not write, form a view about it, and change it safely while someone watches and interrupts.

Four signals recur in candidate accounts: whether you narrate, since silent competence scores worse than average competence explained clearly; whether you treat feedback as input rather than a challenge, because the interviewer will suggest a different approach at least once; whether you read before you type; and whether functional habits show up, meaning pure functions and no hidden mutation. Nubank runs a large Clojure codebase in a hexagonal, ports-and-adapters style, so reaching for a mutable shared variable is visibly out of step even in Python.

What to Expect

You get a repository or editor session with something already in it. Where the round follows a take-home, that something is your own submission, which is why readable code matters more than finishing every optional requirement.

After a short walkthrough, the engineer introduces a change: a new requirement your design did not anticipate, a bug that surfaces only in an edge case, or a refactor of an awkward module. You drive, they contribute. Expect at least one deliberate interruption, often a suggestion you did not ask for. Consider it out loud, then decide. Silently accepting every suggestion scores as badly as brushing them off.

Example Questions and How to Answer Them

”Walk me through your take-home submission.”

Approach: Structure it: the requirement as you read it, the boundary you drew between domain logic and input or output, the trade-off you made knowingly, and what you would change with more time. Naming your own weakness first is a strong move, because the interviewer has already spotted it.

”Add support for a new transaction type without breaking the existing ones.”

Approach: Before typing, say where the change belongs and why. In a ports-and-adapters layout that is usually the domain layer, not the controller. Then write the test first if the repository has tests: Nubank’s codebase culture is test-heavy, and reaching for the test file first is speaking the local language. Keep existing behaviour intact and say how you know you have not broken it.

”This function returns the wrong balance when two events arrive out of order. Fix it.”

Approach: Reproduce before you fix. Write the failing case, state the invariant, then change the code. Nubank’s systems treat records as immutable facts and derive state from them, so the strongest fix orders or aggregates the events rather than patching a mutation. Say that reasoning aloud even if you implement something simpler for time.

”I would do it differently. What do you think?”

Approach: Treat it as a real question. Repeat their suggestion in your own words, name one advantage of theirs and one of yours, and pick. If you switch, say why. If you do not, say what would change your mind. This is the collaboration signal the round exists to measure.

How to Prepare in 3 Days

Day 1. Reread your take-home submission as if a stranger wrote it. Write down the three questions you would ask its author, then prepare answers.

Day 2. Practise in someone else’s code: pick an open source repository, find a small open issue, and fix it while narrating aloud. Fifteen minutes reading before your first edit is normal, not wasted time.

Day 3. Run a live technical mock with follow-up questions in OphyAI Interview Practice, and drill one coding task end to end in OphyAI Coding Interview so that explaining while typing feels routine. Nubank publishes no policy on candidate use of outside artificial intelligence tools, so ask your recruiter and treat Interview Copilot as a mock-round tool here. Start practicing →

Common Mistakes

Coding in silence. If the interviewer cannot hear your reasoning, there is nothing for them to score.

Typing before reading. Editing unfamiliar code within two minutes signals that you would do the same on a production service.

Defending your take-home reflexively. “It was the fastest thing that worked, and here is what I would change” beats a justification.

Ignoring the test file. If tests exist and you never open them, you have told a test-heavy engineering culture how you work.

Rewriting instead of changing. Redoing the module from scratch reads as an inability to work inside constraints.

Related Guides

• Nubank interview guide
• Nubank system design interview
• Revolut live coding interview
• Technical interview preparation for software engineers

Frequently Asked Questions

How long is the Nubank pair programming interview?

Candidates report roughly 60 to 90 minutes with one senior or staff engineer, occasionally two. Where the round follows a take-home, the first five to ten minutes go on walking through what you submitted, leaving about an hour of pairing. One change made properly, with tests, is the expected output.

Do I need to know Clojure for the Nubank pair programming round?

No. Reports agree the round runs in a language you are comfortable with. What interviewers notice is whether functional habits appear in how you write: pure functions, transforming data rather than mutating shared state, and a clear split between domain logic and input or output. You can show that in Python, Java or TypeScript.

Is the Nubank pair programming interview adversarial?

Reports describe it as collaborative. The engineer works with you and will offer suggestions during the session. That is a design feature, not a trap: the round exists partly to see how you respond to input mid-task. Engage with the suggestion, say what you think of it, and make a call.

What happens if I do not finish the task?

Finishing is not the pass condition. Interviewers score how you navigate the code, how you communicate, and whether the change you made is correct and safe. One well-tested change plus a clear plan for the rest usually scores above a rushed sweep through everything with no tests.

Sources and verification notes

Sources checked September 2026. Direct first-party fetches were blocked by this environment’s network policy, so first-party material was consulted through search summaries and is labelled below by origin. Nubank publishes no question bank, so the tasks and format here are candidate-reported and vary by team.

• Building Nubank, functional programming with Clojure: first-party, why Nubank uses Clojure.
• Building Nubank, the hiring process for software engineers: first-party, the engineering interview stages.
• Glassdoor, Nubank software engineer interviews: candidate-reported take-home followed by a live session to explain the code and add functions. Self-reported.
• TechPrep, Nubank interview process 2026: third-party, the pair programming round on an existing codebase.
• InfoQ, architecting a modern financial institution: Nubank engineers on hexagonal architecture and immutable data.