A practice prompt we wrote. No company or candidate report names it, so it carries no company tag.
How to answer
Split every day a file spends into time the bank is working and time it waits on someone else, and count the applicants who give up while it waits. The risk constraint is a set of guardrails someone else owns; your time goes into finding where the days go.
- Clarify “faster”, and why now. From what to what: application received to decision, or to money in the account? Which products: a term loan, a line of credit, a government-guaranteed loan with its own steps? Say you will take one product until told otherwise. Ask why now: are good applicants withdrawing or going silent while they wait, or is the team overloaded? If it is the first, count abandoned applications by the stage they died in, beside time to decision.
- Clarify “more risk”. Ask which risk numbers credit already reports: early delinquency, charge-offs, exceptions to policy. Those become your guardrails, and the chief credit officer who owns them can stop your project, so name them first. Last quarter’s time to decision and those risk numbers are your baseline.
- Name the people. The head of small-business lending owns the goal. Relationship managers, underwriters and credit policy do the work. Compliance cares because Regulation B sets when the bank must notify an applicant once an application is complete, so “complete” needs one definition.
- Map the workflow as stages, then split the time. For each stage, separate time the bank is working from time it waits on the applicant or a third party. Ask whether the loan origination system timestamps status changes, or whether people update them by hand.
- Sequence by where the time is. Waiting on documents means a checklist and a document chase come first. A long underwriter queue means pre-filled financials come first. Say which you expect and what would prove you wrong.
- State the failure modes: stale statuses, files that loop back, and a faster queue that just moves the wait downstream.
An approval model is the tempting first answer. If policy keeps a human underwriter on every file, a faster decision model changes little, and a decision in seconds does not help a file that sits for a week waiting on a tax return.
Follow-ups
What the interviewer may ask next, once your first answer is on the table.
- Draw the stages of an application and the table that records time in each.
- Credit policy says every file needs a human underwriter. What can you automate?
- Volume doubles next quarter. What breaks first in your v0?
Where answers go wrong
- Proposes an approval model before measuring whether most of the time is spent waiting for documents.
Answer this in two minutes
Write the answer you would say out loud. The clock starts with your first word.
Compare with the model answer
Model answer
“I’ll pin what ‘faster’ measures and why it matters now, find where the days go, split them into working and waiting, and build for the biggest wait first.”
Clarify. “I’ll scope to one product, say term loans under the bank’s streamlined limit, and measure application received to decision. Funding comes later. I’ll also ask why speed matters now. If we’re losing applicants, I count files that die in documents pending as the real cost, not just the days. For risk, I’ll ask credit for the metrics they already report and treat them as limits I may not move. Last quarter’s numbers from the table below are the baseline.”
People. “The head of small-business lending owns the goal. Relationship managers collect documents, underwriters spread financials and write the memo, and credit policy and compliance can veto. In the first two days I’d sit with an underwriter and a relationship manager and walk through one recently decided file’s history, every handoff and every wait.”
Stages and the table. “Received, documents pending, documents complete, underwriting, credit review, then decision or withdrawal. Files bounce back from underwriting to documents, and a file in underwriting can wait on the applicant for a day, so each change of stage or of who holds the ball opens a new row:”
CREATE TABLE application_stage (
application_id bigint NOT NULL,
stage text NOT NULL,
waiting_on text NOT NULL CHECK (waiting_on IN ('applicant', 'bank', 'third_party')),
entered_at timestamptz NOT NULL,
exited_at timestamptz, -- null while the file is still here
assignee text,
PRIMARY KEY (application_id, entered_at)
);
WITH visit AS (
SELECT stage, waiting_on, exited_at,
extract(epoch FROM coalesce(exited_at, now()) - entered_at) / 86400 AS days
FROM application_stage
WHERE stage NOT IN ('decision', 'withdrawn') -- end states never exit
AND coalesce(exited_at, now()) >= now() - interval '90 days' -- last quarter, plus open files
)
SELECT stage, waiting_on,
round(percentile_cont(0.5) WITHIN GROUP (ORDER BY days)::numeric, 1)
AS median_days,
round(sum(days)) AS total_days,
count(*) AS visits,
count(*) FILTER (WHERE exited_at IS NULL) AS open_now
FROM visit
GROUP BY stage, waiting_on
ORDER BY total_days DESC;“Open visits count up to now. Otherwise the files stuck longest, the ones I care about, drop out of the numbers. I sort by total time, not the median, because the bank’s backlog is the sum. Beside it I count withdrawn and silent files by the last stage they reached. If the origination system has no timestamps, I rebuild them from the document upload log and emails for the last quarter’s files.”
“Say last quarter comes back like this, in days:”
stage waiting_on median_days total_days visits open_now
documents_pending applicant 6.5 5140 742 96
underwriting bank 2.0 1480 688 31
credit_review bank 1.0 610 603 12
underwriting applicant 1.5 290 171 9
received bank 0.3 240 760 4“Then the bank’s own steps are not the main wait. Most of the days are files waiting on the applicant, and no model fixes that. Underwriting is the second place to look, and some of its time is the applicant again, answering the underwriter’s questions.”
What I expect and what I’d build. “Before I see the data, my guess is that it looks like that sample: documents pending dominates, and it is mostly waiting on the applicant. If so, v0 is a document chase: a checklist per product checked at submission, and a daily list for each relationship manager of their files missing something, with what is missing and for how long. The chase message can double as the notice of incompleteness that Regulation B allows instead of a notice of action taken (section 1002.9(c)), so compliance approves its wording.”
Automating around a human underwriter. “The underwriter still decides. I can take work off their desk: pull tax transcripts with the applicant’s authorization through the IRS Income Verification Express Service, pull bank statements through a consented data connection, pre-fill the spreading template, and draft the memo’s boilerplate sections for them to edit. If a model extracts the figures from tax returns and bank statements into the spread, the underwriter’s corrections to the pre-fill are my evaluation set, collected for free. I track the fields they correct most, and the extraction never decides anything.”
Guardrails. “Delinquency on booked loans takes months to show, so I also watch leading ones weekly: the exception rate, documents waived at approval, and approval rates by industry, loan size and geography. Compliance runs any fair-lending analysis with its own methods, because Reg B controls when and how the bank may ask an applicant for demographic data. A statistical score for applicants is a model, so it falls under the bank’s model risk management. The federal banking agencies’ revised guidance, SR 26-2, which replaced SR 11-7 and is aimed mainly at the larger banks, says validation generally happens before a model’s first use, with rigor that matches how much the model matters. And if a score contributes to a decline, Regulation B says the reasons given must be specific and name the principal ones; failing to reach a qualifying score is not enough (section 1002.9(b)(2)). That is another reason v0 is a document chase, not a model.”
When volume doubles. “Once documents stop being the wait, the underwriter queue breaks first, since the decision is the one step that still needs a person. I’d show the sponsor that queue’s length each week, so the hiring or policy conversation starts before it backs up. And the stage table breaks if relationship managers batch status updates at the end of the day, so I take timestamps from system events, not status clicks.”