As a Software Engineer at DeepTek Medical Imaging, you are at the intersection of advanced artificial intelligence and healthcare innovation. You will be responsible for building, maintaining, and scaling the software infrastructure that powers medical imaging solutions, directly impacting how clinicians diagnose and treat patients globally. Your work involves translating complex medical data into actionable insights, ensuring high availability, and optimizing performance for mission-critical applications.
This role requires a blend of deep technical expertise and a product-focused mindset. You will work within agile, high-performing teams to solve challenging engineering problems, ranging from backend service architecture to efficient database management. Whether you are optimizing a notification system or designing robust APIs, your contributions are central to DeepTek Medical Imaging’s mission to make medical imaging more accurate and accessible.
Technical Fundamentals Assessment
reportedInput bounds are the part of the prompt most often skimmed, and they usually contain the answer. They tell you which complexity class is admissible, which narrows the search before you have thought about the problem itself. As a rough planning figure, a compiled language does on the order of 10^8 simple operations per second and an interpreted one roughly an order of magnitude less. So n up to about twenty admits enumerating subsets, a few thousand admits a quadratic pass, and a million admits neither: you need near-linear, or linear with a log factor. If the bounds are missing, ask for them.
What to demonstrate
- Whether the approach is justified by the stated input size rather than by whichever pattern you recognised first
- Whether you ask about the properties that change the algorithm: whether the input arrives sorted, whether duplicates occur, whether values are bounded integers, whether it all fits in memory
- Whether you can name the bottleneck in your own solution and what would remove it, even when you deliberately leave it in place
- Whether a claimed speedup is real, since memoising a recursion only helps when subproblems genuinely overlap and the state can be keyed cheaply
How to prepare
- For each algorithm you rely on, write down the largest n it handles in roughly a second, then check two of those figures by timing them in the language you will actually type in
- For two weeks, write one line naming your target complexity and the bound that justifies it before you write any code, then compare that line with what you ended up submitting
- Practise the conversion backwards: given a required O(n log n), list the mechanisms that get you there (sorting, a heap, an ordered map, divide and conquer) and choose by what the problem needs to query, not by what you used last
Practical Engineering Scenarios
reportedYou cannot drill a format you do not know, so put the preparation into material that travels. Three pieces of your own work, each rehearsed until you can take a follow-up you did not anticipate, will carry a conversation or a code walkthrough equally well. Specificity is what separates that from filler. A number needs its definition before it means anything: a p99 is over some window and measured at some hop, and a server-side figure excludes the queueing and network time a client would see. The number you cannot qualify is the one to leave out.
What to demonstrate
- Whether your examples carry detail only someone who did the work would hold, such as what the binding constraint actually was, which alternative you rejected and why it was worse, and what you measured on each side of the change
- Whether a number survives one follow-up, meaning you can say what it was measured over and whether it moved because of your change or merely alongside it
- Whether a failure is described with the specific change that followed it, rather than a lesson stated in general terms
- Whether your part in a team effort is stated accurately, including what other people did
How to prepare
- Write a page on each of three projects covering the constraint, the option you rejected, the measurement before and after, and what went wrong. Cut any line you cannot take a follow-up on, since you are writing the parts you will be pressed on rather than a summary.
- Recover the real figures while you still have access: request volume, data size, latency with its percentile and window, team size, timeline. Note where each came from, whether a dashboard, a design document or memory, and mark the estimates so you can say which they are out loud.
- Take your weakest project story to someone who works in a different area and have them ask why four times in succession. The point where you run out of answer is the part to go and re-read before the round.
Project Discussions
reportedWhen a round has no standard shape, it is often there because something is still open: an area no earlier conversation reached, a round where the signal came out mixed, or a decision someone is not ready to make alone. Work out which by going back over what each earlier round actually covered rather than how it felt, and arrive able to give evidence on that point without being asked twice. Weak answers replay the loop's earlier material at the same depth. Strong ones go a level deeper and stay consistent with what you already said.
What to demonstrate
- Whether your account of a project matches the one you gave earlier in the loop, since what you said before may be available to whoever runs this round
- Whether you can go a level deeper on something already covered, reaching the decision and its alternatives rather than repeating the summary
- Whether you state your own uncertainty accurately, including parts of a system you did not build and decisions you inherited, instead of claiming even ownership across all of it
- Whether you can answer a question you handled poorly earlier by naming what you missed, rather than delivering a polished second version as if the first had not happened
How to prepare
- Reconstruct the loop on one page: for each round, the questions you were asked and the answer you actually gave, not the better one you thought of afterwards. The gaps on that page are your best available guess at why this round exists.
- Take the two claims you made earlier that carry the most weight and assemble the backing for each: the measurement, the date, what broke, the decision you would make differently now.
- Write down the three facts about your work that must not drift between tellings, such as team size, timeline and your own role, and check your stories against that list rather than trusting recall under pressure
PracHub editorial advice for the preparation topics above.
Writing the access audit record inside the read transaction, or firing it off after the response with no durability.
Inside the transaction, an audit-store outage blocks clinical reads and turns a logging dependency into a care outage. Fire-and-forget afterwards means the audit trail is incomplete during precisely the incidents it exists to reconstruct, and the gaps are invisible until someone asks for the log. The usual resolution is committing the access decision and its audit row together to a local outbox and shipping asynchronously, which keeps the read path available while preserving durability.
Storing monetary amounts as floating-point numbers.
Binary floating point cannot represent values like 0.10 exactly, so summing allowed and paid amounts across millions of claim lines accumulates representation and rounding error. Reconciliation against a remittance file is exact to the cent, so the drift surfaces as a balance that is off by a few cents with no identifiable cause, and engineers lose days looking for a logic bug in code that is correct apart from its numeric type. Integer minor units or an exact decimal type removes the class entirely.
Never running a concrete value through the code
Trace one small input and one edge input by hand, index by index, out loud. Re-reading your own code catches design mistakes; walking a real value through it catches the off-by-one, the uninitialised accumulator and the loop that never advances.
Hardcoding to the sample inputs
Solve the stated problem rather than the two examples; special-casing a literal to make a sample pass is obvious immediately and reads as either a misunderstanding or an attempt to fake progress. If you genuinely cannot generalise yet, say which part is a stub and what would replace it.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Merge twelve resource streams into one patient summary page
A patient summary fans out to between 8 and 12 resource types. Each returns a network-backed, paged iterator of resource versions sorted by issued_ts descending, up to 200,000 versions per type for one person. Return the 50 most recent current versions across all types, where current means no later version supersedes it within the same logical resource, and a logical resource whose current version is entered_in_error is omitted entirely. You may not materialise the iterators. Give time and space in terms of k types, the result size and the page size.
Approach
- k-way merge with a max-heap holding one head per iterator, keyed on issued_ts. Seeding is O(k), each pop is O(log k), so reaching R emitted rows costs O(k + P log k) for P pops, with O(k) heap space plus one page buffered per iterator. Fetching everything and sorting is O(V log V) over V up to 2.4 million versions and drags every page across the network to produce 50 rows.
- Suppress with a hash set of logical resource ids already seen, recorded on first sight whether or not that version is emitted. A logical resource has exactly one resource type, so all of its versions arrive on one iterator, and that iterator is descending in issued_ts: the first version you see for a logical resource is its newest. Deciding on first sight and suppressing every later pop for that id is therefore correct in one pass with no lookahead.
- Count emits, not pops. A correction-heavy chart can burn many pops per emitted row, so a loop that stops at 50 pops returns a short page. Put a bound on total pops as well, and when it trips, return what you have with a continuation token rather than spinning.
- Break issued_ts ties deterministically on (resource type, resource id). Without it two identical requests return two different orderings and the next page silently skips or repeats rows.
- Handle entered_in_error at first sight: the erroneous version still supersedes its predecessor, so record the id in the seen set and emit nothing, dropping the whole logical resource instead of falling back to the value it replaced. Recording it is the load-bearing half. Skip it and the next pop re-displays the value a clinician already retracted.
- Summarise the budget honestly: the composite p99 is what the user feels, and it is bounded below by the slowest of the k iterators, so the merge fixes the ordering cost but not the fan-out tail.
Worked solution 25 min
- Seed the heap with the head of each iterator and an empty emitted-id set.
- Pop the maximum by issued_ts, push that iterator's next head, and check the logical resource id against the set.
- On first sight record the id, then emit unless that version is entered_in_error; on a repeat sight suppress. Stop when emits reach the target.
- Return the rows plus a continuation token carrying the last (issued_ts, type, id) tie-break tuple.
Follow-up
- One of the twelve iterators has a p99 of 400ms while the rest return in 20ms. What is your composite p99 and what would you change first?
- The user pages to rows 51 through 100. How do you resume without re-reading from the top, and what breaks if issued_ts is not unique?
- One resource type is accidentally returning ascending order. How would your code detect that rather than quietly emitting the oldest rows?
Resolve enterprise identity from a link log that supports unmerge
person_identity_link holds link_id, enterprise_person_id, assigning_authority, source_person_id, match_score, link_status (auto_linked, manual_linked, potential_duplicate, unlinked, rejected), version, superseded_by_link_id, decided_by, decided_at. You have up to 40 million source identities and 60 million decisions applied in decided_at order. Build a structure answering which enterprise identity a given (assigning_authority, source_person_id) resolves to after any prefix of the log, and supporting a revert of the k most recent merges at O(1) each. State the query complexity, and say why path compression is unavailable to you.
Approach
- Intern the node key as the pair (assigning_authority, source_person_id) into a dense integer index. Never key on source_person_id alone: two facilities in one network routinely issue the same medical record number to different people, so a bare-value key merges two patients before any matching logic has run, and a single-source test fixture will never show it.
- Classify the log rows before touching the structure. auto_linked and manual_linked are unions; potential_duplicate and rejected are recorded decisions that must not union anything; unlinked is a revert of the link it supersedes, not a new edge.
- Use union by size with an explicit undo stack, pushing (attached_root, its previous parent, the previous size of the absorbing root) on every union. Find walks parent pointers to the root: union by size bounds tree height at log2(n), so a query is O(log n) worst case, a union is O(log n), and a revert pops two words and is O(1).
- Path compression is the thing you have to give up, and the reason is specific: it rewrites parent pointers of nodes that were never named in the union being recorded, so the undo entry no longer describes the mutation that happened and a revert restores a forest that is quietly wrong. Near-constant find is only available to an append-only structure.
- Hold enterprise_person_id as a property of the root slot rather than a value copied onto every member. A merge then relabels one slot instead of n rows, and an unmerge restores two labels instead of reconstructing n.
- State the price plainly: every read path gains a resolution hop and no downstream table can carry a plain patient_id column. That cost is what buys reversibility, and it belongs in the design discussion rather than being discovered later by whoever writes the first join.
Follow-up
- A merge is found wrong three weeks and 200,000 unions later, and your stack only reverts a suffix. What do you do instead, and what does that cost?
- A claim was posted under the losing identity before the merge. After the unmerge, which identity owns it, and what in your design let you answer that?
- Two matcher instances submit unions concurrently. What is the smallest change that keeps both the structure and the undo stack consistent?
Flag a requester reading too many distinct charts per window
You consume access-audit records (event_ts, requester_id, enterprise_person_id, purpose_of_use, break_glass) at tens of thousands per second, non-decreasing in event_ts. For each requester, emit an alert the first time any sliding 600-second window contains reads of more than D distinct enterprise_person_ids. Break-glass reads count toward the window and are also reported separately. Return (requester_id, window_start_ts, distinct_count). Target O(1) amortised per event and memory proportional to the events resident in the window, not to the day.
Approach
- Per requester, hold a deque of (event_ts, person_id) and a hash map from person_id to its occurrence count inside the window, plus a running distinct counter. Push on the right; while the front is older than event_ts minus 600 seconds, pop it, decrement its count and erase the key when the count reaches zero, decrementing the distinct counter. Each event is pushed once and popped once, so the amortised cost is O(1) and the memory is O(W) for window occupancy W.
- Test the threshold immediately after each push and nowhere else. Between two consecutive events the window can only lose members as its left edge advances, so the maximum distinct count over all window positions is attained at a position whose right edge is an event. Checking at pushes is therefore exhaustive rather than a sampling approximation.
- Latch the alert per requester and re-arm only when the distinct count falls back below D, otherwise one busy stretch emits thousands of near-identical rows and the real signal is buried by its own volume.
- Bound memory both per requester and globally. A requester whose window legitimately holds tens of thousands of reads must not hold the process hostage, so cap the deque and degrade above the cap to an approximate distinct counter such as HyperLogLog, stating the error you accept in exchange.
- Count break-glass toward the window but carry it in its own output field. Break-glass has to succeed during an emergency, which is exactly why it must be the most visible path in the audit, and excluding it from the count would make the abuse route the quiet one.
- State the precondition: this is correct only while input is non-decreasing in event_ts. Out-of-order arrival needs a bounded-lateness buffer and a watermark, and dropping late events without a counter is the failure that hides itself.
Follow-up
- One region's events arrive up to 90 seconds late. What buffer do you add, and what does that do to alert latency?
- One person uses two requester accounts. What has to change in the key, and what new false positive does that introduce?
- How do you restore window state after a process restart without replaying the whole day?
Fix a paid-amount report that double counts claim versions
claim_line: claim_line_id, claim_id, claim_version smallint, line_number, frequency_code in ('original','replacement','void'), enterprise_person_id, coverage_id, billing_provider_npi, service_from_date, procedure_code, units, billed_amount_cents bigint, allowed_amount_cents, paid_amount_cents, adjudication_status, UNIQUE (claim_id, claim_version, line_number). A monthly report sums paid_amount_cents and joins coverage_span on enterprise_person_id with date overlap to attribute a plan. It overstates payment by roughly 9%, and reconciliation against remittance fails. Name both causes, then write the corrected query returning paid cents and plan per billing_provider_npi for March 2026 service dates.
Approach
- Cause one: the SUM spans every claim version. A replacement supersedes a prior claim and a void cancels one, so a replaced claim contributes twice and a voided claim contributes once when it should contribute nothing. Resolve the surviving version per claim_id before aggregating, never by deleting superseded rows.
- Cause two: the coverage join is one-to-many. coverage_span carries a system-time version per coverage period, so a person with three beliefs about one period multiplies every claim line by three. The join is for a label, not for filtering, so it must not be allowed to change cardinality.
- Collapse the version chain with DISTINCT ON (claim_id) ... ORDER BY claim_id, claim_version DESC, then join the lines back on (claim_id, claim_version), and exclude the surviving version when its frequency_code is 'void'.
- Make the coverage lookup cardinality-safe with a LEFT JOIN LATERAL ... LIMIT 1 pinned to valid_to = 'infinity' and ordered by valid_from DESC. LATERAL with LIMIT 1 cannot fan out by construction; a plain join can, and no amount of later DISTINCT repairs a SUM that already doubled.
- Keep the money in integer minor units the whole way. SUM(bigint) returns numeric in PostgreSQL, so there is no overflow and no binary floating-point error; cast to a display type only at the edge.
Follow-up
- A replacement arrives before its original. Your surviving-version logic picks max(claim_version) — what does the report show in the window before the original lands, and does the number self-correct?
- Add a claim_line_adjustment table with several reason codes per line. What does that do to this query, and where do you aggregate to keep it safe?
- Reconciliation is still off by 400 cents. Which of the two causes could still produce that, and what is your next query?
Denormalise consent into a decision table with a stated staleness bound
Access governance answers 'may this requester read this person's data for this purpose' on every identified read — tens of thousands per second at a 5ms p99 — from consent_directive: consent_id, enterprise_person_id, version, scope, purpose_of_use text[], grantee_org_id (NULL meaning all organisations), permit boolean, effective_ts, expires_ts, revoked_ts, status. Evaluating the normalised version history per read misses the budget. Design the denormalised decision store and its key, state the revocation staleness bound in seconds and the mechanism that actually enforces it, and say which normalised rows remain the system of record and why.
Approach
- Derive the shape from the read, not from the source table. The read is a point lookup on (person, grantee organisation, purpose), so fan the purpose_of_use array out into one row per purpose and make those three columns the primary key. A GIN index on the array would serve containment queries nobody issues.
- Handle the wildcard concretely. grantee_org_id NULL means 'all organisations', and NULL never equals anything, so a nullable column in the key breaks both the primary key and the equality lookup. Store a sentinel org id of 0 for the wildcard and resolve specific-before-wildcard in the lookup, or the wildcard row is silently unreachable.
- Make refusal a row, not an absence. An explicit permit = false must outrank a permit for the same key, so carry a precedence rank (specific grantee beats wildcard, refusal beats permit at equal specificity) and resolve with ORDER BY rank LIMIT 1. Default deny when nothing matches, so a rebuild failure fails closed.
- Separate the two staleness mechanisms and be precise about which one is the bound. The in-process decision cache has a TTL; a revocation also publishes an invalidation. The publish shortens the typical case to milliseconds, but it can be lost, so the guaranteed bound is the TTL alone — quote that number, for example 30 seconds, and justify it against the cache hit rate you need to hold 5ms p99.
- Evaluate expires_ts at read time against the request clock rather than baking the decision. A cached permit whose expires_ts has passed is wrong regardless of invalidation, because no event fires when a timestamp simply goes by.
- Keep consent_directive as the system of record: audit must reconstruct the directive in force at any past instant, the decision table holds only current state, and a corrupted decision table must be rebuildable by replaying the directives. Bound the write amplification by keeping grantees at organisation granularity and purposes a closed code set, so one directive expands to a known small number of rows rather than an unbounded cross product.
Worked solution 40 min
- Write the decision table DDL with the three-column primary key, the sentinel wildcard, the precedence rank and a monotonic decision_version.
- Write the lookup query: equality on the key with the wildcard row unioned in, ORDER BY rank, LIMIT 1, and an expires_ts predicate evaluated against the request timestamp.
- Write the projection that turns one consent_directive version into its decision rows, and compute the expansion factor for a directive covering four purposes and one organisation.
- State the TTL, then justify it: at N reads per second and M people, compute the cache hit rate the TTL yields and check it against the 5ms p99 budget.
- Write the failure narrative for a lost invalidation and confirm the TTL, not the bus, is what caps exposure.
- Write the rebuild procedure from consent_directive and the assertion that proves the rebuild is complete before it is swapped in.
Follow-up
- Break-glass must always succeed and must be unmistakably marked. Where does it sit relative to this lookup, and what stops it from becoming the quiet default path?
- The invalidation bus is down for thirty minutes. Walk through what a revoked person's data exposure looks like minute by minute, and what the backlog does when the bus returns.
- Where does the access audit record get written so that an audit-store outage degrades neither the log's completeness nor the read's availability?
How does an abstract class differ from an interface, and when would yo…
How does an abstract class differ from an interface, and when would you choose one over the other?
Approach
- Work from the requirement backwards to the design.
- Say what you would check first and why it is the highest-information step.
- State your assumptions explicitly before working the problem.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
What are the fundamental differences between String, StringBuilder, an…
What are the fundamental differences between String, StringBuilder, and StringBuffer?
Approach
- State your assumptions explicitly before working the problem.
- Work from the requirement backwards to the design.
- Say what you would check first and why it is the highest-information step.
Follow-up
- How would you know your answer was wrong?
- What assumption would you test first?
Differentiate between HashMap, ConcurrentHashMap, and ArrayList in ter…
Differentiate between HashMap, ConcurrentHashMap, and ArrayList in terms of usage and performance.
Approach
- State your assumptions explicitly before working the problem.
- Clarify what is being asked and what a complete answer contains.
- Say what you would check first and why it is the highest-information step.
Follow-up
- What assumption would you test first?
- How would you know your answer was wrong?
Explain the hierarchy of exception handling, including the roles of tr…
Explain the hierarchy of exception handling, including the roles of try, catch, and finally blocks.
Approach
- Work from the requirement backwards to the design.
- State your assumptions explicitly before working the problem.
- Clarify what is being asked and what a complete answer contains.
Follow-up
- How would you know your answer was wrong?
- What assumption would you test first?
Authorising every identified read with bounded revocation
Access governance is invoked on every identified read — tens of thousands of decisions per second — and must hold a sub-5ms p99 while evaluating consent_directive (scope, purpose_of_use, grantee_org_id, permit, effective_ts, expires_ts, revoked_ts, status) against organisational policy and relationship to the person. Every decision emits an audit record. Break-glass must always succeed and always be unmistakably marked. Give the cache design, the bound in seconds between a revocation and reads stopping, the mechanism that enforces that bound, and the system's behaviour during a thirty-minute audit-store outage.
Approach
- Put the decision cache in-process, keyed on requester, enterprise_person_id, purpose_of_use and grantee organisation, with the evaluated directive version in the value. A network hop cannot hold a 5ms p99 at that rate once queueing is included, so the local cache is what makes the budget reachable — and it is also what creates the staleness you now have to bound rather than hand-wave.
- Make the bound a hard number enforced by expiry, and treat push invalidation as an optimisation on top. A revocation bus gives sub-second propagation when it works, but a dropped message or a reconnecting subscriber leaves one node stale indefinitely; the entry lifetime is the only ceiling that survives the bus being broken. A 30-second lifetime states the bound as 30 seconds and the bus makes the common case under one.
- Write the access decision and its audit row together into a local outbox table in the same transaction, and ship asynchronously. That single placement is the whole answer to the outage: the read path never touches the audit store, so thirty minutes of downtime produces a growing local backlog and no clinical impact, and the backlog drains in order afterwards.
- Size the outbox so it is a bounded promise rather than an assumption: state the disk the backlog consumes at peak decision rate for the longest outage you will tolerate, and define the behaviour when it fills. Silently dropping records is the one unacceptable option, because the gaps land precisely in the incidents the log exists to reconstruct.
- Implement break-glass as a separate path that evaluates no policy, always permits, writes a distinguished audit record carrying the asserted reason, and enqueues a review with a committed turnaround. The deterrent is the review, not friction in the path — friction during an emergency is a clinical safety problem.
Worked solution 30 min
- Write the cache key and value, then state the revocation bound in seconds and name the single mechanism that guarantees it when the bus is down.
- Write the outbox schema and the transaction that commits the decision and its audit row together.
- Compute backlog size at peak decision rate over thirty minutes, and define the full-outbox behaviour.
- List the fields of the access audit record and justify each against a specific question an incident review asks.
- Trace a break-glass read end to end, marking where it diverges from the normal path.
Follow-up
- The audit backlog reaches its disk limit at minute forty of the outage. What does the system do, and what do you tell the compliance owner?
- One person's revocation must take effect immediately rather than within the stated bound. What do you add without lowering the global entry lifetime?
Evening eligibility denials cluster in western time zones
Eligibility denials rose from 0.4% to 3.1% of responses. They cluster after 17:00 local time, only at facilities in UTC-5 through UTC-10, and spike on the first and last day of each month. coverage_span.effective_date and termination_date are date columns in business time; the service derives the service date from encounter.admit_ts, a timestamptz. The enrolment files for the affected members look correct on inspection. Give the ordered diagnosis and the fix.
Approach
- Pivot the denial rate two ways before reading code: by facility UTC offset and by local hour of day. A defect that tracks local hour and offset is a time-conversion bug; one that tracks a source file, payer or plan is a data bug. The month-boundary spike is a consequence rather than a second problem, because terminations cluster on month ends and a one-day skew is most visible there.
- Take one denied request and recompute it by hand: the raw admit_ts, its UTC calendar date, the facility-local calendar date under the facility's IANA zone, and the coverage row's effective_date and termination_date. If the answer flips between the UTC date and the local date, the conversion is the cause and no further hypotheses are needed.
- Find the cast. In PostgreSQL, timestamptz::date is evaluated in the session's TimeZone setting, so the identical SQL returns different dates on different pooled connections and a pool that inherits UTC yields the UTC calendar date. date columns carry no zone at all, so comparing a date column to a UTC-derived date compares two different calendars.
- Fix once, at the edge: resolve the service date as (admit_ts AT TIME ZONE facility.iana_zone)::date and pass it down as an explicit date parameter. Use the IANA zone name, never a stored numeric offset, because the offset changes twice a year under daylight saving and a stored -8 is wrong for roughly eight months.
- Forbid re-derivation below the edge and pin the boundary with a frozen-clock test: an encounter at 23:30 local at a UTC-10 facility on the last day of a month whose coverage terminates that day, plus the same encounter one minute later. A test that calls now() passes for most of the day and hides the defect.
Follow-up
- Where else does the as-of date enter the system — the eligibility cache key, claim_line.service_from_date, the accumulator's plan year? Which of those are already computed in UTC?
- An inpatient encounter spans midnight local. Which date governs eligibility — the admit date or the service line date — and at which layer is that decided?
For someone who has spent the last few years shipping features and reading other people's code, and who has not solved a timed problem from a blank file in a long time. Five days rebuild the primitives and the patterns that sit on them, working from invariants rather than remembered solutions, and the last two attach that back to the rest of the loop.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Rebuild the primitives by implementing them
- Implement a dynamic array with doubling growth and an operation counter, then change the growth rule to add a fixed sixteen slots instead, and time both for n of ten thousand, a hundred thousand and a million. The fixed-increment version resizes n/16 times at O(n) each, so its total work is quadratic; doubling is what makes append amortised constant.
- Implement a hash map with separate chaining and a load-factor resize, then insert ten thousand keys engineered to land in one bucket and record what happens to lookup time, so that average-case O(1) becomes a claim with a stated precondition rather than a reflex.
- For dynamic-array append and hash-map insert, write down which cost is amortised rather than worst-case, which single operation pays the whole bill, and what a system with a hard per-operation deadline would have to do instead.
Deliverable: Two working implementations plus a timing table showing the input at which each structure's advertised complexity stops holding.
Practice prompt ↗Practice prompt ↗Worked solution ↗02Arrays under an invariant: two pointers, sliding window, binary search
- Solve longest-subarray-with-sum-at-most-K using a sliding window, then run it on an input containing negative numbers and watch it return the wrong answer: extending the window only moves the sum monotonically when every element is non-negative, and that precondition is the whole reason the technique works.
- Write the binary search that finds the first index satisfying a predicate rather than an exact value, put the loop invariant above the loop in a comment, and verify termination on the two inputs that break careless versions: the empty range, and a range where every element satisfies the predicate.
- Compute the midpoint as lo + (hi - lo) / 2 and write one line on why the obvious (lo + hi) / 2 is a genuine defect in a fixed-width integer type and a non-issue in a language with arbitrary-precision integers.
Deliverable: Three solved problems, each with its invariant written above the loop, plus one recorded input on which the sliding window is provably wrong.
Practice prompt ↗Practice prompt ↗03Sorting, heaps, and the greedy argument that has to be proved
- Solve one top-k problem three ways, by full sort, by a size-k heap, and by quickselect, then write the values of n and k at which each becomes the right choice, along with quickselect's quadratic worst case and why a randomised pivot makes that unlikely rather than impossible.
- Implement bottom-up heapify and count sift-down steps to confirm it does linear work rather than n log n, because most nodes sit near the bottom of the tree and therefore move only a short distance.
- Take interval scheduling by earliest finishing time and write the exchange argument out in full: given any optimal schedule, swapping in the earliest-finishing interval keeps it feasible and no smaller. Then construct the weighted variant where that same greedy fails and name what has to replace it.
Deliverable: A three-way top-k comparison with measured crossover points, one written exchange argument, and one counterexample to a greedy rule that looks almost identical.
Practice prompt ↗Practice prompt ↗04Recursion, memoisation, and the step to a table
- Take one problem with overlapping subproblems, such as edit distance or coin change, instrument the plain recursion with a call counter to show the blow-up, then add memoisation and re-count.
- Convert the memoised version to a bottom-up table and state the two properties you relied on: each subproblem's result depends only on its arguments, and the dependencies form a DAG you can enumerate in order.
- Rewrite one deep recursion with an explicit stack, then find the input length at which the original hits the interpreter's frame limit, which defaults to about a thousand frames in CPython, so you know when the rewrite is required rather than decorative.
Deliverable: One problem in three forms, naive, memoised and tabulated, with call counts for each and the input length at which recursion depth becomes the binding constraint.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Graphs, where most of the work is choosing the traversal
- Implement BFS and DFS over one adjacency list, then answer for each which finds a shortest path in an unweighted graph and which you would use to detect a cycle in a directed graph, including why the in-progress versus finished distinction matters for the second.
- Implement topological sort by in-degree, feed it a graph containing a cycle, and confirm the failure signature is that fewer than V nodes come out rather than an exception, then note that the order it produces is one of several valid ones.
- Run a shortest-path search on a graph with a single negative edge weight and show the wrong answer, then write the precondition Dijkstra actually needs, non-negative weights, because it finalises a node's distance the first time that node is popped, and name the algorithm you would switch to and its own limit.
Deliverable: A small graph library with BFS, DFS and topological sort, plus two inputs that produce documented wrong answers under the wrong algorithm choice.
Practice prompt ↗Practice prompt ↗06One day for everything that is not an algorithm
- Sketch one system only to the depth a coding-heavy loop tends to reach: the endpoints, what the service stores, and the single query pattern that decides the schema. Stop at twenty-five minutes.
- Prepare the project answer for an interviewer who codes, which means rehearsing the two levels they push to: the specific thing you built, and why you chose that approach over the alternative they will name. Open with a number and be ready to say what it excludes.
- Prepare the answer to what you would do differently, choosing a real technical mistake with a specific fix rather than a complaint about process or staffing.
Deliverable: One design sketch at endpoint-and-schema depth, plus a project answer rehearsed to two levels of follow-up.
Practice prompt ↗Practice prompt ↗07Solve out loud, under time
- Do three timed problems at twenty-five minutes each in a plain editor with no autocomplete and no execution until the end, then tally separately the failures that were syntax and the ones that were approach, because those two numbers call for different fixes.
- Narrate one solution from the first sentence, stating the approach and its complexity before writing any code, and rehearse the sentence you will use when you realise mid-solution that the approach is wrong.
- Re-solve from blank the two problems you were slowest on this week and compare the times against the day they first appeared.
Deliverable: A recording of one fully narrated solution and a tally that separates syntax failures from approach failures.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Team size, service count and tickets closed say very little. Seniority shows in the decision you owned: what you chose not to build, which constraint you traded away, whose objection you had to resolve before anything could move. A large project where you executed someone else's plan is a small story.
Unblock an engineer whose deductible accumulator overshoots
An engineer on your team has a benefit-application path that occasionally leaves a member's accumulated deductible above the plan limit — a handful of times a day, never in tests. Their code SELECTs the remaining deductible, computes patient responsibility in application code, then UPDATEs the accumulator to an absolute value. They have spent three days adding logging and are now asking whether the database is losing writes. Describe unblocking someone in this position: what you did first, what you let them find themselves, and what you left them able to diagnose next time.
Approach
- The probe is whether you teach a method or hand over a patch. Reproduce before explaining: two sessions, both BEGIN, both SELECT the accumulator row, both compute, both UPDATE to an absolute value, both COMMIT. The second overwrites the first and neither errors. Fifteen minutes of that ends three days of logging and, more importantly, ends the theory that the database is at fault.
- Be precise about where the anomaly is and is not, because the imprecise version teaches the wrong lesson. A single UPDATE that does its arithmetic in SQL is safe under READ COMMITTED: the blocked statement re-reads the row after the first commits. The loss comes from computing the new value in application code across the statement boundary, so the UPDATE writes an absolute amount derived from a stale read.
- Lay out three fixes with their costs rather than naming one. SELECT ... FOR UPDATE serialises writers per member and holds the lock for the transaction, so nothing in that transaction may make an external call. SERIALIZABLE with a retry loop on SQLSTATE 40001 requires the operation to be safely retryable. Per-member partitioning removes contention entirely and adds routing and rebalancing.
- Let them pick and defend one. The outcome you want is that they can name the anomaly and the isolation level unprompted next time, not that this particular ticket closes today.
- Leave an artefact behind: the two-session reproduction checked in, so the next person meets the interleaving rather than the symptom, and the reasoning is not stored only in your head.
Follow-up
- A claim is reversed and the accumulator must be credited back. What amount, given the plan design may have changed since?
- They choose SERIALIZABLE. How do they make the retry safe when the transaction also wrote a claim adjudication row?
- How would you have noticed this before a member saw it, and what would that check cost per adjudication?
Ship an eligibility cache you already know is too stale
You shipped the eligibility service against a fixed go-live with a 24-hour cache keyed on person and plan, no service date in the key and no computed-as-of field in the response, because the real-time payer inquiry path was two sprints behind. Enrolment files routinely terminate coverage retroactively — a file received on the fifth can terminate coverage effective the first. Describe shipping a compromise of this shape: what you wrote down, who accepted the risk, the bound you could honestly state, the measurement that sized the debt in money, and whether it was ever paid.
Approach
- The probe is whether you can state a compromise as a bounded risk rather than as a known limitation. Start by separating two staleness sources, because they have different fixes: cache staleness is bounded by the TTL, while business-time staleness is not bounded by anything in your system, since the source itself asserts changes retroactively.
- Follow that distinction to its uncomfortable conclusion — shortening the TTL to five minutes leaves the second unchanged. A zero-TTL cache still serves an answer that was false when computed, so anyone who proposes TTL tuning as the fix has misread which of the two is biting.
- Write the debt as a sentence with numbers: the service can answer 'covered' for a person whose coverage terminated up to the enrolment cadence plus its retroactive window earlier, with up to 24 hours of cache on top. That sentence is what a reviewer can accept or refuse; a ticket title is not.
- Name the mitigation that costs days rather than sprints: put service_date in the cache key and computed_as_of in the response body so consumers can see an answer's age, and re-check eligibility at claim submission rather than trusting the encounter-time answer.
- Give the measurement that sizes it in money — the weekly count and dollar value of claim_line rows denied for terminated coverage where the answer served at encounter time said active, filtered to the surviving claim version. That number is what buys the sprint later; without it the fix competes against features on opinion.
- Be specific about the acceptance. Name the artefact the decision lives in and the person with budget authority who signed it, because a compromise nobody accountable acknowledged is a decision you made alone and later described as a trade-off.
Follow-up
- The payer inquiry path ships and the cache stays. Which of the two staleness bounds has actually moved?
- A service was delivered against a stale 'covered' answer. Who absorbs the cost, and does your design record enough to answer that?
- Registration wants a 50ms p99 on this call. What do you give up, and how do you say that to them in one sentence?
Reverse a fail-closed eligibility check at patient registration
You designed registration to block when the external eligibility inquiry exceeds its timeout budget, reasoning that an unverified registration becomes a denial weeks later. Months in, the payer's p99 sits near the budget, front desks are queueing, and two teams have built on the guarantee that a completed registration implies verified coverage. You reversed the decision. Walk through it: the evidence that changed your mind, what you deliberately kept fail-closed, how you migrated the teams relying on the old behaviour, and what you would change about how you made the original call.
Approach
- The probe is whether a reversal is backed by measurement or by fatigue. Lead with both costs in their own units: the share of inquiries exceeding the timeout and the wait minutes that produced at the desk, against the write-off dollars attributable specifically to registrations that proceeded unverified during the pilot.
- State what your original reasoning got wrong, concretely. The usual answer is that you priced the denial and not the queue, and that you reasoned about a p50 round trip when a fail-closed default is governed by the dependency's p99 and by its outage minutes, neither of which you had measured before choosing.
- Show the reversal was partial, which is what a good one looks like. Emergency presentations never block, because care is not conditioned on a benefits answer; high-cost elective services keep a hard stop where the write-off is large and the delay is tolerable; everything else proceeds with coverage_status 'unverified' into a work queue that must clear before the claim is submitted.
- Treat the work queue as part of the design rather than as an afterthought: what enters it, what clears it, what happens when it is not cleared before the submission deadline, and who is paged when its depth grows. A fail-open path with no queue is not a degradation strategy, it is a silent one.
- Describe the migration for the teams that depended on the guarantee: a per-encounter_class flag, a period where the new decision is computed and logged while the old behaviour still stands, and the consumers told which field replaces the assumption before the switch, not after.
- Close on the process change rather than the outcome — what you would now require before shipping any fail-closed default: a measured p99 from the dependency, a named owner for the blocked case, and a reversal trigger agreed in advance so the next reversal is a threshold being crossed rather than an argument.
Follow-up
- Your unverified queue is 900 deep on a Monday and the submission deadline is Wednesday. What happens, and who decided that in advance?
- How do you prevent 'unverified' from quietly becoming the normal path once the desks learn it is faster?
- Six months later the payer's p99 halves. Do you reverse back, and what evidence would make you?
- 01
An engineer on your team has a benefit-application path that occasionally leaves a member's accumulated deductible above the plan limit — a handful of times a day, never in tests. Their code SELECTs the remaining deductible, computes patient responsibility in application code, then UPDATEs the accumulator to an absolute value. They have spent three days adding logging and are now asking whether the database is losing writes. Describe unblocking someone in this position: what you did first, what you let them find themselves, and what you left them able to diagnose next time.
- 02
You shipped the eligibility service against a fixed go-live with a 24-hour cache keyed on person and plan, no service date in the key and no computed-as-of field in the response, because the real-time payer inquiry path was two sprints behind. Enrolment files routinely terminate coverage retroactively — a file received on the fifth can terminate coverage effective the first. Describe shipping a compromise of this shape: what you wrote down, who accepted the risk, the bound you could honestly state, the measurement that sized the debt in money, and whether it was ever paid.
- 03
You designed registration to block when the external eligibility inquiry exceeds its timeout budget, reasoning that an unverified registration becomes a denial weeks later. Months in, the payer's p99 sits near the budget, front desks are queueing, and two teams have built on the guarantee that a completed registration implies verified coverage. You reversed the decision. Walk through it: the evidence that changed your mind, what you deliberately kept fail-closed, how you migrated the teams relying on the old behaviour, and what you would change about how you made the original call.
Is this an official DeepTek Medical Imaging interview guide?
No. It is PracHub's own research and practice material for the Software Engineer role at DeepTek Medical Imaging. Rounds and questions reflect what candidates have reported, not a process DeepTek Medical Imaging has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗How difficult are the technical interviews?
The interviews are considered challenging because they focus on both breadth and depth. Expect to be pushed on your understanding of fundamental concepts and your ability to apply them to system design.
PracHub interview research ↗What is the best way to prepare for the system design round?
Focus on common patterns like rate limiting, message queues, and database sharding. Practice sketching out these systems on a whiteboard or digital document to get comfortable explaining your design choices.
PracHub interview research ↗Does the interview process vary by location?
While the core technical expectations remain consistent, the specific focus may shift slightly depending on the team's current project needs. Always review the job description for specific technology stacks mentioned.
PracHub interview research ↗How long does the process take from start to finish?
The process is generally efficient, typically involving a few rounds. Aim to be ready for an interview within 1–2 weeks of your initial application to maintain momentum.
PracHub interview research ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
PracHub page · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
Cross-company practice questions for this role.
PracHub page · Accessed 2026-09-22 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Epic Systems Software Engineer Interview Questions & Guide 2026
Database practice for Epic Systems candidates: how an index changes a query plan, and which anomalies survive a given isolation level, since read committed still permits non-repeatable reads.
Sprinter Health Software Engineer Interview Guide
Caching exercises for Sprinter Health software engineer candidates: deciding what staleness a feature tolerates, choosing between expiry and explicit invalidation, and handling the stampede when a hot key expires.
Qualified Health Software Engineer Interview Guide
Debugging practice for Qualified Health software engineer prep built on a reproduction you trust, narrowing to the smallest failing input, and changing one variable per run so the result stays attributable.
Flatiron Health Software Engineer Interview Guide
Prepare for the software engineer interview at Flatiron Health with original coding, system design and debugging exercises, each paired with a worked solution and the reasoning behind it.