EvenUp builds AI software for personal injury law firms. The source notes for this guide describe its mission as closing the justice gap for injury victims and their lawyers. They name Demand Letters and Medical Chronologies as flagship products. Both help firms process complex medical records and prepare legal demands for people injured in vehicle collisions, accidents and natural disasters. The notes also name core infrastructure called the Client Portal Integrations engine.
According to the notes, Software Engineers work across the stack: full-stack product work, distributed backend services, LLM orchestration and high-volume document processing. The teams mentioned include AI Document Generation, Cases Product Engineering and Client Portal Integrations. The reported stack is Python with Django on the backend, TypeScript and React on the frontend, PostgreSQL for primary storage, and Kubernetes and Elasticsearch for infrastructure and search. The role handles legal and medical records, so the role description also mentions HIPAA, SOC 2 and PII handling.
For preparation, the reported questions fall into four groups. Practical coding covers a Min Stack, string and array manipulation in CoderPad, and moving averages over a stream of document events. Frontend work includes building a Wordle clone in React. System design covers document pipelines, third-party integrations, sensitive data storage and a high-concurrency auction. Behavioral questions cover speed against technical debt, ambiguous requirements, and work with data science or machine learning teams. Prepare every group, not just one round.
Recruiter Call
reportedThe source notes describe this as a first conversation with a recruiter about your background and the role. Use it to settle what changes your preparation. The notes say stage order and panel composition can vary for frontend, backend and platform integrations roles, so ask which one your loop is for and whether the final stage includes a React or other stack-specific build. Keep your background walkthrough simple enough for someone outside engineering to repeat: what each project did, what you changed, and what happened after, with no internal codenames.
What to demonstrate
- Whether someone outside engineering can restate your background walkthrough: the project, your change and the outcome
- Whether you can talk about the role itself, including which specialization you are interviewing for and what the job involves
- Whether you can say why you want this role and this product area in your own words, tied to work you have done
How to prepare
- Rehearse the bank prompts 'Walk through your resume and impacts' and 'Answer common recruiter behavioral questions' out loud, keeping each project to what broke, what you changed and what the result was
- Ask which specialization the loop is for and whether the final stage includes a React build, then weight days 2-6 of the plan to match
- Before the call, note which of your projects used Python and Django, TypeScript and React, or PostgreSQL, since the notes list that as the stack; this is for your own preparation, not something the notes say the recruiter checks
- Prepare a short, specific answer about building software for law firms and injury victims, tied to something you built rather than to a mission statement
Technical Screening
reportedCandidates report a screen with a hiring manager or senior engineer. Candidates report that it usually combines a deep dive into your technical background with either a practical coding problem or a conceptual design question. The notes do not say which one you will get, so prepare both. For a coding problem, get a correct version running, state its complexity, then improve it while explaining your steps. For the background part, expect follow-up questions on the architectural decisions you made on your own projects.
What to demonstrate
- Whether you get a correct solution running and state its time and space complexity accurately
- Whether you check edge cases without being asked: empty input, one element, duplicates, and repeated extreme values
- Whether you can defend the architectural decisions in a project you owned when a senior engineer asks why
How to prepare
- Practise the reported coding category (the notes do not tie these questions to a round): Min Stack, First Unique Character Index and Look and Say String Compression, in a plain editor, explaining each step aloud and writing down edge cases before you run anything
- For a conceptual design question, rehearse a short structure: requirements, core entities and APIs, choice of data store, and the first failure mode you would handle
- Pick one project you owned end to end and prepare the two or three decisions you would defend, including one you would change now
Final Assessment
reportedThe notes say the final stage is often run as one combined virtual onsite. It has live coding that may be algorithmic or stack-specific (building a React application is the example given), a dedicated system design interview, and behavioral rounds with product managers, cross-functional partners and executive leadership. The same project can come up with several of these interviewers, so keep its facts consistent. For a React build, the notes advise getting a solid working state architecture before polishing styles. Prepare the reported design category as well: document pipelines, integrations, sensitive data and concurrency.
What to demonstrate
- Whether your live code works end to end, including a stack-specific build such as a React component with correct state handling
- Whether your system design covers failure, retries and data sensitivity as well as the happy path
- Whether your behavioral answers show that you own trade-offs and communicate clearly with product, data science and leadership
- Whether the figures and decisions you give for a project stay the same across interviewers
How to prepare
- Rehearse a React build from a blank file using the reported Wordle question: state logic first (guesses, current input, per-letter evaluation, win and lose conditions) and rendering second
- Sketch two reported design questions, the document pipeline (ingest, OCR, LLM extraction, deliverable generation) and the auction system, naming the queue, job state, idempotency and the concurrency control for bids
- Write a one-page fact sheet per project (scale, team, timeline, what broke), and prepare questions for leadership about product direction and scaling plans
2 candidate reports. Individual accounts describe a particular role and hiring cycle.
EvenUp Staff Data Scientist Interview Experience — OA With No IDE, Then a BQ-Only HM Round
The first stage was an OA that took about an hour. It had two parts. The first part was maybe a dozen or so multiple choice questions, covering a lot of ground quickly — there were data processing questions, questions about statistical distributions, and some basic hypothesis testing concepts. There was plenty of time, I think it was 25 minutes for under 15 questions? The second part was rough —…
Read full experienceEvenUp New Grad Software Engineer Interview Experience — Blunt Recruiter Feedback, Then a Canditech OA
I applied 8 months ago, and now I've gone from being a new grad to being an old veteran before I finally got an interview. My first round was a phone call, and I answered pretty confused. The recruiter told me straight up that I answered very poorly, but I said I don't really care about WLB, blah blah, and he said that's exactly the signal they're looking for, so he moved me on to the OA. (Which…
Read full experiencePracHub editorial advice for the preparation topics above.
Tracking a single minimum variable in the Min Stack question
One min field works until you pop the current minimum. At that point you need the previous minimum and it is gone, so you either rescan in O(n) or return a wrong answer. Store the minimum with each element as (value, min_so_far), or keep a second stack that you push to whenever a value is <= the current minimum. Use <= rather than <, or popping one copy of a duplicated minimum empties the min stack too early. Test push 2, push 2, pop, getMin before you say you are done.
Styling the Wordle clone before the game state works
The notes give this tip for the React build directly: get a solid, working state architecture first. Model the target word, submitted guesses, current input and game status, build the grid from that state, then add key handling. Handle repeated letters correctly: mark exact matches first, then mark a letter as present only up to the count of that letter still left in the target. Leave colors and animation until everything else works.
Designing the document pipeline as one synchronous request
OCR and LLM extraction on large medical record sets take a long time and can fail partway through. Put a queue between upload and processing and store a job state for each document and stage. Make each stage idempotent so a retry cannot produce a second deliverable, and send repeated failures to a dead-letter queue that someone reviews. The data is patient and case data, so say where access is checked and what goes into the audit log. The reported prompts ask about both.
Reading the high bid and then writing a new one in the auction design
Two bidders who read the same current price will both think they won. Make bid acceptance atomic. One option is a conditional update such as update auction set high_bid = $bid, high_bidder = $user where id = $id and high_bid < $bid, then checking the affected row count. The other is to serialize bids for each auction through one partition or lock. Send push notifications only after the bid commits, and explain how a client that missed a notification recovers by re-reading the auction state.
Treating model output as always correct in the data science collaboration story
Two reported behavioral prompts ask how you turned raw or non-deterministic model output into reliable features. A story where model output went straight to users skips the actual question. Name the checks you put between the model and the user: schema validation of the output, thresholds that sent low-confidence results to human review, a fallback for when the model failed, and how you measured reliability after launch.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Given a stream of document processing events, write a function to calc…
Given a stream of document processing events, write a function to calculate moving averages and identify processing latency spikes.
Approach
- Choose the data structure from the access pattern, not from familiarity.
- Walk one small example through your approach before writing the whole thing.
- Name the brute-force solution and its complexity before improving on it.
Follow-up
- What is the worst case, and how likely is it on real data?
- How does this change if the input no longer fits in memory?
Describe verbally and implement a Min Stack data structure that suppor…
Describe verbally and implement a Min Stack data structure that supports push, pop, top, and retrieving the minimum element in constant time.
Approach
- Restate the input: its shape, its size, and what is guaranteed about it.
- State the target complexity and say which constraint rules the naive version out.
- Walk one small example through your approach before writing the whole thing.
Follow-up
- Which test case would catch an off-by-one here?
- What is the worst case, and how likely is it on real data?
Solve a string and array manipulation challenge in CoderPad while walk…
Solve a string and array manipulation challenge in CoderPad while walking through your optimization steps and boundary checks.
Approach
- Name the brute-force solution and its complexity before improving on it.
- Walk one small example through your approach before writing the whole thing.
- Choose the data structure from the access pattern, not from familiarity.
Follow-up
- How does this change if the input no longer fits in memory?
- Which test case would catch an off-by-one here?
Locate a billing reconciliation gap without rescanning ninety million events
A tenant's sealed invoice total is 0.4% below the sum of its raw usage_event rows for the period. That tenant has 90 million events over 30 days in a table partitioned daily on ingested_at, and its rollups carry source_max_ingested_at, revision and sealed_at. Recomputing all 30 days from raw is correct, and you are not going to do it. Give the procedure that locates the divergent (workspace, sku, hour) cell, the cost of each probe, and the one query you run before any of it.
Approach
- Run the free query first. Sum raw quantity for the period restricted to
ingested_at <= source_max_ingested_atof the sealed rollups, and compare that against the unrestricted sum. The rollup stores the watermark precisely so this can be answered without a scan. If the whole 0.4% sits above the watermark, nothing is broken: it is late data, it becomes an adjustment line, and the investigation ends in one query. - Only if the gap survives that test do you bisect, and you bisect by dimension rather than by rows. Compare 30 per-day totals, then inside the offending day compare the 6 SKUs, then the workspaces, then the 24 hours. That is roughly 30 + 6 + W + 24 grouped probes, each an indexed range scan over one daily partition for one tenant, against O(N) per attempt for the naive re-fold.
- Quantify why naive is not merely slow but unusable mid-incident: at a generous 200,000 rows/second sequential, 90 million rows is about 7.5 minutes per attempt, you will want ten attempts, and every one competes for I/O on the same partitions live ingest is writing. The diagnostic worsens the backlog it is diagnosing.
- Before fetching each comparison, state what it would look like under each hypothesis. Two adjacent hours off by equal and opposite amounts is
occurred_atversusingested_atbucketing. A whole day offset by exactly N hours is a timezone applied at the wrong layer. A gap confined to one SKU in one workspace is an environment filter. The same(tenant_id, idempotency_key)present in twoingested_daypartitions is the dedup horizon losing a retry that crossed midnight. - Make the next bisection cheap by storing the aggregate you keep recomputing. A per-
(tenant_id, ingested_day)count and quantity checksum turns step two from thirty probes into one read, and it is the same number the reconciliation job already produces. - Whatever you find, the sealed period does not change value. The correction is an adjustment line pointing at the line it reverses, carrying its own
source_rollup_watermark, because the original invoice is the evidence of what the customer was charged.
Worked solution 35 min
- Reproduce the shape locally: generate 2 million events for one synthetic tenant over 5 days, fold them, then inject three defects, namely 0.2% of events bucketed by
ingested_at, a handful of duplicateidempotency_keyvalues whose retries cross midnight, and a block of events ingested after the seal. - Write the watermark-bounded query first and record how much of the gap it explains on its own.
- Bisect by day, then SKU, then hour, recording the probe count and the rows each probe touches.
- For each located cell, write down the predicted signature before querying it, then check whether the data matches the prediction.
- Time a full re-fold of the 2 million rows and extrapolate to 90 million.
Follow-up
- The gap is 0.4% in one direction on one day and 0.4% the other way the next day. What does that shape rule in, and what does it rule out?
- How do you distinguish a duplicate from a restatement, given
revisionandrecomputed_aton the rollup? - Ingest is still running while you investigate. What makes your two numbers comparable at all?
Paginate a tenant's delivery export without skipping rows
A customer exports webhook_delivery: delivery_id (bigint identity), subscription_id, tenant_id, event_id, status, attempt_count, next_attempt_at, created_at, delivered_at, updated_at. The endpoint runs select ... where tenant_id = $1 order by created_at desc limit 100 offset $2, and customers report rows missing from exports taken while new deliveries are being inserted. Write the replacement query and the index that supports it, paging a tenant's deliveries newest first at constant cost per page. State why updated_at cannot be the cursor column.
Approach
- Name the defect precisely. OFFSET is a position in a result set that is recomputed on every request, so a row inserted ahead of the window shifts everything back by one and the next page starts after a row the client never received. Nothing errors and no identifier gap appears, so the loss is silent.
- Replace the position with a value predicate over a stable, unique, indexed ordering:
where tenant_id = $1 and (created_at, delivery_id) < ($2, $3) order by created_at desc, delivery_id desc limit 100. The row comparison is load-bearing: created_at alone is not unique, so ties straddling a page boundary are dropped or repeated, which is the same bug in a smaller window. - Index
(tenant_id, created_at, delivery_id). PostgreSQL scans a btree in either direction, so an all-DESC ORDER BY is served by an ASC index read backwards and no DESC modifiers are needed; they only matter when the ORDER BY mixes directions. Confirm the plan has no Sort node above the index scan, or the LIMIT stops being an early exit. - Price both forms: keyset is one index descent plus 100 adjacent leaf entries per page, constant regardless of depth, while OFFSET still produces and discards every skipped row, so page N costs time proportional to N times the page size and a deep page on a large table goes from milliseconds to seconds.
- Rule out updated_at as the cursor from the precondition, not from taste: a cursor column must never change value for a row already paged past. updated_at moves on every delivery attempt, so a row the client already emitted re-enters a later page and is exported twice. created_at and delivery_id are immutable, which is the whole qualification.
Worked solution 20 min
- Load about 50k deliveries for one tenant, then walk them with the OFFSET query while a writer inserts 10 rows/second, collecting every returned delivery_id.
- Compare the distinct ids collected against the set of ids that existed when the walk started, and record the shortfall.
- Repeat the walk with the keyset query and confirm every pre-existing id is returned exactly once.
- Run
explain (analyze, buffers)on page 1 and page 500 of each form and compare shared buffer hits.
Follow-up
- The client wants a snapshot as of one instant rather than a live tail. Compare a repeatable-read transaction held open, an added
created_at <= $snapshotbound, and a materialised export table. - A retention job deletes deliveries older than 90 days. What does a client mid-walk see, and does keyset pagination help at all?
- The customer wants to resume an export from yesterday's last cursor. What must be true of the cursor for that to be safe?
Explain why the metering dashboard scans every daily partition
usage_event is range-partitioned daily on ingested_at and holds tenant_id, workspace_id, environment, sku, quantity numeric(20,6), occurred_at and ingested_at. The only relevant index is on (occurred_at). A dashboard runs select sku, sum(quantity) from usage_event where tenant_id = $1 and date_trunc('hour', occurred_at) >= $2 and environment = 'production' group by sku, and EXPLAIN shows a sequential scan of every partition. Give each distinct reason, rewrite the predicate so an index can serve it, propose the index, and state the write cost its column order adds.
Approach
- Separate the three causes rather than blaming one. First,
date_trunc('hour', occurred_at)wraps the column, so the predicate is not sargable against a btree on the bare column. Second, pruning keys off ingested_at while the query constrains occurred_at, so no partition can be excluded. Third, even made sargable, (occurred_at) is not tenant-leading, so for one tenant among thousands the scan reads the whole time range and discards nearly all of it. - Rewrite the bound carefully, because the obvious rewrite is only conditionally equivalent.
date_trunc('hour', x) >= $2equalsx >= $2only when $2 is already hour-aligned; for an arbitrary $2 it meansx >= date_trunc('hour', $2) + interval '1 hour'. Normalise the parameter in the caller and leave the column bare. - Restore pruning with a second, redundant predicate on the partition key:
ingested_at >= $2 - interval '<late-data horizon>'. State both sides of it. It prunes to a handful of partitions, and it silently omits any event whose ingest lagged past that horizon, which is precisely what a producer replay produces. Either document the horizon as a stated bound, or partition on occurred_at and move the problem into the dedup window instead. - Propose
(tenant_id, occurred_at) include (sku, quantity)per partition. A partial indexwhere environment = 'production'mostly saves size rather than selectivity, since production dominates the three environments; take it if non-production is a meaningful share and skip it otherwise. - Price the write path honestly. At roughly 250M rows/day each extra index is another insert plus WAL per row, and a tenant-leading key scatters inserts across one hot leaf per active tenant instead of appending to a single rightmost leaf, so page dirtying and random I/O both rise. An INCLUDE payload widens every leaf entry and enlarges the index accordingly.
- Add the index-only-scan caveat before someone reports it as a regression: on a freshly appended table the visibility map is not yet set for recent pages, so the INCLUDE columns still cost heap fetches until autovacuum has been through, and the newest hour is exactly the data the dashboard reads.
Follow-up
- CREATE INDEX CONCURRENTLY is not supported on a partitioned parent. Give the sequence that gets this index onto 400 existing partitions without blocking ingest.
- One tenant holds 200 times the median row count and the dashboard still times out for them with the index in place. What changes?
- Should this read hit
usage_rollup_hourlyinstead? State what that costs in freshness and what the watermark lets you promise.
Design an end-to-end asynchronous processing pipeline for ingesting la…
Design an end-to-end asynchronous processing pipeline for ingesting large medical legal documents, running OCR/LLM extraction, and generating final deliverables.
Approach
- Name the failure you are designing for, then the recovery path.
- Name the read and write paths separately; they rarely have the same bottleneck.
- State the consistency you need, and where you are willing to be stale.
Follow-up
- What breaks first when traffic grows ten times?
- What would you drop to keep the system up under load?
Architect an online auction system capable of handling high-concurrenc…
Architect an online auction system capable of handling high-concurrency real-time bidding, atomic state updates, and push notifications.
Approach
- State the consistency you need, and where you are willing to be stale.
- Choose a partition key and say what query it makes expensive.
- Name the read and write paths separately; they rarely have the same bottleneck.
Follow-up
- What breaks first when traffic grows ten times?
- What would you drop to keep the system up under load?
Structure a third-party integration hub that connects EvenUp with dive…
Structure a third-party integration hub that connects EvenUp with diverse legal practice management software via REST APIs and webhooks.
Approach
- State the consistency you need, and where you are willing to be stale.
- Name the failure you are designing for, then the recovery path.
- Fix the scope first: who calls this, how often, and what they do when it fails.
Follow-up
- What would you drop to keep the system up under load?
- What breaks first when traffic grows ten times?
Implement a functional Wordle game clone in React, managing grid rende…
Implement a functional Wordle game clone in React, managing grid rendering, key handling, and game state logic in a live coding session.
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?
Ship three breaking-looking changes without breaking pinned SDKs
GET /v1/runs/{id} returns status from the set queued, leased, running, succeeded, failed, timed_out, cancelled. You must add the terminal state lost, add an optional billable_seconds field, and start rejecting name values over 64 characters that were previously accepted. Clients are generated SDKs pinned inside customer build pipelines you cannot redeploy or reliably contact, some with strict deserialisers. Classify each change as compatible or breaking and justify it mechanically, then give the rollout: the versioning scheme, the transform old clients receive, the telemetry, and the sunset process.
Approach
- Classify against a deserialiser rather than against intuition. A new enum value breaks a generated client that validates the enum or switches exhaustively; a new optional field breaks one generated with additionalProperties false; tightening validation breaks every caller already sending an 80-character name even though no field moved. All three are breaking for some real client, and that is the answer, not a technicality.
- Choose the versioning axis on maintenance cost. A path version forks the handler, and each subsequent change multiplies the fork. A date-pinned version header, defaulted per credential at first use and pinned thereafter, keeps one internal model and a chain of ordered response transforms, so the handler stays single and the transforms compose.
- Write the downgrade honestly. Older versions have no lost, so the transform maps it to the least-wrong existing value and the changelog says which; mapping it to failed asserts an outcome nobody observed, so pair it with a reason field the old version already exposes rather than inventing a field, and keep the mapping in one documented table instead of a conditional inside the serialiser.
- Sequence the validation tightening separately from the payload changes: first measure how many tenants send names over 64 characters, then warn for a stated window with a Deprecation header and a non-fatal warning code, then reject only for versions dated after the change, never retroactively for a pinned client.
- Deprecate from evidence, not from announcement: per-version, per-tenant, per-credential request counts from the gateway, a Sunset header carrying the date, direct contact for the handful of accounts that make up most of the tail, and short scheduled brownouts before the cutoff so the clients nobody can reach fail on your calendar rather than during their release.
Worked solution 40 min
- Write the three-row classification table with the client-side mechanism that breaks in each case, not just a verdict.
- Pick the versioning scheme and write the header, the default-and-pin rule for a new credential, and where the transform chain sits relative to the handler.
- Write the lost mapping for pre-change versions as an explicit table entry plus the changelog sentence a customer reads.
- Write the validation timeline with four dated steps, and mark which one is visible to clients that never change their version.
- Write the deprecation plan: the telemetry query by version and tenant, the headers, the brownout schedule, and the fallback for the largest holdout.
Follow-up
- Which step of your rollout cannot be rolled back cleanly once a client has depended on it?
- A tenant pinned to a sunset version breaks their build the morning after the cutoff. What in your plan already lets you resolve it within an hour?
- Your transform chain is now six versions deep. What stops it becoming the fork you were avoiding?
Gateway p99 spikes on a five-minute cadence
edge-gateway caches each credential-to-authorisation-context decision for five minutes. p99 sits at 6 ms except for a spike to 900 ms roughly every five minutes, worst in the region with the most pods, and control-plane CPU and read latency rise in step with it. The error rate stays near zero. Customers are told a revoked credential stops authorising within 60 seconds. Give the ordered checklist that identifies the mechanism, and a fix that removes the spike without weakening the 60-second bound.
Approach
- Test periodicity before anything else: take the spike timestamps modulo the TTL in seconds. A tight cluster at a fixed offset means expiry phase, while traffic-driven spikes scatter.
- Overlay pod start times. Entries filled at first request inherit the phase of the pod that filled them, so a cohort of pods deployed together expires together and the amplitude should track cohort size rather than tenant count.
- Separate a herd from a capacity shortfall by measuring control-plane requests per second during a spike against baseline. A stampede shows a step of roughly (pods x hot keys) for one interval with hit rate collapsing to near zero, not a gradual climb that would indicate the dependency is simply undersized.
- Apply three independent controls: randomise each key's TTL by a factor drawn uniformly from something like 0.8 to 1.0 so cohorts de-phase; coalesce concurrent misses per key per pod so exactly one refresh is in flight; and serve the stale value while that refresh runs so a miss costs the stale read rather than the dependency's queue.
- Bound staleness against the published contract rather than against comfort: serve-stale is admissible only up to the 60-second revocation bound, so the TTL floor and the stale window together must stay inside it, and the published invalidation must delete the entry rather than schedule a refresh.
- Decide in advance what a miss does when the control plane is unreachable, because that is now the only uncached path: failing closed converts a dependency outage into a total outage, while extending stale service past the bound breaks the revocation promise. Pick one and configure it explicitly.
Follow-up
- Publish-subscribe invalidation is lossy under a partition. Given that, what actually enforces the 60-second bound, and what number would you put in the contract if asked to defend it?
- One tenant's key is hot enough that a single pod's coalesced refresh still matters. What changes?
- Would a shared cache tier in front of the control plane help or shift the problem, and what new failure does it add?
For someone fluent in a dynamic language who has shipped real work but has never had to say what the runtime is doing underneath. The week is built on measuring and deliberately breaking things, because the questions that expose this background are the ones where the interviewer asks why a second time.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Recruiter call and your background story
- Write two-sentence summaries of your three strongest projects with no internal names: what was breaking, what you changed, what happened after.
- Rehearse 'Walk through your resume and impacts' and 'Answer common recruiter behavioral questions' out loud, and cut anything someone outside engineering could not repeat back.
- List questions for the recruiter: which specialization the loop is for (frontend, backend, platform integrations), whether the final stage includes a React build, and which languages you can use for live coding.
Deliverable: A one-page background sheet with a summary for each project, and a list of questions for the recruiter.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Data-structure coding
- Implement Min Stack two ways, with a parallel stack of running minimums and with (value, current_min) pairs, and test pushing a duplicate minimum followed by a pop.
- Solve First Unique Character Index with a frequency count in linear time, then Look and Say String Compression, stating the complexity before you run either.
- Implement the bank question 'In-Memory Cache With Expiration' and decide whether expired entries are removed lazily on read, by a periodic sweep, or both.
Deliverable: Three working solutions, each with edge-case tests written before the code first ran.
Practice prompt ↗Practice prompt ↗03Streams and document text
- Solve the reported moving-average question. Keep a running sum over a fixed window of events in a deque so each event costs O(1), and write down what counts as a latency spike before you code.
- Practise 'Parse Data From Streams' and 'Extract Metrics From Legal Text', listing malformed-input cases first: missing fields, partial records, unexpected whitespace.
- Solve one string or array problem in a shared editor such as CoderPad while explaining your optimization steps and boundary checks aloud, and note where you went quiet.
Deliverable: A moving-average and spike detector with tests for an empty stream, a window larger than the input, and a single spike.
Practice prompt ↗Practice prompt ↗04React build for the final stage
- Build Wordle in React from scratch. Model the state (target word, guesses, current input, game status) before rendering, then add keyboard handling and the win and lose states.
- Get repeated letters right in guess evaluation: mark exact matches first, then mark a letter as present only up to the count of that letter still left in the target.
- Sketch a reusable form component that renders nested schema definitions, and explain how you would avoid unnecessary re-renders in a long multi-page document view (memoization, list virtualization, stable keys).
Deliverable: A working Wordle clone, plus a note on the state model and how repeated letters are handled.
Practice prompt ↗Practice prompt ↗Worked solution ↗05System design: document processing and sensitive data
- Design the reported asynchronous pipeline for large medical legal documents (upload, queue, OCR, LLM extraction, deliverable generation), with a job state per stage, idempotent retries keyed by document and stage, and a dead-letter path.
- Add the reported access controls and audit logging, then decide yourself whether to scope access per firm and where to encrypt data. Compare your design with the bank's 'Privacy-Preserving API Gateway'.
- Work through this guide's exercise 'Paginate a tenant's delivery export without skipping rows' and use it as the data-access layer for a case list or export in your design.
Deliverable: A pipeline diagram with the failure path, the audit log and the access checks labelled.
Practice prompt ↗Practice prompt ↗06System design: concurrency and integrations
- Design the high-concurrency auction: atomic bid acceptance through a conditional update or per-auction serialization, a bid log, and push notifications sent only after commit.
- Design the reported integration hub for legal practice management software over REST APIs and webhooks: an adapter per integration, webhook signature checks, retries with backoff, and idempotent handling of duplicate deliveries.
- Work through this guide's exercise 'Ship three breaking-looking changes without breaking pinned SDKs' and apply its versioning reasoning to the integration hub's external API.
Deliverable: Two design write-ups, each naming its consistency requirement and its main failure mode.
Practice prompt ↗Practice prompt ↗07Behavioral stories and a full mock of the final stage
- Prepare STAR stories for the reported prompts: speed against technical debt, the hardest project you owned end to end, ambiguous zero-to-one requirements, and working with data science or ML teams.
- In the ML story, state how you handled non-deterministic model output: validation, confidence thresholds or human review, and what the user saw when the model was wrong.
- Run a mock with one coding problem, one design prompt and one behavioral conversation back to back, then compare the project facts you gave in each.
- Write three questions for leadership about product direction and scaling.
Deliverable: Four STAR stories, notes from the mock, and a list of questions for leadership.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
The notes put behavioral rounds with product managers, cross-functional partners and executive leadership in the final stage. The notes say the technical screen usually includes a deep dive into your background as well. The reported prompts return to the same themes: shipping fast against technical debt, ambiguity in zero-to-one work, and turning model output into reliable features. For each theme, prepare one project story that covers your decision, the alternative you rejected and the measured result.
Describe a time when you had to balance shipping a critical feature ra…
Describe a time when you had to balance shipping a critical feature rapidly against incurring technical debt in a high-growth environment.
Approach
- Give the blast radius: what could have broken, and what you measured.
- Name the disagreement and how you resolved it with evidence.
- State the situation in two sentences and spend the rest on the reasoning.
Follow-up
- What did you decide not to do, and why?
- What would you do differently if you ran that again?
Describe a situation where you received ambiguous requirements for a z…
Describe a situation where you received ambiguous requirements for a zero-to-one product feature and how you drove clarity across stakeholders.
Approach
- Name the disagreement and how you resolved it with evidence.
- Give the blast radius: what could have broken, and what you measured.
- State the situation in two sentences and spend the rest on the reasoning.
Follow-up
- What did you decide not to do, and why?
- What would you do differently if you ran that again?
Ship metered billing with a named deduplication horizon
Metered billing must be on in three weeks. usage_event is partitioned daily, so its unique index must include the partition key and deduplicates only within a day: a producer retry that crosses midnight, or a replay run a week later, gets through. A cross-partition dedup store is two weeks you do not have. Describe shipping with debt you named in advance: what you shipped, what you wrote down, the detector you added, the trigger and date for paying it off, and what you would have refused to ship under the same pressure.
Approach
- Show you can separate the two kinds of debt, because that distinction is what the question actually probes. Debt that costs engineering time later is shippable on a deadline. Debt that silently corrupts a number a customer gets charged for is not shippable unless the corruption is detectable, and detectability is the whole negotiation.
- Make the exposure narrow and measured rather than gestural. The hole is duplicates whose occurrences straddle a UTC day boundary, plus any replay older than partition retention. Measure it before arguing about it: how often an idempotency_key recurs at all, and the distribution of the gap between first and last occurrence. If the ninety-ninth percentile of that gap is four minutes, the residual risk is a small band around midnight and you can say so numerically.
- Add the detector before the feature, not after. A nightly job counting keys that appear in more than one partition is one grouped scan over recent partitions, and it converts a silent overcount into a page. State what it costs to run and what it fires on.
- Buy the cheap half of the real fix immediately: extend partition retention so the dedup horizon exceeds the producer's maximum retry window plus the longest replay you intend to support. That reframes retention as a correctness parameter rather than a storage cost, which is the sentence you need on record before someone optimises the bill.
- Make repayment mechanical instead of aspirational: a dated entry with a named owner, plus a threshold that pulls the date forward — first detector hit above N events, or first customer dispute. Debt with a trigger gets paid; debt with only a date does not.
- Answer the second half honestly by naming what you would refuse under identical pressure: the sealing path, because a sealed row is frozen and a wrong number there stops being a bug and becomes an adjustment line, a dispute and an audit question.
Follow-up
- The detector fires on forty duplicate events for one tenant, and two of their invoices have already sealed. What happens next?
- Whom did you tell that the billing numbers had a known hole, and in what words?
- Finance asks you to cut storage by shortening partition retention. What do you say, and to whom?
- 01
Describe a time when you had to balance shipping a critical feature rapidly against incurring technical debt in a high-growth environment.
- 02
How have you collaborated with Data Science or Machine Learning teams to turn raw model outputs into reliable user-facing features?
- 03
Walk me through the most technically challenging project you owned from end to end, highlighting your key architectural decisions and trade-offs.
- 04
Describe a situation where you received ambiguous requirements for a zero-to-one product feature and how you drove clarity across stakeholders.
- 05
Tell me about a time you had to deliver a critical project under tight timelines. How did you decide which technical trade-offs were acceptable?
- 06
How do you approach working with Data Science teams when integrating non-deterministic AI outputs into deterministic software workflows?
Is this an official EvenUp interview guide?
No. It is PracHub's own research and practice material for the Software Engineer role at EvenUp. Rounds and questions reflect what candidates have reported, not a process EvenUp has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗What kinds of technical questions do EvenUp Software Engineer candidates report?
Mostly practical ones. Reported coding questions include a Min Stack with a constant-time minimum, string and array manipulation in CoderPad, extracting metrics from legal document text, and computing moving averages to flag latency spikes in a stream of document processing events. Frontend questions include a Wordle clone in React and a form component driven by nested schemas. Design questions include a document ingestion pipeline with OCR and LLM extraction, an integration hub for legal practice management software, sensitive-data storage with audit logging, and a high-concurrency auction.
PracHub interview research ↗How should I split my preparation?
Spread your time across the four reported categories instead of doing only algorithms: data-structure coding, a React build, system design and behavioral stories. The seven-day plan on this page gives one day to the recruiter conversation, two to coding, one to React, two to system design, and one to behavioral prep with a full mock. If your recruiter confirms your loop has no React build, use that day for more design practice.
PracHub interview research ↗What technology stack does the role use?
The source notes for this guide list Python with Django for backend services and data workflows, TypeScript and React for frontend interfaces, PostgreSQL for primary storage, and Kubernetes and Elasticsearch for infrastructure and search. Practise live coding in whichever of Python or TypeScript you are fastest in, and be ready to talk about PostgreSQL schema and query design in the system design interview.
PracHub interview research ↗Do backend-focused candidates still get the React question?
The notes describe the React and frontend evaluation as applying to roles that involve user interfaces, and they say panel composition varies between frontend, backend and platform integrations roles. Ask your recruiter whether your final stage includes a stack-specific build and which language you can use for algorithmic coding.
PracHub Software Engineer practice ↗What should I focus on in the system design interview?
Focus on failure handling and data sensitivity. The reported prompts involve long-running document processing, third-party integrations, sensitive patient and case data, and concurrent bidding. For each design, name the async boundary, how retries stay idempotent, where access control and audit logging sit, and what consistency the core write needs. The worked exercises on keyset pagination and API versioning on this page cover two data and API details these designs raise.
PracHub Software Engineer practice ↗Sources & methodology 3 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01PracHub interview research ↗
PracHub editorial research into this company and role, maintained with this guide. Candidate-reported, not an employer publication.
platform · Accessed 2026-09-24 - 02PracHub Software Engineer practice ↗
Cross-company practice questions for this role.
platform · Accessed 2026-09-24 - 03PracHub interview preparation framework ↗
The framework the preparation plan follows.
platform · Accessed 2026-09-24
Explore related engineering environments and compare the preparation focus.
Perplexity Software Engineer Interview Guide
Systems practice for Perplexity software engineer candidates, weighted toward B2B software and infrastructure work: the load that actually arrives, the failure modes that matter there, and the invariants a partial outage must not break.
Zscaler Software Engineer Interview Guide
Concurrency exercises for Zscaler candidates: check-then-act races, deadlock from inconsistent lock ordering, and why two individually atomic operations do not compose into an atomic update.
Verkada Software Engineer Interview Guide
Prepare for the software engineer interview at Verkada with original coding, system design and debugging exercises, each paired with a worked solution and the reasoning behind it.
Vanta Software Engineer Interview Guide
Caching exercises for Vanta software engineer candidates: deciding what staleness a feature tolerates, choosing between expiry and explicit invalidation, and handling the stampede when a hot key expires.