Start with the ledger, not the screen. A checkout button can time out after the payment service has already accepted an operation. Give the order, payment intent and attempt separate identities so a retry can discover the recorded result instead of charging twice.
The official careers page emphasizes payment solutions, ownership and communication. The company overview describes a consumer payment platform. Those sources support product context; they do not verify a fixed interview loop or the exact questions below.
Keep money and time contracts explicit. Use integer minor units or an exact decimal type, record the currency and define how remainders are allocated. For status, prefer an append-only event history or a conditional version update over a sequence of ambiguous booleans.
Reconcile independent evidence. A user-facing confirmation, processor callback and internal ledger entry can arrive at different times. Design a repair path that compares them without turning every late event into another financial action.
Explore your preparation priorities
Choose a focus to see how to prepare.
Define what saved means
Contract: identify the durable state and the evidence that confirms it.
YOUR PREPARATION- Name the logical operation and the state visible before confirmation.
- List the invariants a retry must preserve.
PracHub practice map for a payment state change. Select a checkpoint to connect the system contract, concurrency boundary and failure response to a practice prompt.
Define the payment contract
editorialName the logical order, payment intent and attempt. State the amount, currency and result each identity can represent.
What to demonstrate
- Exact money representation
- Operation identity
How to prepare
- Run the installment exercise with awkward remainders.
- Describe a retry after a lost response.
Protect payment state
editorialModel authorized, captured, failed and refunded transitions. Reject an event that conflicts with the stored order or moves the state backward.
What to demonstrate
- State-machine reasoning
- Concurrency control
How to prepare
- Draw two callbacks racing for the same intent.
- Write the latest-state SQL before designing a cache.
Make recovery auditable
editorialCompare gateway events, internal attempts and ledger rows. Keep a review queue for mismatches rather than silently creating another payment.
What to demonstrate
- Reconciliation
- Safe incident response
How to prepare
- Reproduce the duplicate-charge timeline.
- Prepare a story about a high-impact correctness decision.
PracHub editorial advice for the preparation topics above.
Follow the state, not just the happy path
Choose a scenario to trace what changes.
The expected version still matches the stored state.
- 01Edit version 3Edit version 3.
- 02Compare versionCompare version.
- 03Save version 4Save version 4.
Commit one new version and return durable confirmation.
Use the three save outcomes to reason about a payment state change: a confirmed write, a version conflict and a lost response.
Using floating-point arithmetic for money
Use integer minor units or an exact decimal type and keep currency explicit.
Treating a timeout as a failed charge
Preserve operation identity and query the durable result before allowing another financial action.
Deduplicating only in application memory
Enforce uniqueness at the durable write boundary and retain the accepted result.
Hiding reconciliation mismatches
Expose an auditable review state and separate repair from automatic external side effects.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Split an amount into deterministic installments
Given nonnegative integer cents and a positive installment count, return installments whose sum is exact and whose values differ by at most one cent. Allocate any remainder to the earliest installments. Reject invalid inputs.
Approach
- Use divmod(total, parts) to get the common amount and remainder.
- Add one cent to the first remainder entries. This is O(parts) time and output space.
Worked solution 35 min
- Validate integer inputs and a positive installment count.
- Use quotient and remainder; distribute one extra cent to the earliest remainder positions.
- Check both the exact sum and the maximum difference between installments.
def split_installments(total_cents, parts):
if not isinstance(total_cents, int) or not isinstance(parts, int):
raise TypeError("integer inputs required")
if total_cents < 0 or parts <= 0:
raise ValueError("invalid amount or count")
base, remainder = divmod(total_cents, parts)
return [base + (1 if i < remainder else 0) for i in range(parts)]
Scroll sideways to view long lines.
Follow-up
- How would a different legal or product allocation policy change the contract?
Apply payment events once
Given tenant, intent ID, event ID, state and amount records, preserve first-seen order. Ignore exact replays, but reject reuse of an event ID with different content.
Approach
- Key deduplication by tenant and event ID, then store a fingerprint of the accepted content.
- Validate that every event matches the intended payment identity before changing state.
Follow-up
- How will you expire deduplication records without accepting a very late replay?
Count recent payment attempts
Implement add(timestamp) and count(now) for attempts in (now - 10, now]. Timestamps are nondecreasing, equal timestamps are distinct attempts and the clock may advance without a new attempt.
Which events still count?
The left boundary is excluded; the right boundary is included. Drag past an event to see it enter, then expire 10 seconds later.
See the event values
- At 0s: +1 — expired
- At 5s: +1 — in window
- At 10s: +1 — in window
- At 14s: +1 — not arrived
- At 19s: +1 — not arrived
Synthetic payment attempts at 0, 5, 10, 14 and 19 seconds. Drag the clock: the interval is (now - 10, now], so the lower boundary is excluded.
Approach
- Keep timestamps in a deque and remove values at or before now - 10 before returning the count.
- Reject a backward clock. Every timestamp enters and leaves once, so updates are amortized O(1).
Follow-up
- How would you count per customer while limiting memory for inactive customers?
Find the latest state for each payment intent
Given events(tenant, intent_id, event_id, occurred_at, state), return the latest event per intent for tenant a. Use event ID as the deterministic tiebreaker when timestamps match.
Approach
- Filter to the authorized tenant, then rank by occurred_at and event_id descending within tenant and intent.
- Select rank one before filtering by a particular state.
Follow-up
- How should the query distinguish event time from arrival time?
Reconcile orders and captured payments
For tenant a, return each order and total captured cents. Keep orders with no captures. Multiple order items and payment attempts must not multiply the captured amount.
Approach
- Aggregate captures by tenant and order before joining them to orders.
- Join on the full tenant-scoped key and preserve zero-capture orders with a left join.
Worked solution 35 min
- Aggregate captured attempts at the tenant/order grain.
- Join the aggregate to orders using both tenant and order ID.
- Convert missing capture totals to zero and retain currency for interpretation.
CREATE TABLE orders (tenant TEXT, order_id TEXT, currency TEXT, PRIMARY KEY(tenant,order_id));
CREATE TABLE captures (tenant TEXT, order_id TEXT, cents INTEGER);
INSERT INTO orders VALUES ('a','o1','USD'),('a','o2','USD'),('b','o1','USD');
INSERT INTO captures VALUES ('a','o1',400),('a','o1',600),('b','o1',9000);
WITH paid AS (
SELECT tenant,order_id,SUM(cents) AS captured
FROM captures GROUP BY tenant,order_id
)
SELECT o.order_id,COALESCE(p.captured,0)
FROM orders o LEFT JOIN paid p
ON p.tenant=o.tenant AND p.order_id=o.order_id
WHERE o.tenant='a' ORDER BY o.order_id;
Scroll sideways to view long lines.
Follow-up
- How would refunds change the sign and source of the reconciled total?
Design an idempotent checkout payment flow
Design checkout from order creation through payment confirmation. The client may retry, a worker may crash and the provider callback may arrive before the client response.
Approach
- Create a stable payment intent and require an idempotency key for each logical action.
- Commit internal state and an outbound event atomically. Make provider callbacks replay-safe and reconcile unknown outcomes before presenting another pay action.
Worked solution 35 min
- Create the order and stable payment intent before calling the provider.
- Associate each logical action with an idempotency key and persist its result.
- Record state and an outbox event in one transaction; process provider callbacks through a unique event log.
- Treat a timeout as unknown. Query or reconcile the existing intent before enabling another action.
Follow-up
- Where does authorization end and capture begin in your model?
Design replay-safe provider callbacks
Accept signed provider callbacks that can arrive late, out of order or more than once. Preserve evidence for audit and protect tenant boundaries.
Approach
- Authenticate the sender and store the raw event envelope with a unique provider event ID.
- Project an allowed state change in a transaction. Quarantine conflicts and expose lag or failure metrics.
Follow-up
- How would you replay a corrected projector without repeating external side effects?
Stop a retry from creating a second charge
A checkout request times out after the provider accepted it. The client retries with a new operation ID and a second charge is created. Reproduce the race and specify the repair.
Approach
- Trace the original request through provider acceptance and the lost response. A timeout is an unknown result, not proof of failure.
- Reuse one logical idempotency key, query the recorded result and make the server-side uniqueness check atomic. Reconcile before enabling another action.
Worked solution 35 min
- Pause the first request after provider acceptance and before the response reaches the client.
- Retry with the same logical key; verify the server finds the existing intent.
- Make the uniqueness check and recorded result part of the same durable transaction boundary.
- Quarantine any conflicting retry and reconcile existing provider activity before another charge.
Follow-up
- What data would you need to repair already duplicated financial activity safely?
A seven-session PracHub practice plan with one reviewable artifact per session. Adjust the pace to your experience and interview date.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Define the payment contract
- Map order, intent, attempt and provider event identities.
- State amount, currency and success evidence.
Deliverable: A payment state map
02Make money exact
- Run the installment solution.
- Add awkward remainders and invalid inputs.
Deliverable: A tested money function
Practice prompt ↗03Protect state transitions
- Write latest-state SQL.
- Deliver tied and out-of-order events.
Deliverable: A state transition table
Practice prompt ↗04Reconcile evidence
- Run the capture query.
- Add another tenant and repeated attempts.
Deliverable: A verified reconciliation fixture
Practice prompt ↗05Design retries
- Walk through lost client and provider responses.
- Name the atomic uniqueness rule.
Deliverable: An idempotent checkout design
Practice prompt ↗06Debug duplication
- Reproduce the second-charge race.
- Define safe remediation evidence.
Deliverable: A failure timeline
Practice prompt ↗07Rehearse decisions
- Explain one correctness story and one delivery disagreement.
- Review the weakest system assumption.
Deliverable: Two evidence-backed stories
Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Use real examples. Name your responsibility, the evidence available at the time and what changed after the decision.
Explain a high-impact correctness decision
Describe a change involving money, identity or access where you found a plausible but incorrect result.
Approach
- State your responsibility, the information available and the consequence of being wrong.
- Explain the decision, the verification step and what changed afterward.
Follow-up
- What new evidence would make you choose differently?
Resolve a delivery-versus-safety disagreement
Describe a real disagreement about shipping a risky change. What evidence and guardrails changed the decision?
Approach
- State your responsibility, the information available and the consequence of being wrong.
- Explain the decision, the verification step and what changed afterward.
Follow-up
- What new evidence would make you choose differently?
Communicate during an uncertain payment incident
Tell a story where the team did not yet know whether an external action had succeeded.
Approach
- State your responsibility, the information available and the consequence of being wrong.
- Explain the decision, the verification step and what changed afterward.
Follow-up
- What new evidence would make you choose differently?
- 01
Bring one result you improved and one decision you changed after seeing evidence.
Are these verified Sezzle interview questions?
No. They are PracHub editorial exercises informed by official payment-product and careers context. The reviewed official pages do not publish a universal question list.
Sezzle — Careers ↗Sezzle — Company overview ↗Should I use one particular language?
Use the language named in your opening. The examples use Python and SQLite to make the contracts runnable; translate the tests and invariants to your interview stack.
Is seven days enough?
The checklist is a suggested sequence, not a readiness guarantee. Repeat weak areas and follow the schedule for your exact interview.
Sources & methodology 5 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01Sezzle — Careers ↗
Official mission, values and workplace context; no universal interview process is stated.
official · Accessed 2026-09-20 - 02Sezzle — Company overview ↗
Official description of Sezzle as a payment platform and Public Benefit Corporation; product facts only.
official · Accessed 2026-09-20 - 03Python — Decimal arithmetic ↗
Technical reference for exact decimal reasoning.
official · Accessed 2026-09-20 - 04PostgreSQL — Window functions ↗
Technical reference for SQL reasoning. Runnable fixtures below use SQLite.
official · Accessed 2026-09-20 - 05PracHub — Software Engineer practice ↗
Cross-company practice; not evidence of company interview questions.
platform · Accessed 2026-09-20
Explore related engineering environments and compare the preparation focus.
SolarWinds Software Engineer Interview Questions & Guide 2026
Prepare for observability engineering by reasoning about telemetry identity, bounded ingestion, tenant scope and evidence-driven incident response.
Mux Software Engineer Interview Questions & Guide 2026
Prepare for video-platform engineering with explicit asset state, replay-safe webhooks, bounded pipelines and useful quality evidence.
Snowflake Software Engineer Interview Guide 2026
Snowflake provides a cloud SQL data platform for storage, analytics and data processing.
Qorvo Software Engineer Interview Questions & Guide 2026
Prepare for hardware-adjacent software by making units, deterministic inputs, simulation provenance and stale-worker protection explicit.