Software Engineers at Applied Intuition work on simulation platforms, autonomy software and the infrastructure underneath them, for customers in automotive, defense, mining, trucking and aerospace. Reported product areas for the role include synthetic scenario generation and sensor simulation (LiDAR, radar, camera), Vehicle OS and other onboard software that runs on vehicle hardware, and data pipelines that ingest and index drive log data from vehicle fleets.
The work described for the role covers the whole development lifecycle, from architecture and prototyping through implementation, testing and deployment, with code review and runtime tuning in C++ and Python. Engineers work alongside perception, planning, machine learning and hardware integration specialists, and some teams integrate software with external automotive and defense partners. The language that matters most depends on the team: C++ for low-level systems, Vehicle OS and robotics work, and Python or TypeScript/React on other teams.
That context shows up in the interview questions. The reported coding problems are framed around simulation and vehicle data rather than abstract puzzles: a circular buffer, a nested-transaction key-value store, merging collinear 2D segments, finding the first collision among moving vehicles, parsing a button-press stream or a JSON payload of vehicle velocities. Design questions follow the same pattern, from a single-threaded task scheduler to a telemetry replay system and a Game of Life grid too large for memory. For this loop, practise writing tested implementations of stateful components, not just recognising algorithm patterns.
Initial Screening Call
reportedCandidate reports describe this as a brief recruiter screen covering your background and fit for the role. Use it to ask which product area the role sits in: simulation and toolchains, Vehicle OS and onboard software, or data infrastructure. The answer tells you which language to practise in. Low-level, Vehicle OS and robotics-focused teams lean toward C++, while other teams use Python or TypeScript/React. Also prepare a short answer to why Applied Intuition and why you are leaving your current role now. Candidates report both questions for the Leads Chat, so writing them early keeps your story consistent if either comes up sooner.
What to demonstrate
- Whether your background maps clearly onto one of the areas the role covers: simulation, onboard or embedded software, or data pipelines
- Whether you can summarise your background and recent projects briefly and clearly
- Whether your practical constraints, including the in-office expectation described for the role, fit the position
How to prepare
- Write a short background summary that names, for each recent project, what the system did, what you changed and what happened after, with no internal codenames
- Ask which team or product area the role sits in and which language the technical rounds expect, then practise in that language from the start
- Write short 'why Applied Intuition' and 'why leave now' answers now, so you can expand them in the Leads Chat without contradicting yourself
- Confirm location and in-office expectations with the recruiter so they do not surface as a problem late in the process
Technical Assessment
reportedCandidates describe the technical assessment as a live coding screen over video in a shared editor such as CoderPad. Candidates report that interviewers run your code against their own test cases, so a solution that reads well but fails on an empty input or at a boundary is not finished. Reports do not say which questions come up in this screen. The reported coding questions for the role as a whole are practical implementations rather than abstract puzzles, so practise that category: stateful data structures, stream processing and parsing. State the baseline in a sentence, move to the approach you will code once the interviewer agrees, and leave room to trace your own tests.
What to demonstrate
- Whether the code runs and gives correct output on test cases you were not shown, including empty, single-element and boundary inputs
- Whether you pick the data structure from the operations required, for example a fixed array with head and size indices for O(1) push and pop
- Whether you ask about the deliberate gaps in the prompt, such as duplicate keys, ties or what counts as overlap, before writing code
- Whether the complexity you state matches the code you wrote
How to prepare
- Implement two of the reported coding questions, the circular buffer and the nested-transaction store, from a blank file in your interview language, then test overwrite at capacity, pop on empty, delete inside a transaction and rollback with no open transaction
- Practise one stream-processing problem end to end, such as the reported button-press classifier, and decide up front whether a long press is emitted on release or as soon as the threshold is crossed
- After every practice solution, write three test inputs before running anything and trace them through your code line by line
Onsite Interview
reportedReports describe the onsite, held virtually or in person, as a brief group meet-and-greet, then three to four technical rounds covering algorithmic coding, systems design and practical software engineering, then a final Leads Chat with senior engineering leaders or managers. Reports do not tie specific questions to specific onsite rounds, so prepare across the reported coding and design categories rather than betting on particular problems. For design, go past boxes into data schema, API, indexing, storage and memory limits. The Leads Chat is a chronological walkthrough of your academic and career decisions, so the reasoning behind each move matters as much as the move itself.
What to demonstrate
- Whether coding answers are complete and tested, not only correct in outline
- Whether design answers get specific about data schema, API, indexing, storage and memory limits instead of stopping at boxes
- Whether you can explain the motivation behind each academic and career decision, and why Applied Intuition, as one consistent story
- Whether you keep your focus and code quality across back-to-back rounds
How to prepare
- Work the reported geometry and grid questions with exact representations: for integer coordinates, reduce the segment direction with a gcd instead of using a floating slope, and run one BFS per target so unreachable cells are excluded
- For each reported design question, write the data layout and the memory arithmetic first. A 1M x 1M grid is 10^12 cells, about 125 GB even at one bit per cell, so the answer has to stream tiles from disk
- Prepare the Leads Chat as a timeline from your choice of university and major through each job change, with one sentence of motivation per step
- Rehearse at least once with a coding round, a design round and a behavioural conversation back to back
11 candidate reports. Individual accounts describe a particular role and hiring cycle.
Applied Intuition Software Engineer Interview Experience — An Unclear Car-Location API and Binary-Search Hints
This might have been a new question, though I'd only read about ten interview reports. I'd definitely never seen this one. I don't know the result yet, but I didn't finish, so I'm sure this is a rejection report. The main issue was some domain knowledge. I couldn't quickly step back from it, and wasted a lot of time. The interview guidance was also a bit off. I said, "Couldn't this use recursion?…
Read full experienceApplied Intuition Software Engineer Interview Experience: group discussion, system design, and AI coding
After a recruiter call, I had a 45-minute online coding interview. It was a direct technical checkpoint, and after I cleared it, I was invited to the Sunnyvale office for an onsite loop. The onsite included a group discussion, a system-design conversation, an AI coding segment, and a final discussion. It felt structured and professional. They seemed to be looking at how I reasoned, how I communic…
Read full experienceApplied Intuition Software Engineer Interview Experience — Aggressive Interruptions on a Coding Phone Screen
HR call: Two different HR people reached out to me. It was basically background chat. The first HR felt like they came out of a frat, very flippant, and asked me this kind of dumb question about why I'd choose to accept a return offer and go back to a certain company as a full-time employee. The second one asked what I wanted out of my next job, and then asked to schedule the interview right ther…
Read full experienceApplied Intuition Software Engineer Interview Experience — Five Onsite Rounds, No Offer
View report detailsApplied Intuition Software Engineer Interview Experience — A Four-Round Onsite With AI-Assisted Coding
View report detailsPracHub editorial advice for the preparation topics above.
Calling a coding answer done before tracing it on your own test cases
Candidates report that interviewers run your code against their own test cases, so any failing input they find costs more than one you find yourself. For the reported problems, the breaking cases are predictable: pop on an empty circular buffer and the push that wraps around and overwrites at capacity; a get after a delete inside a nested transaction, which needs a tombstone rather than a missing key; rollback or commit with no open transaction. Write these inputs before you run anything, and trace them aloud.
Grouping collinear segments by floating-point slope
The reported segment-merge question groups segments by matching slope. A float slope breaks on vertical segments (division by zero) and on rounding. For integer coordinates, represent each line by its direction (dx, dy) reduced by the gcd with a fixed sign, plus the integer offset dyx - dxy, so segments on the same line share an exact key. Then project the endpoints onto the direction, sort by start and merge. Before you code the comparison, ask whether segments that only touch at an endpoint count as overlapping.
Spending the round defending a brute force instead of coding the real solution
State the baseline briefly, move to the better design, and start coding once the interviewer confirms it. Give the brute force and its cost in a sentence or two, and name the operation that makes it too slow, such as rescanning every simulation on each event in a timeout detector. Replace it with a structure that removes that cost, such as a min-heap keyed on deadline plus a map from simulation id to its latest timestamp, with stale heap entries skipped when popped. Then write the code.
Answering a design question with boxes but no memory or storage arithmetic
The reported design prompts each turn on a hard limit: a Game of Life grid larger than memory, telemetry replay at volume, a scheduler on one thread. Start with arithmetic and layout. For the grid, 10^12 cells do not fit in RAM, so process row bands from disk, keep the neighbouring rows each band needs, and write the next generation to a separate file, because every cell must read the previous generation. For the scheduler, use a min-heap on next run time and one loop that sleeps until the earliest deadline or a newly scheduled earlier task. For replay, name the schema, the index on vehicle and time, and the storage tier.
Treating the Leads Chat as a standard STAR behavioural round
Reports describe the Leads Chat as a chronological review of your choices from college onward, not a set of situational stories. If you arrive with polished STAR answers but no account of why you chose a university, a major, an internship or a job, you will end up improvising the reasoning. Build the timeline in advance with one line of motivation per step. Include why you are leaving now and why Applied Intuition over the alternatives you considered. Make sure the way you describe a project matches how you described it in the technical rounds.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Implement a fixed-capacity generic CircularBuffer<T, N> supporting O(1…
Implement a fixed-capacity generic CircularBuffer<T, N> supporting O(1) push and pop operations that automatically overwrites the oldest element upon reaching capacity.
Approach
- 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.
- Restate the input: its shape, its size, and what is guaranteed about 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?
Given a series of 2D line segment endpoints, merge overlapping segment…
Given a series of 2D line segment endpoints, merge overlapping segments by grouping lines with matching slopes and sorting origin points.
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.
- State the target complexity and say which constraint rules the naive version out.
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?
Implement a key-value store supporting nested transactions using a sta…
Implement a key-value store supporting nested transactions using a stack-based architecture.
Approach
- Walk one small example through your approach before writing the whole thing.
- Choose the data structure from the access pattern, not from familiarity.
- State the target complexity and say which constraint rules the naive version out.
Follow-up
- How does this change if the input no longer fits in memory?
- What is the worst case, and how likely is it on real data?
Given a grid with obstacles and target team locations, determine the o…
Given a grid with obstacles and target team locations, determine the optimal base camp cell to minimize overall path distance using Breadth-First Search (BFS).
Approach
- Name the brute-force solution and its complexity before improving on it.
- Choose the data structure from the access pattern, not from familiarity.
- State the target complexity and say which constraint rules the naive version out.
Follow-up
- How does this change if the input no longer fits in memory?
- What is the worst case, and how likely is it on real data?
Diff a projection against the primary without per-row point reads
The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.
Approach
- Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
- Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
- For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
- Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.
- Pin the comparison to a point in time or it reports lag as drift: consider only rows whose updated_at is older than now minus a lag margin, and re-check each candidate mismatch individually before repairing. At 1,200 writes per second a diff without this reports thousands of false positives, and an unattended repairer would then overwrite live rows with stale values.
- Make the run resumable and throttled: batch by range key, persist the last completed range, and watch a signal such as replica lag or primary CPU, pausing rather than pressing on. A reconciliation that cannot be stopped and resumed gets killed halfway and restarted from zero, which is how a repair becomes an incident.
Worked solution 35 min
- Compute the naive cost explicitly at 40,000,000 reads and 0.5 ms each, then at 100 concurrent, and state what those connections do to a pool already carrying 1,200 writes per second.
- Write the merge-join version over (tenant_id, resource_id) and state its memory.
- Define the range aggregate: the range key, the per-row hash input, and the combining function, with one sentence excluding XOR.
- Work an example with 40,000,000 rows, branching factor 256 and 5 differing rows, and count the ranges examined.
- Add the watermark filter and the resume point, and name the throttle signal the loop watches.
Follow-up
- The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
- Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?
- How would you run this continuously at low cost instead of only as incident response?
Find version gaps and relay lag with window functions
outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.
Approach
- Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
- Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
- Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
- Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.
- Interpret rather than report: no gaps plus a normal p95 of published_at - created_at points at the consumer; gaps or a fat lag tail point at the relay; rows still 'pending' with attempts > 0 point at neither, because they never left the database.
- Be explicit that the partial index on (created_at, event_id) WHERE status = 'pending' does not serve any of these — they read published rows. Name the index a recurring monitor would need, and say why a query run twice a year may not deserve one.
Follow-up
- Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
- Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?
- The consumer claims it never received event 4,812,006. What do you look at, in what order?
Hold a per-tenant active cap against concurrent creates
A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.
Approach
- Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
- Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
- Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
- State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.
- For the job case the invariant is expressible per row, so let the database hold it: a partial unique index on job_run (tenant_id, job_type) WHERE status IN ('queued','running') makes a second running export unwritable and the loser takes 23505, mapped to 409. That is strictly better than a counter — no drift, no reconciliation — and it is available only because the cap is one rather than fifty.
- Add the retry discipline each route demands: under SERIALIZABLE both 40001 and deadlock 40P01 are retryable and the retry must re-execute the read, while under READ COMMITTED with the counter nothing retries, because the conflict is reported to the caller rather than raised as an error.
Worked solution 35 min
- Reproduce with two sessions that both count 49, both insert and both commit, at READ COMMITTED and then at REPEATABLE READ; record the final active count for each.
- Repeat both sessions at SERIALIZABLE and record which SQLSTATE the loser receives and at which statement it is raised.
- Implement the counter form and run a 20-way concurrent create against a tenant sitting at 45 active resources.
- Implement the partial unique index for the job case and race 20 enqueues of the same export.
Follow-up
- A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
- The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?
- How do you detect after the fact that the counter drifted, without locking the table?
Design a scalable file-backed system capable of evaluating a Game of L…
Design a scalable file-backed system capable of evaluating a Game of Life grid spanning a 1M x 1M matrix where state data exceeds system memory limits.
Approach
- 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.
- 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?
Design a single-threaded CPU task scheduler supporting scheduleOnce, s…
Design a single-threaded CPU task scheduler supporting scheduleOnce, schedulePeriodic, and scheduleWithDelay function calls.
Approach
- State the consistency you need, and where you are willing to be stale.
- Fix the scope first: who calls this, how often, and what they do when it fails.
- Name the failure you are designing for, then the recovery path.
Follow-up
- What would you drop to keep the system up under load?
- What breaks first when traffic grows ten times?
Given a JSON payload retrieved from an HTTP API endpoint, parse the ne…
Given a JSON payload retrieved from an HTTP API endpoint, parse the nested structure to find the maximum vehicle velocity and compute peak velocity ranges.
Approach
- Clarify what is being asked and what a complete answer contains.
- State your assumptions explicitly before working the problem.
- 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?
Design the async export contract a client can resume safely
A tenant asks for a CSV of every resource. The work runs for minutes on the worker fleet through a job_run row carrying a lease, an attempt count and a dedupe_key, far past the edge's 400 ms budget. Callers are a browser that polls and a script that walks away and checks later. Specify what the submit call returns, the operation resource and its states, how a duplicate submit is handled, how a client learns about completion, what cancellation means given that a lease can expire mid-run, and how the result is fetched and when it expires.
Approach
- Split the API in two. Submit returns 202 with an operation id and a location to poll, and never blocks on the work. The operation is a real resource with its own lifecycle - queued, running, succeeded, failed, cancelled - plus attempt, a monotonic progress figure, and a terminal error drawn from the same code taxonomy the synchronous endpoints use, so a client needs one error vocabulary rather than two.
- Deduplicate at submit using job_run.dedupe_key, unique over (job_type, dedupe_key) while status is 'queued' or 'running': a repeat submit of the same logical export returns 200 with the existing operation instead of 202 with a new one, and the partial index deliberately permits a legitimate re-run once the first has finished. Pair it with the request's idempotency key so an HTTP-level retry of the submit is exact rather than merely similar.
- Tell the poller how to poll: Retry-After on the polling response, a minimum interval enforced at the edge, and a documented maximum lifetime after which an operation is reaped. Polling is the contract of record; the webhook is the fast path, and both must lead to the same terminal state, so a client that receives the completion event and then polls anyway sees no contradiction.
- Be exact about cancellation. A cancel request records intent; it cannot stop work already executing. The handler reads the flag at checkpoints, and because a lease expires on a clock that cannot distinguish a dead worker from a slow one, a second copy may start after the cancel was recorded - so the handler re-reads the flag immediately after claiming the lease. 'cancelled' becomes terminal only when no lease is outstanding; reporting it earlier shows a client a stopped job while a worker is still writing output.
- Make the handler safe to run twice, because the lease guarantees that it will be. Write output to a deterministic object key derived from the operation id so a second copy overwrites its own work instead of appending a second file, and record completion with a conditional update that only the copy holding the current lease can win.
- Treat result fetch as a separate authorised read: a short-lived signed URL, the tenant checked when it is issued rather than only when the file was produced, and a documented retention after which the operation remains terminal but the bytes are gone - a state the client must be able to tell apart from a failure.
Worked solution 40 min
- Write the submit request and its two possible responses, 202 for new and 200 for a duplicate, and the dedupe_key construction.
- Draw the operation state machine, marking which transitions a client may observe and which are terminal.
- Write the cancellation sequence across a lease expiry, showing where the second copy reads the flag.
- Define the output key, the completion update's predicate, and why both are needed for a double run.
- Specify result fetch: URL lifetime, authorisation point, retention, and the distinct response once the bytes are gone.
Follow-up
- An operation has said 'running' for 40 minutes and the worker is gone. What does the client see, and which columns in job_run decide that?
- Two tenants each submit 50 exports at once. What in this contract stops one of them delaying the other?
- The customer wants the export emailed instead. What changes, and what becomes harder to make exactly-once?
Edge instances grow 400 MB per hour until the nightly restart
Edge API instances start at 700 MB resident and grow about 400 MB/hour; a nightly rolling restart has hidden it for weeks. Growth continues unchanged when request rate halves overnight, p99 degrades in the last hours before an instance is recycled, and heap used immediately after a forced full GC rises monotonically. The service holds no product state. Name the discriminating measurement that separates the plausible causes, give the most likely cause, and give the fix and how you would verify it.
Approach
- Separate resident memory from live heap first, because they fail differently. Resident size can grow from fragmentation, native buffers or thread stacks while the heap is flat; heap used after a full GC rising monotonically is the measurement that says objects are reachable and not being released. You already have it, so this is retention, not fragmentation, and that closes off half the candidate list.
- Use the rate's independence from traffic as the discriminator. Growth that continues at half the request rate rules out per-request objects that are merely slow to collect and points at a structure that grows with distinct values observed rather than with call volume. Write the candidates that have that property: a metrics registry keyed on a high-cardinality label, an unevicted cache, an interner, a per-key lock map.
- Take two heap snapshots an hour apart and diff by retained size, reading the dominator tree, not by allocation count or instance count. Expect one root holding a map with millions of entries, then follow the reference chain to the code that inserts and never removes. Allocation profilers point at churn, which is the wrong signal here.
- The candidate that fits this service is an observability label carrying an identifier, such as a request path recorded before templating so that /v1/resources/48213 becomes its own metric series. That grows with distinct ids seen, is independent of rate, and explains the late p99 degradation, since GC cost rises with the size of the live set.
- Fix by bounding cardinality at the source: template the path to /v1/resources/{id} before it becomes a label, move tenant id from a label to a log field or an exemplar, and cap the registry with a bounded map that evicts. Add a cardinality ceiling that fails loudly in a lower environment rather than growing quietly in production.
- Verify with a soak rather than a restart. Hold one instance out of the nightly recycle for 48 hours with the fix and compare post-GC heap and series count against an unfixed control taking the same traffic.
Follow-up
- Post-GC heap is now flat but resident size still creeps. What are you looking at, and does it matter?
- How would you have detected this before an OOM, given the nightly restart masked the trend?
- That label is what makes one dashboard useful. How do you keep the dashboard and lose the leak?
Roughly ninety minutes on weeknights with one longer weekend block. The plan cuts scope rather than compressing everything, on the assumption that one thing finished per night beats four half-started.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Baseline and the screening call
- Ask the recruiter, or check the listing, which product area and language the role uses: C++ for low-level, Vehicle OS or robotics teams, Python or TypeScript/React elsewhere. Use that language for every problem this week.
- Write the short background summary for the screening call and a first version of your answer to 'why Applied Intuition, why leave now'.
- Solve the fixed-capacity circular buffer cold in a blank editor, then list every input that broke it.
Deliverable: A background summary, a first 'why here, why now' answer, and a cold circular-buffer attempt with its failing inputs listed.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Worked solution ↗02Stateful components
- Implement the nested-transaction key-value store: a stack of change maps, reads that walk the stack from the top down, deletes stored as tombstones, commit merging the top layer into the one below, rollback popping it.
- Rewrite the circular buffer with a fixed array, a head index and a size count so push and pop are O(1) and a push at capacity overwrites the oldest slot.
- For both, write the edge-case tests first: pop on empty, wraparound, delete then get inside a transaction, rollback with nothing open.
- Solve the button-press stream problem, and say aloud when a long press is emitted and what happens to a press still held at the end of the stream.
Deliverable: Two passing implementations with their test lists, plus a written state machine for the button-press classifier.
Practice prompt ↗Practice prompt ↗03Geometry and grid search
- Merge collinear overlapping segments using an integer line key (gcd-reduced direction plus offset), projection onto the direction, then sort and merge. Test vertical segments and segments that touch at a single endpoint.
- Solve the base-camp grid problem with one BFS per team location, summing distances per cell and skipping any cell a team cannot reach. State the O(k·R·C) cost for k teams on an R x C grid.
- Take the vehicle collision prompt far enough to state the model: each vehicle's position as a function of time from its velocity, heading and yaw rate, and the pairwise check you would run to find the earliest contact.
Deliverable: Tested solutions for segment merge and base-camp BFS, and a written model for the vehicle collision question.
Practice prompt ↗Practice prompt ↗04Parsing and validation problems
- Parse a nested JSON payload to find the maximum vehicle velocity. Handle missing fields and non-numeric values explicitly instead of letting them throw.
- Build the nested-object validator: recursively check a payload against a schema of types and nested fields, and return the path of the first mismatch.
- Write a small expression evaluator with variables and operator precedence, and detect cyclic dependencies with a DFS that marks nodes as visiting or done.
Deliverable: A validator and an evaluator that report errors with a location, each tested against missing fields, wrong types and a cycle.
Practice prompt ↗Practice prompt ↗Worked solution ↗05Design rounds
- Design the single-threaded task scheduler: the API for scheduleOnce, schedulePeriodic and scheduleWithDelay, a min-heap on next run time, rescheduling periodic tasks from their planned time so they do not drift, and cancellation.
- Design the out-of-core Game of Life: the memory arithmetic, row-band processing with neighbour rows, and a separate output file per generation.
- Design the telemetry replay system: data schema, API, an index on vehicle and time, and the storage layers.
- Work through the async export worked exercise for how it handles leases and duplicate runs, which applies directly to a job scheduler that may run a task twice.
Deliverable: Three one-page designs, each starting from a data layout and a stated number.
Practice prompt ↗Practice prompt ↗06Onsite rehearsal
- Run a mock with a coding problem, a design question and a Leads Chat walkthrough back to back, with someone else choosing the problems from this guide.
- Have the mock interviewer run your code against inputs you did not see, and count the failures.
- Straight after, write down the moments you lost the thread and fix only those.
- If data volume came up in the design, review the projection-diff worked exercise to see how per-row lookups are replaced with one ordered pass.
Deliverable: Mock notes listing failing inputs and lost-thread moments, each with a specific fix.
Practice prompt ↗Practice prompt ↗07Leads Chat and taper
- Build the career timeline from your choice of university and major through each internship and job change, with one sentence of motivation per step.
- Prepare two stories: shipping under time pressure, and code that failed in production or missed an edge case. For each, cover what you did, how you fixed it and what you changed afterwards.
- Answer 'why Applied Intuition over a large tech company or an early-stage startup' so that it matches the version you wrote on day 1.
- Warm up on one problem you can already solve from a blank file, and open no new material.
Deliverable: A one-page timeline, two behavioural stories and a final 'why here' answer, all consistent with your day-1 answer.
Practice prompt ↗Practice prompt ↗Worked solution ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Candidates report behavioural questions mainly in the Leads Chat. It is described as a chronological walk through your background from college onward, not a set of STAR prompts. Expect follow-ups on why you made each choice, how you handle heavy workloads and tight deadlines, and why this company. Prepare the timeline first, then the individual stories, and check that the numbers and ownership you claim match what you said in the technical rounds.
Describe a situation where you had to ship a complex technical solutio…
Describe a situation where you had to ship a complex technical solution under extreme time pressure. How did you balance execution speed with code quality?
Approach
- Close with what you would do differently, concretely.
- Name the disagreement and how you resolved it with evidence.
- Pick a story where you made the decision, not one where you watched it.
Follow-up
- How did you know your change caused the improvement?
- What would you do differently if you ran that again?
Walk us through every key academic and career decision you have made f…
Walk us through every key academic and career decision you have made from college to your current role, explaining the motivation behind each choice.
Approach
- State the situation in two sentences and spend the rest on the reasoning.
- Pick a story where you made the decision, not one where you watched it.
- Give the blast radius: what could have broken, and what you measured.
Follow-up
- How did you know your change caused the improvement?
- What would you do differently if you ran that again?
Turn a code review disagreement into a decision
A colleague's change updates a row with UPDATE resource SET version = version + 1 WHERE resource_id = $1 AND version = $2 and treats an affected-row count of zero as a successful no-op. You read that as a silently lost update; they think returning 200 is friendlier to clients than returning a conflict. Describe how you have handled a review disagreement of this shape: what goes in the comment, when you leave the thread, and who decides. Then write the comment you would leave here, in under 80 words.
Approach
- Sort the disagreement before writing anything. A silently discarded write is a correctness claim about data; the choice between 409 and 412 is taste. Only the first justifies blocking a merge, and saying which one you are doing is most of the value of the comment.
- Make the claim reproducible in the comment itself with an interleaving rather than a principle: A reads version 7, B reads version 7, B commits version 8, A's predicate matches zero rows, A is told it succeeded and A's edit is gone.
- Offer the alternative with its cost attached: return 409 carrying the current version and the revision that won, so the client can re-read and re-apply. Note that automatic retry is not the fix, because a retry re-reads the winner's state and reapplies an intent formed against data that no longer exists.
- Apply an escalation rule you can state: two round trips on the thread, then a call, and the service's owner decides rather than the reviewer. A reviewer who cannot be overruled is a bottleneck with extra steps.
- Close in writing wherever the decision lands, so the next reader finds the reasoning in the code or the ticket instead of in a collapsed review thread.
Follow-up
- Where would you put the test that fails if someone reintroduces the swallowed zero rowcount?
- The author says clients cannot handle a 409. How do you check whether that is true?
- How do you handle the same review comment when the author is more senior than you and in a hurry?
- 01
Walk through every key academic and career decision you have made from college to your current role, explaining the motivation behind each choice.
- 02
Why are you interested in Applied Intuition, and why are you choosing to leave your current role at this point in your career?
- 03
Describe a situation where you had to ship a complex technical solution under extreme time pressure. How did you balance execution speed with code quality?
- 04
How do you approach working in an intensive in-office environment that demands high individual ownership and fast execution?
- 05
Why Applied Intuition over established large tech companies or early-stage startups?
- 06
Describe a time when your code failed in production or missed a critical edge case. How did you fix the issue and prevent it from happening again?
Is this an official Applied Intuition interview guide?
No. It is PracHub's own research and practice material for the Software Engineer role at Applied Intuition. Rounds and questions reflect what candidates have reported, not a process Applied Intuition has published, and they change over time. Confirm the current format and scope with your recruiter.
PracHub interview research ↗What are the stages of the process?
Candidates report three stages: an initial screening call, a technical assessment done as live coding, and an onsite. Onsite reports describe a brief group meet-and-greet, three to four technical rounds covering coding, systems design and practical engineering, and a final Leads Chat. The onsite can be virtual or in person. Confirm the current format with your recruiter.
PracHub Software Engineer practice ↗What is the primary coding language used during the software engineering interviews?
Reports say you can generally choose your language for algorithmic rounds, and C++ and Python are the most common choices. For low-level systems, Vehicle OS or robotics-focused teams, C++ is strongly recommended and sometimes explicitly requested. If you are interviewing for one of those teams, review modern C++ fundamentals: standard containers, smart pointers, move semantics and RAII.
PracHub interview research ↗What kind of coding problems should I expect?
Reported problems are practical implementations framed around simulation and vehicle data: a circular buffer that overwrites its oldest element, a nested-transaction key-value store, merging collinear 2D segments, BFS over a grid, parsing a button-press stream, and finding peak velocity in a JSON payload. Reported difficulty ranges from medium to hard. Candidates report that interviewers may run your code against their own test cases, so practise getting to a working, tested solution, not only the right approach.
PracHub Software Engineer practice ↗What do the system design questions look like?
Reported design prompts include a single-threaded task scheduler with scheduleOnce, schedulePeriodic and scheduleWithDelay; a replay system for autonomous vehicle telemetry covering schema, API, indexing and storage; a schema validation engine for nested JSON; and a 1M x 1M Game of Life grid that exceeds memory. Start each one from the data layout and memory arithmetic, then the API, then how it handles failure.
PracHub Software Engineer practice ↗What makes the "Leads Chat" interview different from typical behavioral rounds?
Reports describe the Leads Chat as a final onsite conversation with senior engineering leaders or managers that walks chronologically through your background from college onward. Instead of standard STAR prompts, it asks why you made each academic and career choice, how you handle workload pressure, and why you are interested in Applied Intuition. Prepare a timeline with one line of motivation per step, and keep it consistent with what you said earlier in the process.
PracHub interview research ↗Is the Software Engineer role remote?
Reported role requirements describe full-time in-office work, typically five days a week at offices such as Mountain View or Sunnyvale. Confirm the expectation for your location with the recruiter early in the process.
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.
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.
IBM Software Engineer Interview Guide
Failure-handling practice for IBM software engineer candidates: requests whose outcome a timeout leaves unknown, where a retry is safe, and deduplicating at the receiver instead of assuming exactly-once delivery.
Cisco Software Engineer Interview Guide
Operational practice for Cisco software engineer candidates: picking the signal that catches a bad release early, and telling a latency regression apart from a shift in traffic mix.
Adobe Software Engineer Interview Guide
Database practice for Adobe candidates: how an index changes a query plan, and which anomalies survive a given isolation level, since read committed still permits non-repeatable reads.