1 min lesson
The technical / domain screens
Say what this means in practice: "Expect one or more roughly hour-long rounds that split into two halves."
Step 1 of 3
Expect one or more roughly hour-long rounds that split into two halves: live finance-engineering problems and a structured deep-dive on a past billing or ERP implementation. Both reward driving the conversation - stating assumptions, naming trade-offs and connecting choices back to scale and audit.
Use this stage map to decide what evidence belongs in each round. Memorizing the order is the shallow version. For every stage, prepare one artifact, one story and one question that shows how you reason in the role.
Learn more
Advanced table
The two halves of the technical/domain screen
- Problem type
- Live SQL
- What you'll be asked to do
- Reconciliation queries, revenue waterfalls, ARR/bookings/billings roll-forwards, data-quality checks
- What's graded
- Correctness on edge cases, idempotency, controls thinking
- Problem type
- Finance data modeling
- What you'll be asked to do
- Model the path from CPQ/quote → order → usage → invoice → payment → GL
- What's graded
- Auditability, immutability, where the revenue subledger sits
- Problem type
- Integration design
- What you'll be asked to do
- Keep billing, usage and the GL consistent and reconcilable
- What's graded
- Idempotency, reconciliation strategy, handling eventual consistency
- Problem type
- Functional ERP depth
- What you'll be asked to do
- Set up subscription/usage revenue recognition, multi-book/multi-currency consolidation
- What's graded
- Whether you'd configure or build and why
- Problem type
- Implementation deep-dive
- What you'll be asked to do
- Walk through a past ERP/billing build: architecture, build-vs-configure, what failed
- What's graded
- Honest retrospective, technical ownership, judgment
| Problem type | What you'll be asked to do | What's graded |
|---|---|---|
| Live SQL | Reconciliation queries, revenue waterfalls, ARR/bookings/billings roll-forwards, data-quality checks | Correctness on edge cases, idempotency, controls thinking |
| Finance data modeling | Model the path from CPQ/quote → order → usage → invoice → payment → GL | Auditability, immutability, where the revenue subledger sits |
| Integration design | Keep billing, usage and the GL consistent and reconcilable | Idempotency, reconciliation strategy, handling eventual consistency |
| Functional ERP depth | Set up subscription/usage revenue recognition, multi-book/multi-currency consolidation | Whether you'd configure or build and why |
| Implementation deep-dive | Walk through a past ERP/billing build: architecture, build-vs-configure, what failed | Honest retrospective, technical ownership, judgment |
The two halves of the technical/domain screen: hands-on problems and a structured deep-dive on real implementation work.
-- Reconcile invoiced amount vs cash applied per invoice, flag variances.
-- Keyed to avoid double-counting partial payments; nets credit memos.
WITH invoiced AS (
SELECT invoice_id, customer_id,
SUM(line_amount) AS invoiced_amt
FROM billing.invoice_lines
WHERE invoice_status = 'posted'
GROUP BY invoice_id, customer_id
),
applied AS (
SELECT invoice_id,
SUM(applied_amount) AS cash_applied
FROM ar.cash_applications -- one row per payment->invoice link
GROUP BY invoice_id
),
credited AS (
SELECT invoice_id,
SUM(credit_amount) AS credits
FROM ar.credit_memos
GROUP BY invoice_id
)
SELECT i.invoice_id, i.customer_id,
i.invoiced_amt,
COALESCE(a.cash_applied, 0) AS cash_applied,
COALESCE(c.credits, 0) AS credits,
i.invoiced_amt
- COALESCE(a.cash_applied, 0)
- COALESCE(c.credits, 0) AS open_variance
FROM invoiced i
LEFT JOIN applied a USING (invoice_id)
LEFT JOIN credited c USING (invoice_id)
WHERE i.invoiced_amt
- COALESCE(a.cash_applied, 0)
- COALESCE(c.credits, 0) <> 0; -- only the rows that don't tie