The reported work is less about writing every line yourself and more about making agents productive and trustworthy. Candidates describe building the scaffolding agents run inside (context files and prompt structure), designing checks that decide whether generated code is acceptable without a person reading it, and coordinating several agent workstreams towards output that is tested and shippable. That shapes the questions: they ask you to explain how you have used tools like Claude Code and Cursor, and how you would build the safety net around them.
The reported questions fall into five groups. Experience questions ask about AWS and about a project where you used agentic tools. Design questions ask about a multi-component architecture you built and about a verification system for AI-generated code. Problem-solving questions ask what you do when AI output misses quality standards and how you innovated under a tight deadline. Behavioral questions cover explaining technical ideas to a non-technical audience and leading or influencing stakeholders. Two coding questions, data structure trade-offs and speeding up slow code, are the only algorithmic ones, and candidates describe the loop as light on code writing.
Preparation therefore means having specific, honest stories. For the experience and design questions, choose real projects and be ready to say what the agent got wrong, how you caught it and what you changed in the spec or the checks. Practise writing a task specification with acceptance criteria that a machine can run. Revise the stack the role lists: an AWS project you can describe decision by decision, plus TypeScript, Node.js or Python fluency for any coding task.
The behavioral and final stages are described as conversations about past experience, teamwork and collaboration. Candidates also describe cross-functional work with product managers and educators, so your stories should show you explaining a technical point to someone who has to decide something, and moving a group towards a shared goal without relying on title.
Application Review
reportedCandidates describe this first stage as a check of your application against the basic qualifications for the role. The requirements candidates report are 5+ years of software engineering, ideally in AI and automation, working proficiency with Claude Code and Cursor, and solid Node.js, TypeScript or Python. Your CV is the only material at this stage, so make each of those requirements visible in a bullet backed by a concrete project.
What to demonstrate
- Whether your experience matches the reported requirements, especially years of engineering and agentic tool use
- Whether your stack (Node.js, TypeScript, Python, AWS) is visible in your recent work
- Whether extras such as MCP servers, custom agent tooling or token-cost control appear in your history
How to prepare
- Rewrite CV bullets so each names a system, your decision and a result, and add one bullet that shows agentic tool use if you have it
- Outline the AWS project and the Claude Code or Cursor project you would talk about, since both are reported questions
- If you have built an MCP server, internal agent tool or token budget control, give it its own line
Technical Assessments
reportedCandidates describe this stage as coding challenges or problem-solving tasks. Reports list two coding questions (data structure trade-offs and speeding up slow code) and two problem-solving questions (handling AI output that misses quality standards, and innovating under a tight deadline), though they do not say which appear here. Candidates also describe the loop as light on code writing, so expect reasoning to matter as much as syntax.
What to demonstrate
- Working code or a clear technical approach to a coding or problem-solving task
- How you structure an ambiguous problem before solving it
- Reasoning about data structure choice and performance
How to prepare
- Rehearse the data structure trade-off answer on one concrete problem: lookup by key, ordered iteration, queue behaviour, with the complexity of each choice
- Practise a profiling sequence for slow code: measure, find the hot path, fix the algorithm or the I/O, measure again, and use the PracHub latency-spike debugging practice question to rehearse reading symptoms
- Write a short triage routine for AI output that fails a quality bar: reproduce, classify the failure, fix the spec or the checks, then re-run
Behavioral Interviews
reportedCandidates describe these interviews as discussions of your past experiences, how you work in a team and how you solve problems. The reported behavioral questions cover explaining technical concepts to a non-technical audience, leading a team or influencing stakeholders, and innovating under tight deadlines. Candidates also report a theme of working across product managers, educators and other engineers.
What to demonstrate
- Communication across technical and non-technical colleagues
- How you work with a team and with stakeholders
- How you approach problems and set direction in ambiguous situations
How to prepare
- Write three outlines, one for each reported behavioral question, each with your own decision, the alternatives and a result you can verify
- Rehearse the audience story aloud so that the opening names the decision your listener had to make
- Add one story about a time you worked with a product manager or another non-engineer on a shared deliverable
Final Interviews
reportedCandidates describe the final stage as in-depth conversations with team members about cultural fit and collaborative skills. Reports list mentoring junior engineers and working with product teams as part of the role, so this stage is a good place for stories about how you work with other people over a longer stretch, rather than a single heroic delivery.
What to demonstrate
- Collaboration and working style with future teammates
- Depth of your own project experience when a team member follows up
- Fit with the AI-assisted way of building software that the role describes
How to prepare
- Rehearse the story about leading a team or influencing stakeholders until you can give it with real detail and without notes
- Prepare an honest account of how you use Claude Code, Cursor or similar tools day to day: what you delegate, what you check yourself
- Write questions for the team about how agent output is verified and how agent work is split between engineers
PracHub editorial advice for the preparation topics above.
Answering the AWS experience question with a list of services
Pick one project and walk through it: the problem, the services you chose and the one you rejected, what it cost or how it failed, and what you would change. A single decision explained well is stronger than ten service names.
Describing a Claude Code or Cursor project as if the tool's output was accepted as it came
Say where you checked the output, what it got wrong and what you changed in the prompt, context file or tests as a result. The role is described as building the verification around agents, so a story with no checking step undercuts it.
Answering the specification question with a prose wish list
Give the shape of a machine-executable spec: goal, inputs and outputs, constraints, files in scope, and acceptance criteria that a test or script can run. Show one before-and-after where a vague spec produced a wrong result.
Designing a verification system that ends at having another model review the code
Layer it: type checks and linting, unit and integration tests, contract checks, sandboxed execution, and a rule for what is escalated to a person. Say how you would catch the checks themselves being wrong or gamed, and how the system reports its confidence.
Telling behavioral stories in the plural with no personal decision, or with jargon the listener could not follow
Open each story with your decision and the person who needed the result, use plain wording, and finish with a result you can check. Rehearse the non-technical explanation aloud so that it does not need a diagram.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Explain the trade-offs between different data structures for a given problem.
Explain the trade-offs between different data structures for a given problem.
Approach
- Ask for the operation mix first (lookups, inserts, deletes, ordered iteration, range queries, min or max) and the data size. The right structure follows from which operations dominate.
- Arrays and dynamic arrays give O(1) indexing, amortised O(1) append, O(n) insert in the middle and good cache locality. Linked lists give O(1) insert or delete at a known node but O(n) search and poor locality.
- Hash maps give average O(1) lookup and insert, worst case O(n) under heavy collisions, and no sorted order. Balanced BSTs (a Java TreeMap, a C++ std::map) give O(log n) operations plus ordered iteration, floor and ceiling, and range queries.
- A binary heap gives O(1) peek, O(log n) push and pop and O(n) heapify, but no efficient search. A trie answers prefix queries in O(length of the key). Know your language: Python's heapq is a min-heap, Python has no built-in balanced BST, and JavaScript has no built-in heap.
- Show the trade-off on a combined example: an LRU cache pairs a hash map with a doubly linked list for O(1) get and put, and top-k over a stream keeps a size-k min-heap for O(n log k) instead of sorting at O(n log n).
Follow-up
- Design an LRU cache with O(1) get and put, and explain why one structure on its own is not enough.
- How would you return the k most frequent items from a stream too large to sort?
- When would a sorted array with binary search beat a hash map?
How would you optimize a piece of code that is running slower than expected?
How would you optimize a piece of code that is running slower than expected?
Approach
- Define slow against a target (p95 latency, throughput, job duration) and reproduce it with representative input sizes before touching code. Optimising without a measurement is guesswork.
- Profile to find the hot path: cProfile or py-spy for Python, node --prof or the --inspect CPU profiler in Chrome DevTools for Node.js. Spend effort only on the dominant cost, because by Amdahl's law speeding up a 5% section cannot help much.
- Check complexity before micro-tuning: a nested loop doing membership tests is O(n^2) and becomes O(n) with a hash set. Repeated work can be memoised or hoisted out of loops.
- Then check I/O: N+1 database queries become one batched query or a join, a missing index shows up in EXPLAIN, and sequential independent network calls can run concurrently. In Node.js, synchronous CPU work blocks the event loop, so move it to worker_threads. In standard CPython builds the GIL keeps threads from running Python bytecode in parallel, so use multiprocessing or vectorise with NumPy.
- Confirm the fix with a benchmark against the baseline, keep the tests green for correctness, and state the cost: extra memory for caches, staleness for cached results, or harder-to-read code.
Follow-up
- The profile shows time spread evenly with no single hot spot. What do you try next?
- How would you show that a Node.js service is slow because its event loop is blocked?
- Your cache made it fast but memory doubled. How do you bound it?
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.
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?
Keep soft-deleted accounts from blocking re-registration
app_user holds user_id, tenant_id, email CITEXT, password_hash (NULL for SSO principals), email_verified_at, auth_version, status ('invited','active','suspended','deactivated'), created_at, updated_at, deleted_at. Two live accounts for one address inside a tenant must be impossible, but an address freed by a soft delete must be reusable, and the same tenant may delete and re-register it repeatedly. Write the uniqueness DDL for PostgreSQL 16, then the equivalent for MySQL 8 where partial indexes do not exist, and say what each permits once three deleted rows already hold that address.
Approach
- Start from what is actually unique: not (tenant_id, email), but (tenant_id, email) among live rows. PostgreSQL says that directly — CREATE UNIQUE INDEX app_user_live_email ON app_user (tenant_id, email) WHERE deleted_at IS NULL. A full constraint over the same two columns burns the address permanently the first time someone deletes an account.
- Keep case-insensitivity in the type or the index, never in the application: CITEXT as given, or UNIQUE (tenant_id, lower(email)) as an expression index where the extension is unavailable. A case-sensitive unique column is exactly how two accounts for one human appear.
- For MySQL 8 the predicate has to move inside the key: add a discriminator column that is a constant 0 while the row is live and is set to user_id on delete, with UNIQUE (tenant_id, email, deleted_marker). Live rows share the constant and still collide; deleted rows differ from each other and stop colliding.
- State the NULL variant and its dependency: leaving the marker NULL for deleted rows also works, because a unique index treats NULLs as distinct — true in MySQL, and true in PostgreSQL only under the default NULLS DISTINCT, which PostgreSQL 15 lets you reverse. Check the polarity against the three existing deleted rows: constant-on-live is what preserves the collision you want, and reversing it silently admits duplicate live accounts.
Follow-up
- A deleted account re-registers with the same address the next day. Do the old resource rows follow the new user_id, and how does the API keep the two principals apart?
- How do you honour an erasure request while resource_revision.actor_user_id still references this table?
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.
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?
What experience do you have with AWS, and how have you utilized it in your previous projects?
What experience do you have with AWS, and how have you utilized it in your previous projects?
Approach
- Anchor the answer in one project you can defend in detail rather than listing every AWS service you have touched: name the problem, the services you chose and the access pattern that drove each choice.
- Justify compute choices by their limits: Lambda caps a single invocation at 15 minutes and adds cold-start latency, so long or steady workloads often fit ECS on Fargate or EC2 better; say which side of that line your workload sat on.
- Explain storage by access pattern: DynamoDB when every query is known up front and keyed on a partition key, RDS or Aurora when you need joins and ad hoc queries, S3 for blobs and large artefacts.
- Cover the operational layer: IAM roles with least-privilege policies instead of long-lived access keys, infrastructure as code (CloudFormation, CDK or Terraform), and CloudWatch alarms on the metrics that mattered.
- If you used SQS or SNS to decouple services, describe the visibility timeout, retries and a dead-letter queue for poison messages, and give one cost or reliability result you actually measured.
Follow-up
- Why did you put a queue between those two services instead of calling the downstream one directly, and what happened to a message that kept failing?
- How did you scope the IAM permissions for that function or task, and how would you audit them?
- Which line on the monthly bill was largest, and what would you change to cut it?
Can you describe a project where you implemented agentic tools like Claude Code or Cursor?
Can you describe a project where you implemented agentic tools like Claude Code or Cursor?
Approach
- Name the tool (Claude Code, Cursor or similar) and the class of work you handed to it: test generation, migrations, refactors across many files, new endpoints. Be specific about what stayed with you.
- Describe the scaffolding you wrote: a project context file such as CLAUDE.md for Claude Code or rules files for Cursor, encoding build and test commands, conventions and directories the agent must not touch.
- Explain how output was checked before merge: type checking (for example tsc --noEmit), lint, the test suite and CI gates, plus how you kept the agent from weakening or deleting tests to get a green run.
- Give one concrete failure (an invented API, a change outside the task's scope, a loop of failing retries) and what you changed in response: smaller tasks, more context, a new check or a hook.
- State results you can back up, such as fewer review rounds or faster migrations, and mention any token-cost or custom tooling work (an MCP server, for example) only if you actually built it.
Follow-up
- Which kind of task did the agent handle worst, and how did you change the scoping or context for it?
- How did you stop the agent from editing files outside the task, or from changing tests to make them pass?
- How did you track and limit token spend across runs?
How do you approach writing specifications for AI agents to execute tasks independently?
How do you approach writing specifications for AI agents to execute tasks independently?
Approach
- Structure the spec as goal, non-goals, constraints and acceptance criteria. Write the acceptance criteria as executable checks (named tests, commands that must exit 0, a type check) so the agent can verify its own work without a human.
- Point the agent at the exact files, interfaces and examples it needs instead of pasting the whole codebase. Context windows are finite, and irrelevant context lowers output quality and raises token cost.
- Break large features into small tasks that can be checked independently, with explicit order and dependencies. Each task should end in a state where the tests pass, so one failure does not spoil later work.
- State what the agent must do when the spec is ambiguous or a check cannot pass: stop and report with evidence rather than guess, and never edit protected paths such as the tests that define done.
- Treat the spec like code: version it, record which specs led to rejected output, and tighten the wording or the checks where agents went wrong. The trade-off is that an over-detailed spec takes longer to write than the code it describes.
Follow-up
- How do you stop an agent from passing the acceptance checks by changing the tests themselves?
- How would you split a feature that spans the frontend and the backend into specs two agents can run in parallel without conflicting edits?
- When an agent's output is wrong, how do you tell whether the spec, the context or the model was at fault?
Describe a system architecture you designed that required collaboration among multiple components.
Describe a system architecture you designed that required collaboration among multiple components.
Approach
- Pick one system you owned and sketch its components and the contracts between them: which calls are synchronous (HTTP or GraphQL) and which go through a queue or event stream, and why each boundary sits where it does.
- Make data ownership explicit: each component owns its own store. If a write must both update a database and publish an event, mention the transactional outbox pattern so the two cannot drift apart.
- Walk through failure handling: timeouts on every remote call, retries with exponential backoff and jitter, idempotency keys so a retried request does not double-apply, and a dead-letter path for messages that keep failing.
- For multi-step workflows across components, say whether you used orchestration (one coordinator) or choreography (events), and how compensating steps undo partial work, as in the saga pattern.
- Close with observability (a correlation or trace ID carried across components), the scale you actually ran at, and the one boundary you would redraw today and why.
Follow-up
- What happens if a consumer processes the same message twice, and how does your design make that safe?
- Which component failed in production, and how did you trace the problem across the boundaries?
- If you rebuilt it today, which boundary would you move or remove?
How would you design a verification system for AI-generated code?
How would you design a verification system for AI-generated code?
Approach
- Frame it as a pipeline of gates ordered cheapest first: parse, format and lint, then type checking (tsc, mypy), then unit tests, then integration tests. Reject early, and return structured failure output the agent can act on in a retry.
- Run everything in an isolated sandbox (a container or microVM) with no production secrets, restricted network access and CPU, memory and wall-clock limits, because generated code is untrusted input.
- Protect the oracle: tests and acceptance checks live in paths the agent cannot modify, and any diff that touches them is flagged. Add a scope check on changed files and diff size against what the task allowed.
- Go beyond the agent's own tests: property-based tests (Hypothesis, fast-check), mutation testing to measure whether the tests catch real faults, static security analysis (Semgrep or CodeQL), and a check that every new dependency exists and is on an allowlist, since models can name packages that do not exist.
- Cap retries per task and route to a human after N failures. Track escaped defects, false rejections and flaky-test rate, and quarantine flaky tests so they neither block good changes nor send the agent into a loop.
Follow-up
- How do you verify a change to a module that has no tests yet?
- How do you keep one flaky test from rejecting correct changes or making the agent retry forever?
- What kind of wrong change could pass every gate you described, and what would catch it?
How would you tackle a situation where an AI-generated output fails to meet quality standards?
How would you tackle a situation where an AI-generated output fails to meet quality standards?
Approach
- Start by turning "fails quality standards" into a concrete failure class: wrong behaviour, an invented API, a style or convention breach, a security problem or a scope violation. Each one is fixed at a different layer.
- Reproduce with the full input captured: the prompt or spec, the context files, tool outputs, model and version, and sampling settings. Without that record you cannot tell a one-off from a pattern.
- Because outputs are non-deterministic (even temperature 0 is not guaranteed to be identical), rerun the case several times and measure a pass rate rather than judging from one sample.
- Find the root cause and fix that layer: missing context, an ambiguous spec, a task that is too large for one step, or a model limitation. Then add a check or test that catches this failure class automatically.
- Add the failing case to a regression evaluation set so future spec, prompt or model changes are tested against it. In the meantime, reject or roll back the output instead of quietly patching it by hand.
Follow-up
- How many reruns would you need before you trust that a fix worked, and what pass rate would you accept?
- What would you do if the output is sometimes correct and sometimes not for the same input?
- At what point do you stop adjusting the prompt and change the task decomposition or the model instead?
Read latency spikes on a sixty-second sawtooth
The cached listing read path serves about 14k reads/second at an 85% hit rate. p99 sits at 35 ms for 57 seconds, jumps to 900 ms for 3, and repeats. During each spike the primary shows several hundred identical listing queries starting within the same millisecond, all carrying one large tenant's id. Cache entries use a 60-second TTL. Give the mechanism, the ordered checks, the fix, and the correctness hazard your fix must not introduce.
Approach
- Match the period to a configured number before theorising about load. A spike every 60 seconds against a 60-second TTL is an entry expiring, and you confirm it by correlating spike timestamps with the entry's write time rather than with the traffic curve. If the period had matched a cron or a GC interval instead, this is a different investigation.
- Establish the concurrency of the miss. Several hundred identical queries in one millisecond means the miss path has no coalescing: every request that arrives between expiry and repopulation recomputes. The herd size is that key's arrival rate times its recompute time, so at 1.2k reads/second for the hot key and a 250 ms recompute you expect about 300 concurrent misses, which matches what is observed.
- Add single-flight on the miss path so one caller per key recomputes under a short-lived lock while the rest wait for its result. Prefer stale-while-revalidate where the read tolerates it: return the expired value immediately and refresh asynchronously, which removes the latency spike rather than serialising it into a queue of waiters.
- De-synchronise the keys. Write TTLs with jitter, for example 60 seconds plus or minus 10%, so a deploy or a mass invalidation does not align every key on the same second and turn a per-key herd into a fleet-wide one.
Follow-up
- The same sawtooth appears on a key that is invalidated on write rather than expired. Is that the same bug?
- How does your answer change if the recompute takes 4 seconds instead of 250 ms?
The plan starts with the four reported rounds and the reported requirements, then spends a day each on the experience, specification, verification and coding questions, and finishes with the three behavioral stories and a full spoken run-through.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the loop to your own experience
- Write the four reported rounds, then list the reported requirements: 5+ years, Claude Code or Cursor, Node.js, TypeScript or Python, and the optional MCP, token-cost and education items.
- Next to each requirement, write the project that proves it, and mark any with no evidence as gaps.
- Choose the AWS project and the agentic-tool project you will use as your main examples.
Deliverable: A one-page table of requirements against evidence, with the two chosen projects and the gaps marked.
02AWS and agentic tool stories
- Write an outline of your AWS project: the problem, the services chosen and rejected, one failure or cost surprise, and what you would change.
- Write an outline of your Claude Code or Cursor project: the task, how you gave context, what the agent got wrong, how you caught it and what you changed afterwards.
- Say each outline aloud once and cut anything that is a list of tools rather than a decision.
Deliverable: Two spoken outlines, one for the AWS question and one for the agentic-tools question, each ending in a lesson.
Practice prompt ↗Practice prompt ↗03Specs for agents and multi-component design
- Write a specification for a small task an agent could run alone, such as adding a GraphQL query in TypeScript, with inputs, constraints, files in scope and runnable acceptance criteria.
- Rewrite it once after listing three ways an agent could satisfy the words and still be wrong.
- Outline a system you built with several cooperating components: a diagram, the interface between each pair, and what happens when one fails.
Deliverable: One agent-ready spec with acceptance criteria and one architecture outline with its failure cases.
Practice prompt ↗Practice prompt ↗04Verification of AI-generated code
- Design a pipeline that decides whether generated code is accepted without manual review: static checks, tests, sandboxed runs, a contract check and an escalation rule.
- Write the triage routine for AI output that fails a quality bar: reproduce, classify the failure, fix the spec or the checks, and re-run.
- Rehearse a comparison-style check with the PracHub practice question on diffing a projection against the primary, then say how the same idea applies to checking generated output against a reference.
Deliverable: A verification design on one page, with a written triage routine and the comparison practice question completed.
Practice prompt ↗Practice prompt ↗Practice prompt ↗05Coding: data structures and slow code
- Pick one problem and compare three data structures for it (hash map, sorted structure, queue or heap), with the complexity and the failure case of each, in TypeScript or Python.
- Take a slow function, write a profiling sequence for it, and fix the dominant cost; state the complexity before and after.
- Work through the PracHub latency-spike debugging practice question to rehearse reading a symptom back to a cause.
Deliverable: A data structure comparison, one optimised function with before-and-after complexity, and the debugging practice question finished.
Practice prompt ↗Practice prompt ↗Practice prompt ↗06Behavioral stories
- Write the outline for the non-technical audience story, starting from the decision your listener had to make.
- Write the outline for the story about leading a team or influencing stakeholders, naming the conflict and the evidence that settled it.
- Write the tight-deadline story with the option you rejected, the safeguard you used and the clean-up afterwards, then say all three aloud.
Deliverable: Three spoken story outlines, each with your own decision and a verifiable result.
Practice prompt ↗Practice prompt ↗Practice prompt ↗07Full spoken run-through
- Answer aloud, in sequence, the agentic-tools question, the verification system question and the failing AI output question.
- Answer the leadership story once more as you would for the final conversations with team members.
- Write five questions for the team about how agent output is checked and how work is divided between engineers and agents.
Deliverable: One recorded run-through, a list of weak spots to fix and five prepared questions.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Candidates describe the behavioral and final stages as conversations about past experience, teamwork and collaboration. The reported prompts centre on explaining technical ideas to non-technical colleagues, leading or influencing others, and working under deadline pressure, and the role description stresses stakeholder communication. Prepare stories where you made the decision, and where the stakeholders were people such as product managers or educators.
Share an example of a time when you had to translate technical concepts for a non-technical audience.
Share an example of a time when you had to translate technical concepts for a non-technical audience.
Approach
- Choose a moment when your listener had a decision to make that depended on the technical point, for example a product manager or educator weighing a deadline against a risk. Open with that decision, so the story is about an outcome and not a lecture.
- Show the translation itself: name the one or two ideas that mattered, the jargon you dropped, and the comparison or example you used in its place. For instance, "I told them the agent's output is a first pass that an automated test suite accepts or rejects" is concrete; "I simplified it" is not.
- Show that you checked understanding: you asked them to restate the trade-off, watched which questions came back, or followed up in writing. Say what you changed after a first attempt landed badly.
- Close with the result in their terms (decision made, scope changed, risk accepted) and say what the simplification left out, so the answer is accurate as well as clear. The mistake that sinks this answer is an analogy that is wrong, or a story that never reaches a decision.
Follow-up
- How did you know they had understood and were not just nodding?
- What detail did you leave out on purpose, and what would have gone wrong if they had needed it?
- How would you explain to a product manager who wants to ship faster why AI-generated code needs automated checks?
Describe a project where you led a team or influenced stakeholders to achieve a common goal.
Describe a project where you led a team or influenced stakeholders to achieve a common goal.
Approach
- Pick a project where the goal needed several people or groups to move together. Say in one sentence what the goal was and why it was yours to drive, then name your own role precisely: what you decided, wrote, convened or unblocked.
- Describe each stakeholder by what they wanted (a product owner wanting scope, an engineer wanting stability) and where those wants collided. Influence stories are about handling that conflict, so spend most of your time there.
- Show the mechanism of influence: a short written proposal, a prototype or measurement that settled an argument, a staged rollout that lowered the risk for a sceptic, or an agreement on who makes the call. Evidence works better than persuasion.
- Give a result someone could check (shipped, adopted, error rate, lead time) and say what you would change. If you led junior engineers, include how you split the work and reviewed it. The usual failure is a story told entirely in the plural, where the listener cannot tell what you did.
Follow-up
- Who disagreed with you, and what did they say that changed your plan?
- What would have happened if you had not been involved?
- How did you keep the work moving after the people who resisted had agreed?
Discuss a time when you had to innovate under tight deadlines.
Discuss a time when you had to innovate under tight deadlines.
Approach
- Pick a deadline that was real and fixed, and state what was at stake in a sentence. Then name the constraint that made the usual approach impossible, since a story without a constraint is ordinary work done quickly.
- Lay out the options you weighed and why you rejected the obvious one: cutting scope, reusing an existing component, automating a manual step, or using an AI coding tool to generate repetitive code. If you used the last, say how you checked the generated code (tests, review, staged rollout).
- Name the risk you accepted and the safeguard that bounded it: a feature flag, a rollback path, tests around the riskiest module, and a written list of what was deliberately left out.
- End with the measured outcome and the clean-up: what shipped, what debt you recorded and what you did afterwards. The mistake that sinks this answer is overtime heroics, or corner-cutting presented as innovation, with no account of the consequences.
Follow-up
- What did you decide not to build, and who agreed to that?
- If the idea had failed halfway through, what was your fallback?
- What would you keep from that approach when there is no deadline?
- 01
Share an example of a time when you had to translate technical concepts for a non-technical audience.
- 02
Describe a project where you led a team or influenced stakeholders to achieve a common goal.
- 03
Discuss a time when you had to innovate under tight deadlines.
- 04
Discuss a complex problem you solved and the outcome.
- 05
Describe a time when you had to explain a technical concept to a non-technical team member.
- 06
Tell me about a time you helped a junior engineer improve the quality of their work.
How long does the Agentic interview process take?
Candidates report four stages over about three to five weeks, and some reports go as far as six depending on scheduling. The stages are Application Review, Technical Assessments, Behavioral Interviews and Final Interviews.
Agentic Software Engineer candidate reports ↗Is the Software Engineer role remote or hybrid?
The role is reported as hybrid, with four days a week onsite in the London area. Confirm the current arrangement with the recruiter before committing to a plan.
Agentic Software Engineer candidate reports ↗Do I need experience with Claude Code and Cursor?
Candidates report proficiency with agentic coding tools such as Claude Code and Cursor as a must-have, alongside strong Node.js, TypeScript or Python. Building custom agent tooling or MCP servers and controlling token spend are reported as extras. Prepare a real project in which you used these tools, including what you checked and what went wrong.
PracHub Software Engineer practice ↗How much coding should I expect?
Reports describe the loop as light on code writing, with algorithmic thinking still possible. The two coding questions candidates report are about data structure trade-offs and speeding up slow code, so prepare to reason clearly, explain complexity and write a short function in TypeScript or Python.
PracHub Software Engineer practice ↗How do I prepare for the verification system question?
Build a layered answer: static analysis and type checks, unit and integration tests, sandboxed execution, contract checks against interfaces, and an escalation path to a person for anything the checks cannot decide. Then explain how you would spot weak checks, for example by seeding known defects and confirming the system rejects them.
PracHub Software Engineer practice ↗Which stack should I revise?
The technologies reported for the role are AWS, Salesforce, Node.js, TypeScript, Python, React and GraphQL. Be able to discuss at least one AWS project in depth and be comfortable writing TypeScript or Python, since the other items are listed as part of the work and not tied to a particular round.
PracHub Software Engineer practice ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01Agentic Software Engineer candidate reports ↗
Company-reported rounds, questions and FAQ.
Candidate reports · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
PracHub practice material, not company-reported.
PracHub page · Accessed 2026-09-22 - 03PracHub preparation framework ↗
PracHub preparation guidance.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Vercel Software Engineer Interview Guide
Debugging practice for Vercel software engineer prep built on a reproduction you trust, narrowing to the smallest failing input, and changing one variable per run so the result stays attributable.
Together Ai Software Engineer Interview Guide
Failure-handling practice for Together Ai 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.
Lambda Software Engineer Interview Guide
Failure-handling practice for Lambda 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.
CoreWeave Software Engineer Interview Guide
Failure-handling practice for CoreWeave 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.