Assist-x Software Engineer Interview Guide

The 60-second brief

Candidates describe Assist-x as a healthcare technology company whose software supports patient access, therapy enrollment and clinical support workflows. Software Engineers there work across the stack: candidates name Angular on the frontend, backend services behind it, and integration with Salesforce, and .NET appears among the technologies the role asks for. The engineering themes candidates report are maintainable code, automated testing and code review, with TDD and design patterns coming up repeatedly in conversation. Healthcare or other regulated-industry experience is reported to count in a candidate's favour.

This guide is for mid-level and senior Software Engineers, the range candidates report for this role, preparing for an Assist-x loop as a full-stack engineer with Angular, .NET or Salesforce exposure. It covers the six reported rounds, question-specific answers to the eight questions candidates report (four on technical practice, four on behaviour and teamwork), the mistakes that cost candidates on those question types, and a seven-day plan that ends with a working practice application and a full mock.

Candidates report six stages over roughly 4-6 weeks: Initial Screening, Technical Discussions, Leadership Discussions, Practical Programming Assessment, Cultural Fit Assessment and Final Decision. Much of the loop is conversational, and some candidates also report having to finish a working application.

Focus areas

• Angular
• .NET
• Salesforce Development

Overview

Candidates describe the work as building software for patient-access and therapy-enrollment workflows: Angular frontends, backend services, and integration with Salesforce, with .NET listed among the required skills. Candidates also report that the technical interviews favour class modelling, design patterns and explaining architectural decisions over algorithm puzzles. That changes what you prepare: instead of grinding puzzle problems, build a set of project stories in which you can name the design, the alternatives you rejected, the tests you wrote and what you would change now.

The reported questions fall into two groups. Four are about technical practice: your experience with TDD, how you approach design patterns and class modelling, whether you lean frontend, backend or full-stack, and your experience with .NET frameworks. Four are behavioral: an introduction, handling disagreements with managers or teammates, what you look for in a team culture, and a time you advocated for a technical approach. The technical ones are open prompts, so a vague answer is easy to give and easy to see through. Answer each with one concrete project, the technique named precisely (red-green-refactor, Strategy over a switch statement, scoped versus transient lifetimes) and the trade-off it carried.

Two more reports shape preparation. Some loops include a practical programming assessment in which candidates finish a working application, so arrive with a project scaffold you can start from, a habit of getting one feature working end to end before widening it, and tests written along the way. Candidates also report that several interviewers have an affinity for the book The Software Craftsman, so know its main ideas (professionalism, deliberate practice, TDD, pairing, being able to say no) well enough to agree or disagree with them using your own experience.

The Assist-x interview process

Candidates report six rounds over roughly 4-6 weeks, from an initial screening to a final decision, with a practical programming assessment in some cases. The stages below follow the order candidates describe.

Initial Screening

Candidates report that the loop opens with a screening stage that checks basic qualifications. Use it to establish the match quickly: a full-stack engineer at the mid-to-senior level candidates report for this role, with whatever Angular, .NET or Salesforce work you actually have. Keep your introduction structured and short, and use the call to find out which later stages apply to you, since candidates report the practical programming assessment appears only in some loops.

What to demonstrate

• Basic qualifications for the role, which is what candidates report this screen checks
• How clearly you summarise your experience and the stack you have worked in

How to prepare

• Write a present-past-future introduction: current role and stack, one shipped project with a measurable result, and why healthcare software interests you.
• Know where your experience sits across frontend, backend and integration work, with one concrete example for each layer you claim.
• Ask the recruiter which of the later rounds apply to you, including whether your loop has a practical programming assessment and what it involves.

Technical Discussions

Candidates describe in-depth technical discussions about technical proficiency, and report that some interviews are open conversations rather than a whiteboard session. They also report that the technical interviews centre on modelling classes, applying design patterns and explaining architectural decisions. Approach it by steering open questions toward your strongest project and walking through it as a design narrative: the problem, the class structure, the alternatives, the trade-off you accepted and what you would change.

What to demonstrate

• Class modelling and the use of design patterns, as candidates report for the technical interviews
• How well you explain architectural decisions and their trade-offs
• Technical depth in your own past work, discussed conversationally

How to prepare

• Pick two projects and write each as a design narrative: components, key classes, one rejected alternative and why, and one thing you would redo.
• Practise modelling a small domain aloud (for example an enrollment workflow): name the classes, their responsibilities and where a pattern such as State or Strategy fits.
• For each pattern you might mention, have one real case from your code where it solved a specific problem, and one case where it would have been overkill.

Leadership Discussions

Candidates report that this stage focuses on leadership qualities and team dynamics. For an individual-contributor engineer, leadership usually means influence without authority, so prepare stories where you moved a technical outcome or helped others do better work, and stories about friction inside a team that you handled well. Each story needs your specific action and a result, not a description of what the team did.

What to demonstrate

• Leadership qualities, as candidates report for this stage
• How you operate within team dynamics, including friction and feedback

How to prepare

• Write a story about mentoring through code review: a review comment that changed how a teammate wrote code, and how you phrased it.
• Write a story about driving a technical decision you did not own outright: the options, the evidence you gathered and how you got agreement.
• Write a story about friction in a team and the specific step you took to resolve it, including what you would do differently.

Practical Programming Assessment

Candidates report that in some cases they complete a practical programming task, and that it can involve finishing a working application. The reported format puts a premium on delivering something that runs, so the order of work matters: get one thin feature working end to end, then add tests and edge cases, then tidy structure and naming. Hand in code that someone else can run without asking you how.

What to demonstrate

• Delivering a working application, which the reported format requires
• The quality of the code you hand over: structure, naming and the tests you include

How to prepare

• Build a small practice app in your strongest stack (an Angular client over a .NET API if that is yours): one list view, one create form, one validated endpoint.
• Keep a ready project setup with the test runner configured and a README template covering run steps and known gaps.
• Practise writing tests alongside the code rather than at the end, so the submission reflects the testing habits you describe in conversation.

Cultural Fit Assessment

Candidates report an assessment of fit with the team and the company's values, and describe fit here as being humble, eager to learn and able to work well with others. Treat it as a behavioral round with its own evidence: stories that show you learning something new quickly, taking critical feedback, and putting the team's outcome ahead of being right. Candidates also describe the process as two-way, so bring real questions about how the team works.

What to demonstrate

• Fit with the team and company values, as candidates report
• Humility, willingness to learn and collaboration, the qualities candidates associate with fit

How to prepare

• Prepare a story of learning a new framework or tool under delivery pressure: what you did first, how you checked your understanding, and what shipped.
• Prepare a story of receiving critical feedback on your code or design and what you changed afterwards.
• Write three questions about how the team works day to day, such as code review norms, how tests are run and how technical disagreements get settled.

Final Decision

Candidates report that the final decision rests on all of the earlier assessments and discussions; no separate interview content is reported for this stage. Candidates also report that pace varies, so your part here is follow-through: stay in touch with your recruiter and make sure nothing you promised in an earlier round is left open.

What to demonstrate

• The record from every earlier round, which candidates report the decision draws on
• The practical programming assessment result, in loops that include one

How to prepare

• After your last interview, send a brief follow-up that refers to one specific technical point you discussed.
• Keep notes of each round's questions and your answers so you can respond precisely if the recruiter asks for anything more.
• Agree with your recruiter on when you should hear back, and follow up if that date passes.

Where candidates lose points

Describing TDD as a principle with no example from your own code, or claiming you test-first everything.

Bring one feature you built test-first: the first failing test, the mock or fake you used for the database or external API, and the refactor the tests made safe. Also name where you skip test-first (spikes, layout, legacy code) and what you do there instead, such as characterization tests.

Naming design patterns (Singleton, Factory, Repository) without the problem each one solved.

For every pattern you mention, state the force first (rules that vary, an entity with statuses, an external system to wrap) and then the pattern. Keep one example where you removed a pattern because it added indirection without benefit.

Treating the conversational technical rounds as small talk and answering open questions in generalities.

Candidates report some interviews are open-ended rather than whiteboard sessions. Arrive with two or three project narratives covering class structure, alternatives and trade-offs, and steer open questions toward them.

Handing in a practical programming assessment that does not run, or runs without tests or instructions.

Get one thin feature working end to end before adding anything else, write tests as you go, and include a README with run steps and the shortcuts you took. A smaller working application beats a larger broken one.

Disagreement and advocacy stories in which the other person is the villain and you were simply right.

State the other side's position fairly, show the evidence you gathered and the point you conceded, and include an outcome plus a lesson. Have one story ready where you changed your own mind.

Questions & practice

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

1. 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.
2. 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.
3. 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.
4. 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?

Merge partitioned event streams into one ordered feed with bounded lateness

Hard · k-way merge · watermarks · out-of-order streams

The read-model service consumes 64 log partitions carrying about 4,000 events per second in total. Each partition is ordered within itself, but partitions drift by up to 30 seconds, and the activity feed must present a tenant's events in occurred_at order. Produce the merge. State its complexity, the buffer it requires in events and in bytes, what happens when one partition is idle, and what you do with an event that arrives after you have already emitted its position. Payloads average 1 KB.

Approach

1. Merge with a min-heap over the 64 partition heads keyed on (occurred_at, event_id): O(log P) per event and O(n log P) overall. The tie-break on event_id is what makes the output deterministic when two partitions carry the same millisecond, which matters because the feed is paginated and a non-deterministic order reorders pages under the reader.
2. Emitting the heap head is only correct once every partition has produced everything up to that timestamp, so the emit condition is a watermark: the minimum across partitions of the highest occurred_at seen, less the allowed lateness. Events are held until the watermark passes them, which is what turns individually ordered streams into a jointly ordered one.
3. Size the buffer from the lateness rather than guessing: 4,000 events per second times 30 seconds is 120,000 buffered events, and at 1 KB each about 120 MB of heap. That number is the real price of the ordering guarantee and belongs in front of whoever asked for it.
4. Handle the idle partition explicitly, because it fails the feed rather than corrupting it: a partition with no traffic never advances its own maximum, so the watermark freezes and output stops entirely. Either every partition emits a periodic idle marker carrying the broker's current time, or the watermark falls back to wall clock for a partition silent beyond a threshold.

Follow-up

• The lateness budget is raised to five minutes. What is the new buffer, and what besides memory changes?
• The consumer restarts. Where does it resume from, and what does the feed look like for the first 30 seconds?

Diff a projection against the primary without per-row point reads

Hard · reconciliation · range hashing · throttling

The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.

Approach

1. Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
2. Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
3. For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
4. Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.

Follow-up

• The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
• Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?

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

1. 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.
2. 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.
3. 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.
4. 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?

Denormalise tenant onto revisions and backfill it live

Hard · denormalisation · online migration · backfill

resource_revision (revision_id, resource_id, version, actor_user_id, change_kind, patch, request_id, created_at) has 400M rows and no tenant column; tenant_id lives only on resource. Two reads need it: a tenant-scoped audit feed ordered by created_at DESC, and an offboarding purge. Both join back to resource today. Justify adding tenant_id to resource_revision against those two reads, name the anomaly the copy introduces and the constraint that prevents it, then give the ordered migration for a live table taking 1.2k writes/second — the lock each step takes, how the backfill is batched, and where each step stops being reversible. PostgreSQL 16.

Approach

1. Justify from the access path rather than from taste. Without the column, the audit feed either scans resource_revision by created_at and discards other tenants' rows, or resolves the tenant's resource_ids first and probes with them — both proportional to the tenant's whole history rather than to one page. With (tenant_id, created_at DESC, revision_id DESC) it is a seek that stops at 50 rows, and the purge becomes a ranged delete instead of a join.
2. Name the cost exactly: a second copy of a fact can disagree with the first. Make the disagreement unwritable rather than documented — add UNIQUE (resource_id, tenant_id) on resource so it can serve as a foreign-key target, then FOREIGN KEY (resource_id, tenant_id) REFERENCES resource (resource_id, tenant_id) on the revision table. A revision can then only ever carry its parent's tenant.
3. Step one, expand: ALTER TABLE resource_revision ADD COLUMN tenant_id BIGINT NULL, with no default, so it is a catalogue change and no rewrite. It still needs ACCESS EXCLUSIVE for an instant, and that instant queues behind the longest open transaction on the table while every later query queues behind it — set lock_timeout to 2s and retry rather than wait.
4. Step two, dual-write: deploy the writer that populates tenant_id on every new revision while reads still use the join. Reversible by redeploying the previous build, because nothing reads the column yet.

Follow-up

• The backfill is half finished and a rollback is required. What state is the table in, and what does the previous build do with a half-populated column?
• How do you verify the backfill actually finished, given rows are still being inserted while it runs?

How do you approach design patterns and class modeling in your day-to-day work?

Medium · Technical and Domain Proficiency

Approach

1. Start from the domain, not the pattern: list the nouns and behaviours, give each class one responsibility, and decide which object owns which state and invariant. Prefer composition over inheritance unless there is a true is-a relationship.
2. Introduce a pattern only when a specific force appears: Strategy when rules vary (for example eligibility rules per program), State when an entity moves through statuses with different allowed actions, Adapter to wrap an external system behind your own interface, Factory when construction logic branches.
3. Check the model against SOLID out loud: single responsibility, open for extension without editing a switch statement, depend on abstractions so you can inject fakes in tests and swap implementations.
4. Walk through one real class model from your work, including the version you got wrong first and the refactor that fixed it.
5. Close with the trade-off: patterns add indirection, so name a case where you removed one because it made the code harder to read.

Follow-up

• Model an enrollment workflow with its statuses. Where would you put the transition rules?
• When would you choose inheritance over composition?
• How does dependency injection in .NET or Angular change the way you design classes?

Are you more comfortable working on the frontend, backend, or full-stack?

Medium · Technical and Domain Proficiency

Approach

1. Give a straight answer first: name your strongest layer, then back it with one deep example from that layer rather than a list of technologies.
2. Show depth in the layer you claim. Frontend: Angular change detection and OnPush, RxJS subscription cleanup with the async pipe or takeUntil, sharing state through injectable services. Backend: API design, data access, async work, error handling.
3. Show you can cross the boundary with one feature you carried end to end: the API contract between the Angular client and the backend, validation on both sides, and how you tested it.
4. Be honest about your weakest layer and what you are doing to close the gap; claiming equal strength everywhere is hard to defend under follow-up questions.
5. Connect it to the stack candidates report for this role (Angular, .NET services, Salesforce integration) without claiming experience you do not have.

Follow-up

• Walk me through a feature you shipped from UI to database.
• How do you design an API so the frontend and backend can change independently?
• Which layer would you rather not work in, and why?

One log partition stops advancing while the others drain

Easy · poison message · head-of-line blocking · consumer lag

Search results for a subset of tenants are hours stale; the rest are current. The projection consumer reports lag of zero on 15 of 16 partitions and 400,000 on one. Its error rate is flat and its CPU is idle. outbox_event has no pending rows older than a second, so the relay has published everything it holds. Identify the mechanism, give the ordered checks, and state what you do in the first ten minutes versus what you change permanently.

Approach

1. Read the lag distribution first. A slow consumer lags everywhere; zero on fifteen partitions and 400,000 on one is not throughput. Idle CPU on the stuck partition means the consumer is not advancing its offset at all, which points at one message it cannot get past rather than at a rate problem.
2. Exonerate the producer before touching the consumer. No pending outbox rows older than a second means the relay published, so the event exists in the log. This separates never sent from sent and never applied, which are different code paths and usually different owners.
3. Read the message at the stuck offset and the handler's log lines for its event_id. A flat error rate with no progress has two explanations and you must distinguish them: the handler is throwing and the retry loop is swallowing it, or the handler is blocking on something and never returning. Idle CPU with no error lines favours the second.
4. Mitigate before diagnosing further. Move the offending event to a dead-letter store and commit the offset past it. Adding consumers does nothing here, because a partition is consumed by exactly one member of the group, and the blast radius is every aggregate hashed to that partition, not only the aggregate that produced the bad event.

Follow-up

• The dead-lettered event carried aggregate_version 7 and the projection had applied 6. What must the replay do differently if 8 and 9 landed in the meantime?
• How do you show staleness to the user while the partition is behind, given the API already returns the projection's watermark?

Suggested practice checklist

Each day targets one reported round or question group: introduction and stack positioning, TDD, class modelling, stack depth in .NET, Angular and Salesforce, a practice build for the programming assessment, behavioral stories, and a full mock across all eight reported questions.

Day 1 — Map the loop and write your introduction

• List the six reported rounds and, for each, write the stories or skills you will rely on; mark the practical programming assessment as a stage to confirm with your recruiter.
• Write and rehearse a present-past-future introduction naming your stack, one shipped project with a result, and why healthcare software interests you.
• Write your frontend, backend or full-stack answer: your strongest layer, one deep example from it, and one feature you carried across the boundary.

Deliverable: A round map with confirmed and unconfirmed stages, a rehearsed introduction, and a written stack-preference answer with two examples.

Day 2 — TDD in your own code

• Do one kata (bowling score or string calculator) strictly red-green-refactor in your main language, committing after each green step so the history shows the cycle.
• Write your TDD story from a real feature: the first failing test, how you isolated a dependency, and one place you chose not to test first and why.
• Write characterization tests around a small piece of untested code, then refactor it, so you have a legacy-code example ready.

Deliverable: A kata repository with a commit-per-step history, a written TDD story from your own work, and one characterization-test example.

Day 3 — Class modelling and design patterns

• Model a therapy-enrollment workflow as a practice domain: classes, responsibilities, statuses and transitions, explained aloud.
• For Strategy, State, Adapter, Factory and Observer, write one problem from your experience where the pattern removed a concrete pain, and one case where it would be overkill.
• Review your model against SOLID and write down the class you had to split and why.

Deliverable: A class diagram for the enrollment practice domain with its SOLID review, and a pattern table with one used and one overkill example each.

Day 4 — Stack depth: .NET, Angular and Salesforce

• .NET: explain the three DI lifetimes and the captive-dependency bug, async/await and why blocking on .Result risks deadlock, and how you would find and fix an Entity Framework N+1 query.
• Angular: explain subscription cleanup with the async pipe or takeUntil, OnPush change detection, and sharing state between components through injectable services.
• Salesforce: write what you know about integrating with it (REST API, OAuth connected apps, API limits); with no experience, write an honest short answer on how you would ramp up.

Deliverable: One page of notes per layer (.NET, Angular, Salesforce integration), each with a real example or an honest gap statement.

Day 5 — Rehearse the practical programming assessment

• Build a small working application in your strongest stack (an Angular client over a .NET API if that is yours): one list view, one create form, one validated endpoint.
• Write tests as you build, then add a README with run steps and the trade-offs you skipped.
• Warm up on the lease-records concurrency practice question: turn records into start and end events, sort them, and sweep to find overlaps and peak concurrency.

Deliverable: A runnable mini-app with tests and a README, plus a working solution to the concurrency practice question.

Day 6 — Leadership, culture and advocacy stories

• Write STAR stories for a disagreement with a manager or teammate and for advocating a technical approach, each with the alternatives, the evidence and the outcome.
• Write your team-culture answer as three concrete practices (code review norms, test automation, how decisions get made), each tied to a team you were on.
• Skim the main ideas of The Software Craftsman (professionalism, deliberate practice, TDD, pairing, saying no) and note where your habits match or differ.

Deliverable: Two STAR stories, a three-practice culture answer, and a one-page note mapping The Software Craftsman to your own habits.

Day 7 — Full conversational mock

• Run a mock in which a partner asks all eight reported questions in random order, with one follow-up on each.
• Re-answer your two weakest responses and cut every sentence that names a pattern or practice without an example.
• Write three questions for your interviewers, such as how the team reviews code or tests its Salesforce integrations.

Deliverable: A recorded mock covering the eight reported questions, two rewritten answers, and three questions to ask.

Behavioural preparation

Candidates report a Leadership Discussions stage on leadership qualities and team dynamics and a Cultural Fit Assessment, and they describe fit as humility, eagerness to learn and working well with others. Prepare stories that show influence without authority, handling friction, and learning quickly, each with your own action and a result.

1. Tell me about a time you had to learn a new framework or tool quickly to deliver a feature.
2. Tell me about feedback on your code that changed how you work.

Describe your experience with TDD (Test Driven Development) and how you apply it in your workflow.

Medium · Technical and Domain Proficiency

Approach

1. Define the cycle precisely: write a failing test that states one behaviour, write the least code that makes it pass, then refactor with the test as a safety net. Say how small your steps really are in practice.
2. Anchor it in one feature you built test-first: the first test you wrote, the framework (xUnit, NUnit or MSTest in .NET; Jasmine or Jest with TestBed in Angular), and how you isolated a database or external API behind an interface with a fake or mock.
3. Name where you do not test first and why: exploratory spikes, UI layout, or untested legacy code, where you start with characterization tests to pin current behaviour before refactoring.
4. Explain the payoff you actually observed (smaller classes, earlier design feedback, safe refactors) and the cost (slower first pass, brittle tests when they assert implementation details instead of behaviour).
5. Mention how it fits the wider suite: many fast unit tests, fewer integration tests against a real database, a few end-to-end tests.

Follow-up

• How do you test code that talks to a database or a third-party API such as Salesforce?
• Tell me about a time TDD slowed you down. What did you change?
• How do you stop a test suite from breaking every time you refactor?

Can you explain your experience with.NET frameworks?

Medium · Technical and Domain Proficiency

Approach

1. Say which .NET you used and when: .NET Framework versus modern .NET (Core, 5 and later), and whether you built ASP.NET Core Web APIs, MVC apps, background services or desktop software.
2. Show runtime-level understanding with specifics: the middleware pipeline, built-in dependency injection and the three lifetimes (singleton, scoped, transient), and the captive-dependency bug when a singleton holds a scoped service.
3. Cover async correctly: async/await all the way down, why blocking with .Result or .Wait() can deadlock or starve threads, and passing CancellationToken through.
4. Cover data access if you used it: Entity Framework Core change tracking, AsNoTracking for read paths, spotting and fixing N+1 queries with Include or projection, and migrations in a team setting.
5. Finish with one problem you diagnosed in .NET (a slow endpoint, a memory leak, a deadlock) and the sequence you used to find it.

Follow-up

• What is the difference between a scoped and a transient service, and when does it matter?
• How would you migrate an application from .NET Framework to modern .NET?
• How would you find out why one API endpoint got slow?

Please tell me about yourself.

Medium · Behavioral and Professionalism

Approach

1. Use present, past, future: what you do now and in which stack, one or two past projects that show the range of the role, and why this role and healthcare software is the next step.
2. Pick projects that match what candidates report the role covers (Angular frontends, backend services, Salesforce or other integrations, testing practice) and give each a concrete result.
3. Keep it short enough to finish before you are interrupted, and end on a hook you want to be asked about, such as a design you are proud of.
4. Avoid reciting your CV in date order; the job history is already on paper, so spend the time on decisions and outcomes.

Follow-up

• Why are you leaving your current role?
• Which project you mentioned are you proudest of, and why?
• What draws you to healthcare software?

How do you handle disagreements with managers or teammates?

Medium · Behavioral and Professionalism

Approach

1. Use STAR with a real disagreement over substance (a design, a deadline, a scope cut), not a personality clash; state both positions fairly, including the strongest version of the other side's.
2. Show the steps you took: understanding the other person's constraint, gathering evidence such as a quick spike, a benchmark or data from production, and discussing it privately before escalating.
3. Cover the manager case explicitly: if overruled after making your case, commit fully and say how you would raise it again if new evidence appeared.
4. Give the outcome and the lesson. A story where you were simply right and the other person was wrong sinks the answer; one where you changed your mind, or both views improved the result, works better.

Follow-up

• Tell me about a disagreement where you turned out to be wrong.
• What would you do if your manager overruled you and the decision went badly?
• How do you handle a disagreement that comes up in code review?

What do you look for in a team culture?

Medium · Behavioral and Professionalism

Approach

1. Answer with concrete practices instead of adjectives: how code review is done, whether tests run on every change, how technical decisions get made and recorded, and how incidents are reviewed without blame.
2. Tie each practice to a team you were on: what it looked like there, and what happened when it was missing.
3. Say what you contribute to that culture, for example review comments that explain the reason, pairing on hard changes, or keeping the build green.
4. Candidates report a craftsmanship theme in these interviews, so if those values are genuinely yours, connect them to clean code and testing; do not adopt the vocabulary if you cannot back it with examples.

Follow-up

• Describe a team culture that did not work for you. What did you do about it?
• What would you change first in a team that ships fast but has few tests?
• What do you do when a team norm conflicts with how you prefer to work?

Describe a situation where you had to advocate for a specific technical approach.

Medium · Behavioral and Professionalism

Approach

1. Use STAR and open with the decision and the options: what you advocated for, at least one serious alternative, and the criteria you used (risk, maintainability, delivery date, team skill).
2. Show how you built the case: a short spike or prototype, a measurement, a written design note circulated for comments, and who you persuaded and in what order.
3. Describe how you handled objections, including a point you conceded or a change you made to your plan because of feedback.
4. Give a measurable outcome and what you would do differently; advocating by authority or volume, or never naming an alternative, weakens the story.

Follow-up

• What was the strongest argument against your approach?
• What would you have done if your approach had failed in production?
• Tell me about a time you advocated for something and lost.