Interview guides · Agility Robotics

Agility Robotics Software Engineer Interview Guide

Agility Robotics Software Engineer interview guide: four reported rounds, robotics coding, perception and design questions, behavioral prep, 7-day plan.

The 60-second brief

Agility Robotics builds robots meant to work alongside people. Candidates describe the Software Engineer role as touching object perception, locomotion and human-robot collaboration, and the reported projects include Cassie and Digit. The reported day-to-day is designing, coding and testing software components for robotic systems, working with hardware engineers and product managers so the software fits the physical machine, debugging and tuning existing code for speed and reliability, taking part in code reviews, and exploring new methods in robotics.

This guide is for software engineers interviewing at Agility Robotics, especially those with a few years of experience in robotics or automation. It covers the four reported rounds, the technical questions candidates report (algorithms, debugging, SLAM, navigation, modular architecture, communication protocols, perception troubleshooting, pathfinding), the behavioral questions, and a plan for the coding exercise and the final presentation.

Candidates report four rounds over roughly three to five weeks: a Recruiter Call, a Coding Exercise (sometimes a take-home), a set of Multiple Interviews, and a Final Interview built around presenting your work or your coding solution.

Focus areas

Coding Exercises / Coding Assessments
Perception / Machine Vision (Robotics)
Take-Home Technical Assignment

Overview

The reported questions mix general software engineering with robotics-specific topics. The general ones are explaining an algorithm you built, debugging, optimizing a codebase and working with real-time systems. The robotics ones are SLAM, navigating a dynamic environment, a modular architecture for a robotic application, communication-protocol trade-offs, troubleshooting a robot that fails to recognize an object, and improving perception accuracy. Two coding questions are reported as well: detecting and classifying objects in an image, and pathfinding for a robot in a maze. Preparing means being able to write that code and also reason about the physical system it runs on.

Candidates describe a required toolkit of Python, C++ or Java, plus experience in robotics or a related field, with machine learning frameworks, agile practice and ROS listed as extras. Candidates also mention kinematics, perception and control theory as topics that can come up in discussion. You do not need to master all of them, but pick the language you will code in and be ready to name where you used it, and know enough ROS-style publish/subscribe and sensor-pipeline vocabulary to hold a design conversation.

The topics candidates associate with this loop are coding exercises, perception and machine vision, a take-home technical assignment, a technical presentation and open-ended problem solving. That shapes how to spend time: work the pathfinding and image-classification code until it is clean, rehearse a troubleshooting sequence for a failing perception system, and prepare one project you can present with its design choices, measurements and mistakes. Your behavioral stories should draw on the same material, so a performance story or a real-time story can double as presentation content.

The Agility Robotics interview process

These are the four stages candidates describe, in the order they report them. Treat the order and format as reported experience rather than a published process, and ask your recruiter what applies to your loop.

Recruiter Call

Candidates describe the first stage as a screening call with a recruiter about your background and why you want the role. No technical questions are reported for it by name, so treat it as the place to establish your fit and learn the shape of the rest of the loop, including whether the coding exercise is live or a take-home. Be concrete about your robotics or automation experience, since that is what the role requirements emphasise.

What to demonstrate

How your background lines up with the role as candidates describe it: software development in Python, C++ or Java, with robotics or automation experience
Your interest in the role and in robotics specifically
Basic communication, since it is a conversation rather than a technical exercise

How to prepare

Write a two-minute walkthrough of your career that ends on a robotics, perception, controls or embedded project, and the part you personally owned.
Prepare the answer to the motivation question (what draws you to robotics and where you want to go) so it is specific rather than generic.
Decide which language you will code in (Python, C++ or Java are the ones listed) and be ready to say where you have used it.
Ask what the Coding Exercise looks like (live or take-home) and what the Final Interview presentation should cover.

Coding Exercise

Candidates report a coding exercise, and some describe it as a take-home assignment. The topics associated with this loop include coding assessments and a take-home technical assignment, and two reported coding questions are detecting and classifying objects in an image and pathfinding for a robot in a maze. Because the Final Interview is reported to involve presenting your solution, write the code as something you will have to explain: clear structure, tests, a short README stating assumptions, and notes on what you would improve.

What to demonstrate

Working, readable code in a language you chose
Choice of algorithm and data structure for problems such as grid pathfinding and image processing
How well you can later explain and defend the solution, since presentation is reported at the final stage

How to prepare

Implement breadth-first search and A* on a grid with obstacles, then handle a start or goal that is blocked, no path, and weighted cells.
Sketch a detect-and-classify pipeline (preprocess, propose regions or run a model, filter by confidence, classify) and decide which parts you would write by hand and which you would call from a library.
Write unit tests for your own solution and state the time and space complexity in comments or a README.
Keep a log of decisions and trade-offs as you code so the presentation material already exists.

Multiple Interviews

The third stage is reported as Multiple Interviews that include behavioral assessments, technical problem-solving and discussions about past projects. The reported question types for this stage's themes include explaining an algorithm, debugging a robotic system, real-time systems, optimization, SLAM, navigating a dynamic environment, modular architecture and communication protocols, plus the leadership, conflict and motivation prompts. Because the sessions span several formats, prepare both technical frameworks and rehearsed stories.

What to demonstrate

Technical problem-solving across algorithms, debugging and robotics design topics
How you describe past projects: your role, decisions and results
Behavioral skills such as leading under pressure and resolving technical disagreements
Communication and collaboration with hardware and product colleagues, which the role description mentions

How to prepare

Rehearse a structured answer for SLAM: what it estimates, the sensors involved, the front end and back end, loop closure and drift.
Prepare a design outline for navigation in a dynamic environment covering perception, a map, global and local planning, replanning and safety stops.
Write a modular architecture sketch with message boundaries, plus a short comparison of communication options (latency, reliability, ordering, discovery).
Prepare two or three STAR stories covering real-time work, a performance optimization, a deadline you led and a technical disagreement.

Final Interview

Candidates report that the Final Interview centres on presenting your work, or your solution to the coding challenge. That makes it a communication exercise as much as a technical one: explain the problem, your design, the results and what you would change, to an audience that may include people outside your specialty. Prepare slides or a walkthrough that you can cut short or expand, and be ready to defend each choice.

What to demonstrate

Clarity when presenting your own technical work
Depth of understanding of the decisions behind your solution or project
How you handle questions and alternatives to your approach

How to prepare

Choose between presenting your coding-challenge solution or a past robotics project, and structure it as problem, constraints, design, results, limitations.
Prepare one slide or section on a failure, a debugging story or a trade-off that you rejected and why.
Practise a version that fits in a short window and one that opens up for deeper questions on algorithms, perception accuracy or architecture.
Run the presentation aloud for someone outside your area and fix every place they ask for a definition.

Where candidates lose points

Treating the maze pathfinding question as a memorized algorithm

State the grid or graph model, the move set and how obstacles are represented before coding. Choose BFS for unweighted shortest paths or A* with an admissible heuristic such as Manhattan distance, handle no-path and blocked-start cases, and say how the answer changes when obstacles move and the plan must be recomputed.

Answering the failed object recognition scenario with 'retrain the model'

Walk the pipeline in order: sensor and calibration, lighting and exposure, preprocessing, model input and thresholds, then the output consumers. Compare frames that fail against frames that pass, check what changed, and only then decide whether data, model or configuration is the cause.

Giving performance or real-time stories with no measurements

Bring a baseline, a profile or trace, the specific change and the after numbers on the same workload, including worst-case or tail latency. If you cannot state those, choose a different story or prepare the figures first.

Giving design answers that name SLAM, ROS or a protocol but never state a trade-off

For navigation, architecture and communication questions, give requirements first, then at least two options with the reason you pick one: latency against reliability, coupling against flexibility, accuracy against compute. Say what fails when a sensor drops out or a node crashes.

Arriving at the final presentation unable to defend decisions in the coding solution

While solving the exercise, record why you chose each data structure, library and test, and what you would do with more time. Rehearse the presentation aloud and expect to justify the alternatives you did not choose.

Questions & practice

Explain a complex algorithm you have implemented in a past project.

Medium · Technical / Domain Questions

Approach

Pick an algorithm you personally designed or tuned, such as an A* planner, an extended Kalman filter, ICP scan matching or a scheduler, and open with the problem it solved and the constraint that made a library call insufficient (latency budget, memory, accuracy).
Explain the core idea through its invariant or update step, for example 'the open set is a min-heap keyed on g + h, and with a consistent heuristic a popped node is never reopened', then state the time and space complexity in terms of the real input sizes.
Name the alternatives you rejected and the deciding property: optimality versus speed, numerical stability, worst-case versus average behaviour, or ease of testing.
Show how you verified it: comparison against a brute-force or reference implementation on small cases, edge-case unit tests, and a measured before/after number on real data.
Close with what broke in production or on hardware and what you changed, so the answer shows ownership beyond the textbook version.

Follow-up

What input makes it hit its worst case, and how often did that happen on real data?
If you rewrote it today, what would you change first and why?
How did you test it for numerical or timing problems, not just logical correctness?

Write a function to detect and classify objects in an image.

Medium · Coding / Algorithms

Approach

Clarify the scope before coding: classical computer vision or a pretrained detector, the input format (for example an H x W x 3 uint8 array and its channel order), the set of classes, and the output, such as a list of (bounding box, label, score).
For a classical version: segment by colour or intensity threshold, find connected components with BFS or union-find in O(H x W), compute a bounding box and features (area, aspect ratio, mean colour) per component, then classify with simple rules or a small classifier. Discard components below a minimum area to remove noise.
For a model-based version: preprocess to match training (resize, normalise, channel order), run the detector, decode boxes, filter by score, then apply non-maximum suppression. Sort by score, keep the top box, drop the rest whose IoU with it exceeds a threshold, and repeat (O(n^2) worst case for n boxes, usually per class).
Write IoU correctly: intersection width and height are clamped at zero, and IoU = intersection / (area A + area B - intersection). Be explicit about whether box coordinates are inclusive or exclusive.
Cover the edge cases: an empty image or no detections, touching objects that merge into one component, boxes clipped at the image border, and overlapping objects of the same class that NMS might wrongly suppress.

Follow-up

Implement IoU and NMS from scratch and test them on overlapping and non-overlapping boxes.
How would you make this run within a real-time frame budget on embedded hardware?
Two objects of the same class overlap heavily, and NMS removes one of them. How do you handle that?

How would you implement a pathfinding algorithm for a robot navigating through a maze?

Medium · Coding / Algorithms

Approach

Model the maze as a graph: grid cells are nodes and free neighbours are edges. Clarify 4- or 8-connectivity, whether moves have different costs, and the robot's footprint (inflate obstacles so a point-robot path is valid for the real robot).
For uniform costs, BFS gives the shortest path in O(R x C) time and space. For weighted costs, use Dijkstra with a binary heap, O(E log V). A* adds a heuristic: Manhattan distance is admissible on a 4-connected unit grid, octile distance on an 8-connected grid with diagonal cost sqrt(2), and with a consistent heuristic no node needs reopening.
Implementation details: a visited or closed set, a parent map to rebuild the path by walking back from the goal, and a tie-break on the priority queue. On 8-connected grids, prevent diagonal moves that cut a blocked corner.
Edge cases: start equals goal, start or goal is blocked, the goal is unreachable (return an empty result rather than looping), and very large maps where memory for the open set matters.
Connect it to a real robot: smooth the grid path, replan incrementally with D* Lite when new obstacles appear, and use hybrid A* or a state lattice when the robot has a turning radius or heading constraints.

Follow-up

A new obstacle appears on the path halfway through. How do you replan without starting from scratch?
The map is too large for full A* in memory or time. What do you change?
The robot cannot turn in place. How does the search change?

Keep soft-deleted accounts from blocking re-registration

Easy · soft delete · unique constraints · engine differences

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?

Stop tag and share joins from fanning out a page

Medium · join fan-out · semi-joins · many-to-many

resource_tag is (resource_id, tag_id) with PK (resource_id, tag_id); resource_share is (resource_id, shared_with_user_id, permission). The tagged-and-shared listing inner-joins resource to both, filters tenant_id, tag_id = ANY($2) and shared_with_user_id = $3, orders by updated_at DESC and takes 50. Pages come back with fewer than 50 distinct resources and the total in the header is far too high. Explain the row multiplication, rewrite both the page query and the count query so each is correct, and name the index each one needs. PostgreSQL 16.

Approach

Do the arithmetic against the predicates that are actually there. An inner join emits one row per matching child row, and both joins are filtered: tag_id = ANY($2) admits only the requested tags, shared_with_user_id = $3 admits one user's share rows. So a resource holding three of the requested tags and shared with $3 once yields three rows, not one — the multiplier is its count of matching tags times its share rows for that single user, and that second factor is 1 unless the table admits duplicate (resource_id, shared_with_user_id) pairs. LIMIT 50 then limits rows rather than resources, and COUNT(*) counts pairs — the header is the product, not the population.
Reject DISTINCT as the fix. It deduplicates after the product has been built, so the planner must materialise and sort the fanned-out set before the LIMIT can apply, and it leaves any SUM or AVG in the same select list wrong.
Rewrite both filters as semi-joins, keeping resource as the only row source: AND EXISTS (SELECT 1 FROM resource_tag rt WHERE rt.resource_id = r.resource_id AND rt.tag_id = ANY($2)) and the same shape against resource_share. A semi-join stops at the first match per resource and preserves the driving index order, so ORDER BY updated_at DESC, resource_id DESC LIMIT 50 still stops after 50 rows.
Count with the same predicates and no join at all: SELECT count(*) FROM resource r WHERE r.tenant_id = $1 AND r.status = 'active' AND EXISTS (...) AND EXISTS (...). Nothing multiplies a resource, so the number is the population.

Follow-up

The filter changes from 'any of these tags' to 'all of these tags'. Rewrite it and state what it costs relative to the ANY form.
A resource can be shared with the same user twice under different permissions. Does your count change, and should it?

What is your understanding of SLAM (Simultaneous Localization and Mapping)?

Medium · Technical / Domain Questions

Approach

Define the problem: the robot has to estimate its own pose and a map of the environment together, because a good pose needs a map and a good map needs known poses. Errors in odometry accumulate as drift unless they are corrected.
Split the system into a front end (feature extraction or scan matching such as ICP, data association, odometry from lidar, camera or IMU) and a back end that estimates the poses and map from those constraints.
Compare back ends. EKF-SLAM keeps poses and landmarks in one state vector with a dense covariance, so each update costs O(n^2) in the number of landmarks. Particle-filter methods such as FastSLAM factor the problem per particle. Graph-based SLAM treats poses as nodes and measurements as edges, and solves sparse nonlinear least squares with Gauss-Newton or Levenberg-Marquardt (libraries such as g2o, GTSAM or Ceres).
Explain loop closure: recognising a revisited place adds a constraint that spreads the correction back along the trajectory. A false loop closure can corrupt the map, so use geometric verification and robust cost functions.
Cover the sensor trade-offs and failure modes: monocular cameras cannot recover absolute scale, IMU fusion (visual-inertial odometry) helps with fast motion, lidar struggles in featureless corridors, and moving people break the static-world assumption.

Follow-up

Why does drift grow without loop closure, and how does a pose graph spread a loop-closure correction?
How would you keep moving people and objects from corrupting the map?
When would you choose a filter-based approach over graph optimisation?

Design a system for a robot to navigate a dynamic environment. What factors would you consider?

Medium · System Design / Architecture

Approach

Fix the requirements first: indoor or outdoor, the speed of the robot and of the people or objects around it, its sensors, its onboard compute, and the safety requirement (minimum clearance, maximum speed near people).
Lay out the pipeline: localisation against a map, perception that detects and tracks moving obstacles with velocity estimates (for example a Kalman filter per track), a layered costmap (a static map plus a dynamic layer with inflation for the robot footprint), a global planner (A* or D* Lite on the grid), and a local planner or MPC that replans at a higher rate using predicted obstacle trajectories.
State the timing trade-off: the global plan can be slow and coarse, but the local loop must react within the stopping distance at current speed, so give it a latency budget and keep it independent of slow perception updates. If the platform is legged, the local plan must also produce feasible footsteps or body velocities.
Design for uncertainty and failure: inflate obstacles by tracking uncertainty, fall back to slowing or stopping when localisation confidence drops or a sensor goes silent, use recovery behaviours for local minima, and keep an emergency stop path that does not depend on the planner.
Explain how you would validate it: simulation with scripted pedestrians, replay of recorded logs, and metrics such as collisions, minimum clearance, time to goal and how often recovery behaviours fire.

Follow-up

A crowd of people moves unpredictably across the planned path. What does the system do?
Localisation confidence suddenly drops in the middle of a task. How should the robot behave?
Which parts of this system run at which rates, and what happens if perception falls behind?

How would you approach designing a modular software architecture for a robotic application?

Medium · System Design / Architecture

Approach

Decompose by responsibility and rate: hardware drivers behind a hardware abstraction layer, state estimation, perception, planning, control, and a task or behaviour layer on top. Each module owns one job and exposes typed message interfaces.
Keep the hard real-time control loop separate from non-real-time work. Run it in its own thread or process with fixed priority and no allocation or blocking I/O, and let perception and planning feed it setpoints asynchronously.
Choose the communication model on purpose. Publish-subscribe middleware (for example ROS 2 over DDS) gives loose coupling, recording and tooling, but every process boundary adds serialisation and latency. Putting modules in one process (ROS 2 components support intra-process transport) cuts that cost but loses fault isolation.
Make the hardware abstraction layer the seam between simulation and the real robot, so the same planning and control code runs against a simulator, log replay or hardware. Version the message schemas so modules can change independently.
Plan for faults: heartbeats and watchdogs on each module, lifecycle states (configure, activate, shut down), a defined degraded mode, and per-module tests driven by recorded inputs.

Follow-up

Where would you draw process boundaries, and what does each boundary cost you in latency?
How would you add a new depth sensor without touching the planner?
A perception module crashes while the robot is moving. What should happen next?

Discuss the trade-offs between different communication protocols in robotics.

Medium · System Design / Architecture

Approach

Frame the trade-off with a few properties: latency and jitter (determinism), bandwidth, delivery guarantees, topology and discovery, and tooling. Then match each link in the robot to the properties it needs.
Transport layer: TCP gives ordered, reliable delivery but has head-of-line blocking and retransmission delay. UDP gives low latency with no delivery guarantee, which suits high-rate sensor streams where only the latest value matters.
Middleware: ROS 1 used a central master and mostly TCP. ROS 2 runs over DDS, usually on UDP, with per-topic QoS settings (reliable or best-effort, history depth, durability). Shared memory or zero-copy transport suits large images and point clouds on the same host. gRPC, ZeroMQ or MQTT suit fleet and cloud links.
Fieldbuses for actuators and embedded boards: classic CAN tops out at 1 Mbit/s with 8-byte frames and arbitrates by message ID, so high-priority messages win deterministically. CAN FD extends the payload to 64 bytes with a faster data phase. EtherCAT gives Ethernet bandwidth with sub-millisecond cycles and distributed clocks for synchronised motor drives. UART, SPI and I2C serve short on-board sensor links.
Give a concrete mapping and its cost: a deterministic fieldbus for the joint control loop, best-effort pub-sub for camera frames, reliable delivery for commands and state changes, and a store-and-forward link for telemetry over unreliable Wi-Fi.

Follow-up

Which protocol would you use for a 1 kHz joint control loop, and why not plain TCP?
Camera streams are saturating the network and delaying control messages. What do you change?
How do you keep a fleet-management link usable when Wi-Fi drops for several seconds?

Outline your thought process for improving a robotic system’s accuracy in perception tasks.

Medium · Problem-Solving / Case Studies

Approach

Define accuracy for the task before touching the model: precision and recall at a fixed IoU, mAP, or pose error in centimetres and degrees. Decide which error costs more operationally; a missed person and a false obstacle are not equally bad.
Build an evaluation set that reflects field conditions and slice it by lighting, distance, occlusion, motion and object type, so you can see where the errors are concentrated instead of tracking one average number.
Do error analysis on the failures: bucket them into label noise, under-represented conditions, small or distant objects, or confusable classes, and fix the largest bucket first (relabelling, targeted data collection, augmentation, hard-negative mining).
Look past the model at system-level gains: better sensor placement or calibration, fusing depth with RGB, tracking and temporal filtering across frames, or moving the robot to get a better view before committing to a decision.
Respect the robot's compute and latency budget: a larger model or higher input resolution may raise accuracy but miss the frame deadline. Validate on held-out data and log replay before deploying, and keep a regression suite.

Follow-up

Accuracy improved, but inference now exceeds the latency budget on the robot. What are your options?
How do you know your evaluation set reflects real deployment conditions?
How would you choose the operating point between precision and recall for this task?

How do you approach debugging a software issue in a robotic system?

Medium · Technical / Domain Questions

Approach

Pin the symptom down first: which behaviour, how often, on which robot or build, in simulation or only on hardware. Then make it reproducible by recording sensor and command logs (a rosbag if the stack uses ROS) so the failing run can be replayed offline.
Walk the data path layer by layer: sensor and driver output, timestamps and clock synchronisation, coordinate-frame transforms and calibration, then estimation, planning and control. At each boundary, check whether the data going in is still correct.
Bisect with the replayed log: run the same input through the last known-good and the current software version, or swap one module for a known-good one, so each test rules out half the candidates.
Check timing-specific causes that only show up on a robot: missed control deadlines, priority inversion, race conditions between callbacks, queue overflow dropping messages. Use lightweight tracing, because heavy logging can change the timing and hide the bug.
Reproduce safely (simulation, test stand or a tethered robot) before testing a fix on hardware, and finish by adding a regression test built from the recorded log.

Follow-up

The bug appears on the physical robot but never in simulation. What differences do you check first?
The failure happens about once an hour. How do you capture enough information to diagnose it?
How do you add instrumentation without changing the timing behaviour you are trying to observe?

Given a scenario where a robot fails to recognize an object, how would you troubleshoot the issue?

Medium · Problem-Solving / Case Studies

Approach

Classify the failure first: no detection at all, a wrong class, a correct detection below the confidence threshold, or a correct detection that is lost downstream (tracking, frame transform, the consumer). Each one points to a different part of the pipeline.
Check the input before the model: is the camera publishing at the expected rate, are exposure, focus and white balance sane, are timestamps and the camera-to-robot transform correct, and is the calibration current. Save the exact frames where the failure happens.
Run the saved frames offline through the model. If the model detects the object offline but not on the robot, the bug is in the pipeline: preprocessing mismatch (BGR versus RGB, normalisation, resize or aspect-ratio handling), a different model version, or timing. If it also fails offline, it is a model problem.
For model failures, compare the failing images with the training distribution (lighting, distance and scale, occlusion, viewpoint, a new object variant), and check the score threshold and non-maximum-suppression settings before retraining.
Fix it at the right layer (collect and label data for the failing condition, adjust thresholds, add temporal filtering across frames), then add the failing cases to a regression set so the fix is measured and stays fixed.

Follow-up

The object is recognised reliably in the lab but not at a deployment site. What do you compare?
Recognition fails only while the robot is moving. Which causes do you suspect?
How do you stop this failure from coming back after the next model update?

Suggested practice checklist

The plan follows the reported loop: coding exercise first, then the technical and behavioral topics from the multiple interviews, and the final presentation last. Each day ends with something you can produce or say aloud.

Day 1 — Map the loop and pick your stack

List the four reported rounds and mark what you still have to ask the recruiter, in particular whether the coding exercise is live or a take-home.
Choose your coding language from Python, C++ or Java, and write a short list of robotics projects, sensors, middleware (ROS if you know it) and real-time work you can speak about.
Write your two-minute career walkthrough and the motivation answer for working in robotics.

Deliverable: A one-page loop map, a language decision, a project inventory and written drafts of the walkthrough and motivation answer.

Day 2 — Grid pathfinding in code

Implement BFS and A* on a grid with obstacles, in your chosen language, with tests for blocked start, blocked goal and no path.
Add weighted cells and a replanning step for when an obstacle appears mid-route.
Write down the complexity of each version and when you would pick one over the other.

Deliverable: Working, tested pathfinding code with a short note on complexity and replanning.

Day 3 — Perception: build a detector and debug a failure

Write a function that takes an image, finds objects and returns labelled boxes, using a library for the model but your own code for preprocessing, thresholding and non-maximum suppression.
Write a troubleshooting checklist for a robot that fails to recognize an object, ordered from sensor and calibration through to the model.
Outline how you would measure and improve perception accuracy: a labelled validation set, per-class error analysis, targeted data and a regression test.

Deliverable: A detect-and-classify function with tests, plus a written troubleshooting order and an accuracy-improvement plan.

Day 4 — SLAM, navigation and architecture

Explain SLAM aloud in three levels: one sentence, a two-minute version and a diagram of the front end, back end and loop closure.
Sketch a navigation system for a dynamic environment, covering perception, mapping, global and local planning, replanning and a safe stop.
Draw a modular architecture for a robotic application, then compare two communication options on latency, reliability and coupling.

Deliverable: Three diagrams (SLAM, navigation, modular architecture) and a one-page protocol trade-off table.

Day 5 — Past work and debugging stories

Pick the complex algorithm you will explain and write its problem, alternatives considered, complexity and the result.
Write your debugging sequence for a robotic system: reproduce, isolate hardware from software, check logs and timestamps, bisect, then confirm the fix.
Collect the numbers for one real-time story and one performance optimization story.

Deliverable: An algorithm explanation, a debugging checklist and two metric-backed story outlines.

Day 6 — Leadership and conflict stories

Write the deadline-leadership story in STAR form, including what you cut and how you communicated risk.
Write the technical-disagreement story with the criteria, the evidence and the outcome.
Say both aloud to another person and trim each until the decision, not the background, takes most of the time.

Deliverable: Two rehearsed STAR stories with the decision points highlighted.

Day 7 — Build and rehearse the final presentation

Assemble a presentation of your coding solution or a past project: problem, constraints, design, results, limitations.
Run it aloud for someone outside your specialty and fix every point where they ask for a definition.
Do one full mock pass: motivation answer, a design question and the presentation, noting weak spots to patch.

Deliverable: A finished presentation plus a list of the weakest answers from the mock pass.

Real-time, performance and teamwork stories

The behavioral parts of the loop are reported to sit within the Multiple Interviews stage, alongside technical problem-solving and discussions of past projects. For this role they come down to real-time and performance experience, leading work against a deadline, handling technical disagreements, and why robotics. Prepare stories where you made the decision and can give numbers, because the same stories will feed the project discussion.

Discuss your experience with real-time systems and the challenges they present.

Medium · Technical / Domain Questions

Approach

Use a project where you owned a timing constraint, such as a control loop, sensor-processing pipeline or message handler that had to finish within a fixed period. State the period and the consequence of missing it, and separate hard deadlines (a miss is a failure) from soft ones (a miss degrades quality).
Name the real challenges you handled: jitter, priority inversion, allocation or locking inside the critical loop, blocking I/O, and interrupts or other threads competing for the same core. Say which you actually hit, rather than listing all of them.
Describe how you measured: worst-case and tail latency from timestamps or tracing, not the average, and under realistic load. A story that shows a missed deadline you found with measurement is stronger than one claiming it never happened.
Give your fix and its cost, for example moving work out of the loop, preallocating buffers, replacing a mutex with a lock-free queue or a bounded handoff, raising thread priority or pinning cores, with the trade-off in complexity or throughput. End with the result and what you would redo.
If you lack hard real-time experience, use the closest case honestly (a latency-sensitive service, an audio or video pipeline) and say how the constraints differ.

Follow-up

What was your worst-case latency versus the average, and how did you find it?
How do you avoid priority inversion when a high-priority task needs a resource held by a low-priority one?
What would you do if the deadline is occasionally missed and the robot cannot simply stop?

Can you describe a time you optimized a codebase for performance?

Medium · Technical / Domain Questions

Approach

Open with the problem in one or two sentences: what was slow, for whom, and the target (a latency, throughput, memory or startup figure). If you cannot put a number on it, pick another story.
Show measure-first discipline: you profiled (sampling profiler, flame graph, benchmark harness, tracing) and found the hot spot rather than guessing. State the baseline you recorded before changing anything.
Explain the change by category and why it applied: a better algorithm or data structure, removing repeated work, cutting allocations or copies, improving cache locality, batching, or parallelism. Say what you rejected.
Prove it: before and after numbers on the same workload, a correctness check (tests or output comparison), and a guard such as a benchmark in CI so the gain is not lost.
Mention the cost: added complexity, a readability trade-off or a risk you contained, and how you reviewed it with teammates.

Follow-up

How did you know that function was the bottleneck and not just the most visible one?
Did the optimization change any behavior, and how did you verify it did not?
When did you decide the code was fast enough to stop?

Describe a situation where you had to lead a project under tight deadlines.

Medium · Behavioral / Leadership

Approach

Choose a project where you were the person responsible for the outcome, with a fixed external deadline and real constraints. Say in one sentence what was at stake and what your role was.
Show how you planned: breaking the work into milestones, identifying the riskiest piece first, and agreeing with stakeholders what was in and out of scope. Cutting scope deliberately is a better story than working harder.
Show how you led other people: assigning work to strengths, unblocking, short check-ins, and how you communicated bad news early. Use I for your actions and name what teammates did.
Describe one hard decision made under pressure (a shortcut taken, a feature dropped, a risk accepted) and how you limited the damage, for example with tests or a rollback plan.
Close with the result against the deadline and what you changed afterward. The mistake that sinks this story is a hero narrative of long hours with no decisions or planning in it.

Follow-up

What did you decide not to do, and who agreed to that?
How did you find out the schedule was at risk, and when did you tell people?
What technical debt did you leave behind, and did you pay it down?

How do you handle conflict within a team, especially when it involves technical disagreements?

Medium · Behavioral / Leadership

Approach

Pick a real technical disagreement, such as architecture, a library or protocol choice, or a testing approach, where both positions were reasonable. Present the other person's view fairly and in its strongest form.
Explain how you moved from opinion to evidence: agreeing on the criteria first (latency, maintainability, safety, schedule), then a prototype, benchmark, spike or review of failure cases to compare options.
Show your communication: you listened and asked questions, kept the discussion on the problem rather than the person, and involved a third person or lead only when the two of you were stuck.
State the outcome, including cases where you lost. Committing to a decision you disagreed with and helping it succeed is a good answer; so is changing your mind and saying why.
Finish with the relationship afterward and what you do differently now. The mistake that sinks it is a story where the other person was simply wrong.

Follow-up

What evidence would have changed your mind?
What if the disagreement was with your manager or with a hardware engineer who owned the constraint?
How did you make sure the decision was recorded and not reopened?

What motivates you to work in robotics, and how do you see your career evolving in this field?

Medium · Behavioral / Leadership

Approach

Answer the first half with specifics: the project, experience or problem that pulled you toward robotics, and what about it holds your interest, such as software that meets physical sensors and actuators, where bugs show up as real motion.
Link it to the areas candidates report for this role (perception, locomotion, human-robot collaboration) and to work you have done or built on your own. Show that you know what you would be doing day to day, rather than that you admire the field.
For career direction, describe a realistic path: skills you want to deepen (for example perception, controls, real-time software or systems architecture), and whether you see yourself growing as an individual contributor or leading people. Tie each to something you would learn in this role.
Be honest about gaps. If you come from non-robotics software, say what you are doing to close the gap, such as projects in ROS or a simulator.
Keep it short and forward-looking; the mistake that sinks it is a generic passion statement that could be said for any company.

Follow-up

What robotics project have you built or studied closely, and what did you learn from it?
Which part of the stack do you want to grow into, and what is your first step?
What would make you decide this was not the right role?