Interview guides · APS Medical Billing

APS Medical Billing Software Engineer Interview Guide

APS Medical Billing Software Engineer interview guide: reported rounds, billing and coding topics, REST, SQL and behavioral answers, plus a 7-day plan.

The 60-second brief

APS Medical Billing is a medical billing company, and the Software Engineer role is about building and maintaining the software behind billing work: designing new features, improving existing applications and working alongside product and operations colleagues. Topics candidates tie to this loop include revenue cycle management, pathology medical coding (CPT, HCPCS and ICD codes), claims processing systems, payment processing and remittance handling, and RPG programming on IBM i. In practice that means software whose output is money and paperwork: a claim goes to a payer, a remittance comes back, and an engineer's code has to keep both sides reconcilable.

This guide is for engineers preparing for the Software Engineer interviews at APS Medical Billing. It covers the two reported stages, the technical, problem-solving and behavioral questions candidates report, the languages and tools reported for the role (Java, C# or Python; .NET or Angular; SQL and NoSQL databases; AWS or Azure as a plus), and a seven-day plan that ends with spoken practice.

Candidates report two stages over roughly two to four weeks: a Screening Call about your background and fit, then one or more Technical Interviews on technical knowledge and problem solving. Only one loop has been reported, so treat the order and count as a sketch.

Focus areas

Medical Billing / Revenue Cycle Management (RCM)
Pathology Medical Coding (CPT/HCPCS/ICD)
Claims Processing Systems

Overview

The reported questions fall into three groups: technical (REST services, synchronous versus asynchronous programming, database experience and query optimisation, a hard bug, the languages you are strongest in), behavioral (pressure, disagreement, leading a project, motivation, prioritising deadlines) and problem-solving (designing a billing feature, troubleshooting, assessing application performance, investigating a billing error, improving a user interface). Several of them can be answered with one well-chosen story, so build a small bank of stories and reuse them.

The domain is what separates this loop from a generic web-developer loop. Medical billing generally runs as a cycle: a visit is recorded, procedures and diagnoses are coded (CPT and HCPCS codes describe procedures, supplies and services; ICD codes describe diagnoses), a claim goes to the payer, the payer adjudicates it, a remittance advice comes back, payments are posted against the claim, and denied or short-paid claims are reworked. Be able to draw that cycle and say where software sits in it. Requirements candidates describe list knowledge of healthcare regulations as a plus, so learn the vocabulary even if you have never worked in healthcare.

For the billing-error scenario and the feature-design question, domain thinking turns generic answers into specific ones. Money fields should be decimal types, never floating point. Payment requests need idempotency so a retry cannot post twice. Corrections should be new adjusting entries, not overwritten rows, so the history stays auditable. Claim state changes should be explicit and logged. If you can say these things in your own language of choice, you are preparing for this loop rather than for a generic one.

Check your stack coverage against what candidates report: Java, C# or Python; .NET or Angular; SQL and NoSQL; optionally AWS or Azure; and RPG on IBM i appears among reported topics. You will not know all of it. Decide what you can discuss in depth, and for the rest be candid about where your experience stops and what the nearest equivalent is that you have used.

The APS Medical Billing interview process

Candidates describe two stages, and the descriptions below are what they report rather than a published process; the number of technical interviews can vary.

Screening Call

Candidates describe the Screening Call as an initial conversation about your background and how you fit the role. No specific questions are tied to it. Treat it as the first test of whether you can explain your experience clearly and connect it to medical billing software, and be ready to talk about the stack the role lists (Java, C# or Python, SQL, and web frameworks).

What to demonstrate

Your background and how it maps to the Software Engineer role
How clearly you communicate your experience
Fit with the role as you describe it

How to prepare

Write a short walk through your career that ends at this role, naming the languages and databases you have used in production.
Prepare one or two sentences on why medical billing software interests you, based on something real such as an interest in payments, data accuracy or healthcare.
Learn the claim lifecycle well enough to draw it, so a domain question does not catch you cold.
Write down your questions for them, for example how the team splits work between new features and maintaining existing applications.

Technical Interviews

The Technical Interviews are reported as one or more sessions on technical knowledge and problem solving. Candidates link the loop to REST services, sync versus async programming, database work, debugging and designing or investigating things in a billing context. Which questions land in which session is not reported, so prepare every question type rather than guessing.

What to demonstrate

Working knowledge of programming languages, frameworks and databases
How you break down a problem and explain your reasoning
How you approach troubleshooting and performance

How to prepare

Rehearse the REST answer with a concrete resource such as claims or remittances: URLs, verbs, status codes, idempotent payment requests, pagination.
Prepare your query-tuning story with a before and after measurement, and the execution-plan reading that led to the fix.
Work through the billing-error investigation and the new-feature design aloud, using decimals for money and an audit trail for corrections.

Where candidates lose points

Describing REST as 'use HTTP and JSON' with no design choices

Anchor the answer in a resource such as claims or remittances: nouns in URLs, correct verbs and status codes, pagination, versioning, and an idempotency key so a retried payment request cannot post twice.

Answering the database question with products used instead of a measured tuning result

Prepare one story with the slow statement, the execution plan, the cause (such as a wrong-order composite index or an N+1 pattern), the fix and the before and after numbers.

Treating the billing-error scenario as a generic bug hunt

Use a sequence that fits money: scope the affected claims, compare the claim against the remittance, check recent releases and code mappings, check rounding and duplicate postings, correct with adjusting entries and add a reconciliation check.

Having no vocabulary for the domain, so CPT, HCPCS, ICD, claim and remittance are unfamiliar words

Spend a session on the claim lifecycle and write one sentence for each term. Candidates describe healthcare knowledge as a plus, and a little vocabulary makes your design answers concrete.

Using the same vague story for pressure, disagreement and troubleshooting

Build a bank of four distinct stories, each with a situation, your decision, a measurable result and a lesson, and map each story to the prompts it can serve before the interview.

Questions & practice

What are the key differences between synchronous and asynchronous programming?

Medium · Technical / Domain Questions

Approach

Start with the definitions: synchronous code blocks the calling thread until the operation returns, while asynchronous code starts the operation, frees the thread, and resumes in a callback, future or await once the result is ready.
Separate concurrency from parallelism: async/await on one event loop (Python asyncio, Node) interleaves tasks on one thread, while threads or processes can run work in parallel. Async helps I/O-bound work such as HTTP or database calls, not CPU-bound work; in CPython the GIL means CPU-bound work needs processes.
Name the language mechanics for the stack candidates describe: C# Task with async/await, Java CompletableFuture or virtual threads (Java 21), Python asyncio coroutines.
Give the pitfalls: one blocking call (time.sleep, a sync DB driver) inside an event loop stalls every task; in C#, calling .Result or .Wait() on a Task can deadlock where a SynchronizationContext exists (classic ASP.NET, UI threads); exceptions in unawaited tasks can be lost.
Extend to system level: a message queue between services is asynchronous processing too, trading immediate consistency for resilience, and it needs retries, idempotent consumers and a dead-letter queue.

Follow-up

What happens if you call time.sleep inside an asyncio coroutine, and what should you use instead?
How would you cap the number of concurrent outbound calls to a payer API?
When would switching a service to async make it no faster or even slower?

Track a rolling failure rate per destination for circuit decisions

Easy · sliding window · ring buffer · circuit breaker

The egress service delivers about 1,500 webhooks per second across roughly 40,000 destinations, each call bounded by a 10 second timeout. Maintain, per destination, the failure rate over the trailing 60 seconds so a caller can ask before dispatch whether the circuit should open. Attempts arrive as (destination_id, finished_at_ms, outcome). Requirement: amortised O(1) per attempt, with total memory bounded by the destination count rather than by traffic. Give the structure, its exact memory, and the rule that stops a destination with three attempts from opening a circuit.

Approach

Name the exact-deque version and then reject it as the default. Holding timestamps and advancing a tail pointer past anything older than now minus 60 seconds is a correct two-pointer window at amortised O(1) per attempt, but its memory tracks in-window traffic, so one destination in a retry storm holds hundreds of thousands of entries while thousands of quiet destinations hold none.
Use a ring of 60 one-second buckets per destination, each bucket a pair of counters for attempts and failures. On an attempt, advance the ring by the elapsed whole seconds, zeroing at most min(elapsed, 60) buckets, then increment the head. That is amortised O(1) with a fixed footprint per destination.
State the footprint: 60 buckets times two 4-byte counters is 480 bytes of payload per destination, so 40,000 destinations is roughly 20 to 25 MB with per-entry overhead, bounded by the catalogue rather than by the rate. The cost is granularity, since the oldest bucket ages out in whole seconds, which is far tighter than the decision needs.
Require a minimum sample before the circuit may open. A destination with three attempts and three failures reads as 100 percent and is not evidence; a floor of roughly 20 attempts in the window makes the ratio meaningful, and below that floor use a run of consecutive failures as the trigger instead.

Follow-up

The fleet is 30 instances and each sees roughly a thirtieth of a destination's traffic. Where does the rate actually live, and what does a per-instance answer get wrong?
A destination answers in 9.5 seconds and succeeds. It is not failing but it is consuming your per-destination concurrency. What signal should open the circuit here?

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.

Approach

Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.

Follow-up

A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?

Keep soft-deleted accounts from blocking re-registration

Easy · soft delete · unique constraints · engine differences

app_user holds user_id, tenant_id, email CITEXT, password_hash (NULL for SSO principals), email_verified_at, auth_version, status ('invited','active','suspended','deactivated'), created_at, updated_at, deleted_at. Two live accounts for one address inside a tenant must be impossible, but an address freed by a soft delete must be reusable, and the same tenant may delete and re-register it repeatedly. Write the uniqueness DDL for PostgreSQL 16, then the equivalent for MySQL 8 where partial indexes do not exist, and say what each permits once three deleted rows already hold that address.

Approach

Start from what is actually unique: not (tenant_id, email), but (tenant_id, email) among live rows. PostgreSQL says that directly — CREATE UNIQUE INDEX app_user_live_email ON app_user (tenant_id, email) WHERE deleted_at IS NULL. A full constraint over the same two columns burns the address permanently the first time someone deletes an account.
Keep case-insensitivity in the type or the index, never in the application: CITEXT as given, or UNIQUE (tenant_id, lower(email)) as an expression index where the extension is unavailable. A case-sensitive unique column is exactly how two accounts for one human appear.
For MySQL 8 the predicate has to move inside the key: add a discriminator column that is a constant 0 while the row is live and is set to user_id on delete, with UNIQUE (tenant_id, email, deleted_marker). Live rows share the constant and still collide; deleted rows differ from each other and stop colliding.
State the NULL variant and its dependency: leaving the marker NULL for deleted rows also works, because a unique index treats NULLs as distinct — true in MySQL, and true in PostgreSQL only under the default NULLS DISTINCT, which PostgreSQL 15 lets you reverse. Check the polarity against the three existing deleted rows: constant-on-live is what preserves the collision you want, and reversing it silently admits duplicate live accounts.

Follow-up

A deleted account re-registers with the same address the next day. Do the old resource rows follow the new user_id, and how does the API keep the two principals apart?
How do you honour an erasure request while resource_revision.actor_user_id still references this table?

Write the update path that detects a concurrent edit

Medium · optimistic concurrency · transactional outbox · audit history

resource carries version INT NOT NULL DEFAULT 1. resource_revision holds revision_id, resource_id, version, actor_user_id, change_kind, patch JSONB, request_id, created_at with UNIQUE (resource_id, version). outbox_event holds aggregate_type, aggregate_id, aggregate_version, event_type, payload, status. A PUT carries the version the client read. Write the exact statements for the single transaction that applies the edit, records the revision and enqueues 'resource.updated', and give the handler's branch on zero affected rows. Then say what PostgreSQL 16 does under READ COMMITTED when two of these updates hit one row at once.

Approach

One transaction, three writes, no network call inside it: UPDATE resource SET title = $3, version = version + 1, updated_at = now() WHERE resource_id = $1 AND tenant_id = $4 AND version = $2; then INSERT the resource_revision row at version $2 + 1; then INSERT the outbox_event row at the same aggregate_version. The event goes to a table rather than a broker because no transaction spans both.
Branch on the affected-row count before doing anything else. Zero has three causes — stale version, wrong tenant, row gone — so re-read once and map to 409 carrying the current version, or 404 for an id outside the caller's tenant, which also stops the endpoint confirming that another tenant's id exists.
State the engine behaviour instead of assuming it. Under READ COMMITTED the second UPDATE blocks on the row lock, and when the first commits PostgreSQL re-evaluates the WHERE clause against the newly committed row, so the version predicate now fails and the statement reports zero rows. Under REPEATABLE READ the identical collision raises SQLSTATE 40001 instead, so the handler must fold both shapes into one conflict response.
Keep UNIQUE (resource_id, version) even though the predicate already serialises writers. It is what makes a lost update unwritable if any other path ever reaches the revision table, and it converts a logic bug into 23505 rather than into a silently missing history row.

Follow-up

A client sends the version it read ten minutes ago and the resource has moved three versions. What is in your 409 so it can resolve the conflict without a full re-fetch?
Two editors, two disjoint fields, no overlap. Does your answer still refuse the second write, and should it?

Explain the concept of RESTful services and how you would implement them in a project.

Medium · Technical / Domain Questions

Approach

Define REST as resource-oriented HTTP: nouns as URLs (/claims/{id}, /claims/{id}/payments), standard methods for actions, stateless requests that carry their own auth, and representations (usually JSON) rather than RPC-style verbs in the path.
Get method semantics right: GET, PUT and DELETE are idempotent, POST is not, and PATCH is not guaranteed to be. Return precise status codes: 201 Created with a Location header, 204 for an empty success, 400/422 for validation errors, 404, 409 for a conflict.
For a money-moving POST such as posting a payment, accept an Idempotency-Key header and store the key with the result, so a client retry after a timeout returns the first response instead of posting twice.
Cover the implementation details: an OpenAPI spec written before the code, cursor-based pagination for large lists, versioning (/v1 in the path or a header), ETag with If-Match so a stale update gets 412 Precondition Failed, and auth over TLS with OAuth2 or JWT bearer tokens.
Close with the trade-off: REST is simple and cacheable but can over-fetch or need several round trips, which is where GraphQL or a purpose-built endpoint can be the better fit.

Follow-up

What is the difference between PUT and PATCH, and which would you use to update one field on a claim?
How do you make a payment-posting endpoint safe for a client to retry?
How would you version the API without breaking existing consumers?

Can you discuss a challenging bug you encountered and how you resolved it?

Medium · Technical / Domain Questions

Approach

Pick a bug with a real root cause you found yourself, and tell it as a debugging sequence: symptom and impact, reproduction, hypotheses, the evidence that killed each wrong one, the root cause, the fix.
Show the techniques by name: a minimal reproduction, logs and correlation IDs, a debugger or added instrumentation, git bisect to find the commit that introduced it, and comparing a working input with a failing one.
Distinguish the symptom from the cause. Strong examples are a race condition, a time-zone or date-boundary error, or money stored as a binary float (0.1 + 0.2 != 0.3), fixed by switching to decimal types or integer cents.
End with prevention: the regression test that reproduces the bug, plus the monitoring, validation or code-review check that would have caught it earlier.

Follow-up

How did you confirm that was the root cause and not a coincidence?
What would you have done if you could not reproduce it locally?
What changed in your process afterwards so it did not recur?

What programming languages are you most comfortable with and why?

Medium · Technical / Domain Questions

Approach

Name one or two languages you can defend in depth rather than listing everything. Tie each to a project and to the requirements candidates describe for this role: Java, C# or Python, with .NET and Angular mentioned as frameworks.
Give concrete, checkable reasons: C# has reified generics and LINQ, while Java generics use type erasure; both are statically typed and garbage-collected. Python is dynamically typed, quick for scripting and data work, and has a decimal module for exact money arithmetic.
State a real weakness of your favorite language and how you work around it, for example Python's runtime type errors handled with type hints and mypy, or Java verbosity reduced with records.
Candidates report RPG Programming (IBM i / RPG) among the topics, so explain how you would get productive in an unfamiliar or legacy language: read the existing code, learn the data access patterns, and pair on small changes first.

Follow-up

How does your preferred language represent money, and what goes wrong with floating point?
What is a feature of another language you wish yours had?
How would you approach maintaining code in a language you have never used?

How would you approach designing a new feature for a billing system?

Medium · Problem-Solving / Case Studies

Approach

Clarify the feature first: who uses it (billing staff, providers, patients), what problem it solves, and what success looks like. Then pick a concrete example, such as patient payment plans or claim-denial tracking.
Sketch the data model: patient, encounter, charge lines (CPT/HCPCS procedure codes, ICD-10 diagnosis codes), claim, payment, adjustment. Keep the ledger append-only, and store money as decimal or integer cents, never float.
Model claim status as an explicit state machine (created, submitted, accepted or rejected, paid, denied, appealed), allow only valid transitions, and write an audit row for every change.
Cover correctness and compliance: idempotent payment posting, reconciliation against remittances, role-based access and encryption for patient health information, and the HIPAA minimum-necessary principle when deciding which fields each screen and API returns.
Plan the rollout: a backward-compatible schema migration with backfill, a feature flag, tests for rounding and partial payments, and a reconciliation report that compares totals before and after release.

Follow-up

How would the design handle a partial payment followed by a contractual adjustment?
How would you change the schema without downtime while claims are being processed?
What would you test first, and how?

How would you assess the performance of an application?

Medium · Problem-Solving / Case Studies

Approach

Define performance before measuring it: latency percentiles (p50, p95, p99) rather than averages, throughput, error rate and resource use, against a target set by the user-facing operation.
Measure top-down: APM or distributed tracing to find the slow span, then a profiler on the hot path (py-spy or cProfile for Python, JFR or async-profiler for Java, dotnet-trace for .NET).
Check the database early: the slow-query log, EXPLAIN ANALYZE for scans versus index use, N+1 query patterns from an ORM, missing indexes, and lock contention.
Load-test with realistic data volumes (k6, JMeter or Locust) to find the saturation point, and check utilization, saturation and errors for CPU, memory, disk and connection pools.
For the front end, measure Core Web Vitals (LCP, INP, CLS) and bundle size. Change one thing at a time and re-measure to confirm the fix.

Follow-up

Average latency looks fine but p99 is bad. What could cause that?
You find an N+1 query in a list endpoint. How do you fix it?
How would you load-test realistically without using production patient data?

Present a hypothetical scenario where a billing error occurs. How would you investigate and resolve it?

Medium · Problem-Solving / Case Studies

Approach

Set up a concrete scenario (for example, patients billed twice, or claims paid at the wrong rate), then scope it before touching code: which records, since when, how much money, and which payers or providers. Contain it by pausing the affected batch or statement run.
Trace one bad record end to end with SQL and logs: charge entry, coding, claim generation, submission, remittance and payment posting. Compare expected and actual amounts at each step to find where they diverge.
Check what changed: recent deploys, fee schedule or payer rule updates, and data imports. Common causes are a retry without an idempotency key that posts a payment twice, rounding from float arithmetic, or a time-zone error that shifts the date of service.
Fix the code, then correct the data with reversing and adjusting entries, never by editing history. Identify every affected account with a query, and resubmit corrected claims where needed (in X12 837, frequency code 7 replaces a claim and 8 voids it).
Prevent recurrence with a regression test, a unique constraint or idempotency check, and an automated reconciliation that alerts when posted totals and remittance totals disagree.

Follow-up

How would you find every account the error touched, and verify that the correction is complete?
Why correct with adjusting entries instead of updating the original rows?
What alert would have caught this before a patient or payer noticed?

Discuss how you would implement a solution to improve the user interface of a software application.

Medium · Problem-Solving / Case Studies

Approach

Start from evidence, not taste: support tickets, analytics (task completion rate, time on task, error and abandonment rates), and watching real users of a specific workflow such as charge entry or a denial work queue.
Name the concrete problem, sketch options, and test a clickable prototype with a handful of target users before building. Billing staff who use the screen all day may value keyboard shortcuts and dense tables over visual polish.
Implement incrementally: reusable components (in Angular, reactive forms with validators give inline error messages), behind a feature flag, with a way back to the old screen.
Build accessibility in: semantic HTML, labelled inputs, full keyboard navigation, and WCAG 2.1 AA contrast (4.5:1 for normal text), checked with axe or Lighthouse and a screen reader.
Measure the same metrics after release as before, or A/B test where the traffic allows, and roll back if error rates or task time get worse.

Follow-up

How would you show the new interface actually improved things?
Experienced users push back on the change. What do you do?
How would you test accessibility before release?

Every query on one table stalls for forty seconds mid-deploy

Medium · lock contention · ddl · migrations

During a release on PostgreSQL, every query touching resource times out for about 40 seconds and then recovers with no intervention. The release ran one migration, ALTER TABLE resource ADD COLUMN archived_reason TEXT, and the migration log shows it completing in 6 ms. Unrelated tables showed no change in error rate. Explain how a 6 ms statement caused a 40-second stall, give the ordered checks you would run on a live system to confirm it, and give the migration procedure that prevents a repeat.

Approach

Separate the statement's duration from the lock's duration. ADD COLUMN with no default is a catalogue-only change and genuinely runs in milliseconds, but it requires ACCESS EXCLUSIVE, and it cannot acquire that until every transaction already touching the table has finished.
Account for the queueing, which is the part that surprises people. A lock request that is waiting blocks later requests for conflicting modes behind it rather than letting them overtake, so one long-open transaction holds the DDL and the DDL holds all the traffic. The stall length is set by the longest open transaction, not by the size of the change.
Confirm on a live system in this order: pg_stat_activity for that table ordered by xact_start, looking for the oldest transaction and specifically for state = idle in transaction; then pg_locks where granted = false to find the waiter; then join them on pid to name blocker and blocked. pg_blocking_pids() does that join for you and is the fastest single call.
Prevent rather than merely time it better. Set lock_timeout to a second or two on the migration session so the DDL abandons the queue after a bounded wait and is retried, instead of holding it for as long as the oldest transaction lives. Be exact about what that buys: queries arriving during the wait still queue behind the pending ACCESS EXCLUSIVE request, so each attempt costs them up to one lock_timeout of added latency. The outage goes from 40 seconds to about one second per attempt, not to zero. Also run migrations away from deploy-time peaks, and put a statement timeout and an idle-in-transaction timeout on the analytics role that opens the long transactions.

Follow-up

The same release also wants NOT NULL on that column. What is the sequence that gets there without a long lock?
Your lock_timeout retry fails ten times in a row because the analytics transaction is always open. What do you change?

Suggested practice checklist

Seven days built around the two reported stages: first the domain and data model, then the technical questions, debugging and design, then behavioral stories and a full spoken run.

Day 1 — Map the loop and learn the billing vocabulary

Write out the two reported stages, Screening Call and Technical Interviews, and note which question types you are least ready for.
Draw the claim lifecycle from visit to remittance and payment posting, including where denials return for rework.
Write one sentence each defining CPT, HCPCS and ICD codes, claim, remittance advice and denial.

Deliverable: A one-page loop map, a claim lifecycle diagram and a glossary of the billing terms, with your weakest areas marked.

Day 2 — Data model and database experience

Sketch tables for patient, claim, claim line, procedure code, payer, remittance and payment posting, and choose a decimal type for money.
Write three SQL queries over your model, for example unpaid claims past a cutoff date, total paid versus billed per payer, and claims with no remittance.

Deliverable: A schema sketch, three working queries, notes on the two practice exercises and a written query-tuning story.

Day 3 — REST, async and your languages

List the endpoints for a claims and remittance API with verbs, status codes, pagination and an idempotency key on payment creation, in your strongest language among Java, C# or Python.
Write a one-paragraph explanation of synchronous versus asynchronous programming with one example, such as calling a payer service without blocking a worker.
Write your answer on which languages you are strongest in, with one trade-off for each and what you would reach for on a new project.

Deliverable: An endpoint list, an async explanation paragraph and a language answer, each rehearsed aloud once.

Day 4 — Debugging and performance

Write your challenging-bug story: symptom, hypotheses, root cause, fix and test.
Write a performance assessment checklist: define the target, measure latency percentiles and error rate, find the bottleneck with a profiler or query timings, load test, change one thing at a time and re-measure.

Deliverable: A debugging sequence, a finished bug story and a performance checklist.

Day 5 — Design a billing feature and investigate a billing error

Pick one feature, such as a payment-posting screen, and design it aloud: requirements, data model, states, audit trail, failure handling and rollout.
Run the billing-error scenario: scope the affected claims, compare claim and remittance, check recent changes, rounding and duplicates, correct with adjusting entries and add a reconciliation check.
Outline how you would improve a user interface: observe real users, find the slowest or most error-prone step, change it, and measure again.

Deliverable: A feature design, an investigation sequence for a billing error and a UI improvement plan, each in outline form.

Day 6 — Behavioral story bank

Write four stories in situation, decision, result and lesson form: one under pressure, one disagreement, one where you led, one troubleshooting a significant issue.
Add one real number to each story and cut anything that describes what the team did rather than what you did.
Record yourself telling each story and fix the one that rambles.

Deliverable: Four stories with measured results and a mapping of which prompts each story can answer.

Day 7 — Full spoken run

Run a mock Screening Call: your career walk-through, why this company and your questions for them.
Answer the motivation and prioritisation questions aloud without notes.

Deliverable: A rehearsed walk-through, spoken answers to the motivation and prioritisation questions, and a list of what to revise.

Behavioural preparation

Candidates report behavioral questions about pressure, disagreement, leading a project, motivation, prioritising deadlines and troubleshooting. A story bank of four or five real examples covers them: each needs your own decision, a measurable result and a lesson, and the troubleshooting story should show a clear diagnostic sequence.

Describe your experience with database management systems and how you optimize queries.

Medium · Technical / Domain Questions

Approach

Open with one or two systems you have really worked on, naming the engine (for example SQL Server, PostgreSQL, MySQL, Oracle or a NoSQL store) and your role: schema design, writing queries or tuning in production. Say plainly what you did and did not own.
Tell one tuning story in order: the symptom with a number (a worklist page that took many seconds), how you found the slow statement (slow-query log or query store), how you read the execution plan, the cause, the fix and the measurement afterwards. Typical causes are a full scan, a composite index in the wrong column order, a function wrapped around an indexed column, N+1 queries from an ORM, SELECT * on wide rows and OFFSET pagination.
A billing-shaped example works well: a claims table filtered by status and date range for a work queue. A composite index on (status, service_date) serves the filter and the sort, and keyset pagination avoids scanning skipped rows.
Name the trade-off: each index slows inserts and updates and takes space, statistics can go stale, and a plan that is fast on a test database can differ on production-sized data. State how you verified on realistic data.
The mistake that sinks this answer is a list of database products with no measured result. Name one query, one plan and one number.

Follow-up

How do you decide between adding an index and rewriting the query?
When would you choose a NoSQL store over a relational database for this kind of data?
How would you debug a query that is fast in test and slow in production?

Describe a time when you had to work under pressure. How did you handle it?

Medium · Behavioral / Leadership

Approach

Choose a story with a real constraint such as a fixed release date, a production incident or a sudden scope change, and state it in two sentences. Do not pick a story where you only waited it out.
Show triage: what you listed, what you cut or deferred, what you protected, and who you told early. For billing-style software, correctness of money and claim data is the thing to protect before scope.
Give the concrete actions: splitting the release, putting the risky part behind a feature flag, writing the test for the highest-risk path first, rolling back instead of patching live.
Close with the outcome and what changed afterwards, such as a runbook, a monitoring alert or a revised estimate process, so the story shows you reduced the next occurrence of the pressure.
Avoid answers whose only technique is working late. Say how you kept quality up while time was short.

Follow-up

What did you cut, and who agreed to the cut?
Did the pressure cause any mistakes, and how did you catch them?
How do you tell when you should ask for more time instead of pushing through?

Give an example of how you handled a disagreement with a team member.

Medium · Behavioral / Leadership

Approach

Pick a technical disagreement with real stakes, such as an API shape, a schema decision, a library choice or how to roll something out. A personality clash gives you nothing to analyse.
State the other person's position fairly, in terms they would accept, then your own. This shows you understood the disagreement rather than just resisted it.
Describe how you resolved it with evidence: a small prototype, a benchmark, a written comparison of options, a review with a third engineer, or agreeing to try one option behind a flag and measure.
State the outcome honestly. If you conceded, say what you learned; if your option won, say how you kept the working relationship. Never present it as you being right and them coming round.
Keep blame out of it, and finish with what you now do earlier to avoid the same disagreement, for example writing a short design note before building.

Follow-up

What would you have done if you had still disagreed after the evidence?
How did your working relationship with that person change afterwards?
When would you escalate a disagreement instead of resolving it yourselves?

What motivates you to perform well in your job?

Medium · Behavioral / Leadership

Approach

Pick one or two drivers and prove each with a moment from your work. 'I like challenges' is empty; 'I reworked a nightly import after an incorrect total reached a report, and I felt uneasy until I had tests around it' is specific.
Connect the driver to this role honestly. Software for billing and claims produces money and records, so if accuracy, reliability or seeing a process work end to end really motivates you, say so with evidence. Do not claim an interest in healthcare you cannot back up.
Show the driver in behavior: what you do differently because of it, such as reading production data after a release, writing the extra test, or volunteering for the awkward legacy module.
Keep the answer short and finish with a sentence that links it to the kind of work you would do on the team.
Avoid answers that are only about pay or title, and avoid motivation that depends on constant novelty if the role includes maintaining existing applications.

Follow-up

Tell me about a time that motivation was missing and what you did about it.
How do you stay engaged on maintenance or bug-fix work?
What would make you want to leave a job?

Share an experience where you took the lead on a project. What was the outcome?

Medium · Behavioral / Leadership

Approach

Choose a project where you owned the outcome, not just the title. Say the goal, the team size and the date or constraint in a sentence or two.
Show how you led: how you broke the work into pieces, how you assigned them, how you ran code review, and which decisions you made yourself versus which you took to the group.
Include one difficulty, such as a teammate falling behind, a requirement changing midway or a technical dead end, and say exactly what you did about it.
Give the outcome with a concrete measure: what shipped, what improved, what it replaced. If the outcome was mixed, say so and say what you would change.
Avoid describing a project the team did while you contributed one piece. The story needs your decisions.

Follow-up

How did you handle a teammate who was falling behind?
What would you do differently if you led it again?
How did you decide what to leave out of the first release?

How do you prioritize tasks when you have multiple deadlines?

Medium · Behavioral / Leadership

Approach

State your method before the story: write every commitment down with its deadline, estimate each, rank by impact and cost of delay, and check dependencies, since a small task that unblocks others moves up.
Make the ranking visible and confirm it with the people who own the work. When everything is 'top priority', ask the owner to rank them and show what slips in each ordering.
Give one concrete case with two deadlines colliding. Say what you shipped first, what you negotiated (smaller scope, later date, help from someone) and when you told stakeholders.
A billing example: a defect that mis-posts payments costs more every day it is open than a cosmetic improvement due the same week, so correctness defects rank first.
Say how you re-plan when something urgent arrives, and avoid the answer that you simply work longer.

Follow-up

What do you do when two stakeholders each insist theirs comes first?
How do you tell stakeholders you are going to miss a deadline?
How do you handle interruptions without losing the planned work?

Describe a time when you had to troubleshoot a significant issue. What steps did you take?

Medium · Problem-Solving / Case Studies

Approach

Pick an incident or bug with real impact. Start with scope: who was affected, since when, and what evidence told you so (error rate, a customer report, a reconciliation mismatch).
Describe stabilising before diagnosing: rollback, feature flag, a workaround, or pausing a job, so the damage stopped growing.
Walk through diagnosis as a sequence: reproduce, list hypotheses, test the cheapest first, using logs, the diff of recent deploys, metrics and bisecting where useful. Name what you ruled out.
State the root cause rather than the symptom, the fix, the test that now covers it and any data repair needed. With billing-style data, say how you reconciled affected records afterwards.
Finish with prevention: a monitor, a runbook or a blameless write-up. The mistake to avoid is a story that jumps straight to the fix.

Follow-up

How did you know it was the root cause and not a symptom?
What did you add so it cannot happen silently again?
What would you have done if you could not reproduce it?