Start with the domain contract. Humanoid context points toward robotics; name the robot/task identity, authorization boundary and durable evidence before choosing infrastructure.
The official source provides company or product context. It does not prove a fixed employer loop or that the exercises below were asked in an interview.
Model the state before the happy path. Treat robot events as potentially duplicated, delayed or reordered. State which version is authoritative and who can change it.
Make recovery observable. Separate a rejected operation from an unknown result, preserve correlation IDs and explain which retries are safe.
Explore your preparation priorities
Choose a focus to see how to prepare.
Define robot identity
Contract: identify the durable robot/task state and proof.
YOUR PREPARATION- Name the stable identity and authorization boundary.
- Write the success and replay invariants.
PracHub practice map for Humanoid. Select a checkpoint to connect robot/task identity, robot state and recovery evidence to a practice prompt.
Define robot identity
editorialWrite the contract for a robot/task operation: stable identity, authorization, version and durable confirmation.
What to demonstrate
- Domain modeling
- Clear assumptions
How to prepare
- Name the business entity and its stable key.
- List the proof a retry must preserve.
Protect robot state
editorialModel concurrent motion events as explicit transitions so a stale or duplicated event cannot silently replace current state.
What to demonstrate
- Concurrency reasoning
- Failure boundaries
How to prepare
- Trace two actors from the same version.
- Choose the atomic comparison and update boundary.
Explain robot recovery
editorialKeep enough evidence to distinguish a robot timeout from rejection, duplicate acceptance or an already-completed operation.
What to demonstrate
- Operational judgment
- User-safe recovery
How to prepare
- Write the retry and reconciliation path.
- Name the metric or log that proves each outcome.
PracHub editorial advice for the preparation topics above.
Follow the state, not just the happy path
Choose a scenario to trace what changes.
The expected version for this robot still matches the authoritative state.
- 01Start robot operationAccept the robot request with an operation identity.
- 02Check current versionCompare the expected version with the authoritative state.
- 03Commit robot statePersist the new robot state and return durable confirmation.
Commit one robot version and return durable confirmation.
Compare three outcomes for Humanoid practice: a confirmed robot write, a version conflict and a lost response.
Choosing infrastructure before defining identity and state
Name the robot/task key, tenant scope, versions and durable confirmation before selecting queues, caches or databases.
Treating a timeout as proof of failure
Model an unknown robot result, look up the operation and reuse the same identity.
Joining multiple one-to-many tables at detail grain
Aggregate each robot input to the requested output grain and assert row-count invariants.
Quoting an unverified interview sequence
Use the exact recruiter instructions and role posting; describe this guide as preparation rather than employer-process evidence.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Merge operation windows
Given half-open operation windows [start, end), merge overlapping or touching windows. Reject an end before its start and return a new sorted list.
Approach
- Sort by start and scan while keeping one current window.
- Merge when the next start is at or before the current end; validate every boundary.
Worked solution 35 min
- Sort the windows.
- Validate each boundary during the scan.
- Merge overlap and exact touching; otherwise start a new result window.
def merge_windows(windows):
merged = []
for start, end in sorted(windows):
if end < start:
raise ValueError("end before start")
if not merged or start > merged[-1][1]:
merged.append([start, end])
else:
merged[-1][1] = max(merged[-1][1], end)
return [tuple(item) for item in merged]
Scroll sideways to view long lines.
Follow-up
- How would an inclusive end change the touching-window rule?
Apply motion events exactly once
Process robot/task events with an operation ID, observed time and version. Ignore exact replays, reject an ID reused with different content and reject a stale version.
Approach
- Deduplicate by the full business key and event ID.
- Make duplicate detection and state advancement one atomic decision.
Follow-up
- What evidence should remain after the replay-retention period?
Count recent robot signals
Implement add(timestamp) and count(now) for robot signals in (now - 10, now]. Timestamps are nondecreasing, equal timestamps are distinct and the clock can advance without a new signal.
Which events still count?
The left boundary is excluded; the right boundary is included. Drag past an event to see it enter, then expire 10 seconds later.
See the event values
- At 0s: +1 — expired
- At 5s: +1 — in window
- At 10s: +1 — in window
- At 14s: +1 — not arrived
- At 19s: +1 — not arrived
Synthetic robot signals at 0, 5, 10, 14 and 19 seconds. Drag the clock: the interval is (now - 10, now], so the lower boundary is excluded.
Approach
- Keep timestamps in a deque and evict values at or before now - 10.
- Each timestamp enters and leaves once, giving amortized O(1) updates.
Follow-up
- How would you bound memory for inactive keys?
Find latest robot state
Given robot_events(tenant, robot_id, event_id, occurred_at, state), return the latest event for every robot in tenant a. Use event_id as the deterministic tiebreaker.
Approach
- Filter to the tenant before ranking.
- Partition by the full business key and order by event time plus a unique tiebreaker.
Worked solution 35 min
- Filter to tenant a before ranking.
- Partition by the full entity key.
- Order descending by time and event ID, then keep row one.
WITH ranked AS (
SELECT tenant, robot_id, state,
ROW_NUMBER() OVER (
PARTITION BY tenant, robot_id
ORDER BY occurred_at DESC, event_id DESC
) AS rn
FROM robot_events
WHERE tenant = 'a'
)
SELECT robot_id, state FROM ranked WHERE rn = 1 ORDER BY robot_id;
Scroll sideways to view long lines.
Follow-up
- When should arrival time replace event time for an operational view?
Aggregate robot evidence without row multiplication
Join robots, motion event details and reviewer or operator notes. Return one row per robot with counts and latest note, including entities with no activity.
Approach
- Aggregate each one-to-many input to the requested grain before joining.
- Use the full tenant-scoped key and preserve inactive entities with a left join.
Follow-up
- Which invariant would detect silent many-to-many multiplication?
Design an idempotent robot workflow
Design robot/task creation through validation, durable state and downstream effects. Cover authorization, duplicate requests, retries, status reads and reconciliation.
Approach
- Name the authoritative state owner and operation identity first.
- Persist state and outbound work together, then make consumers replay-safe.
Worked solution 35 min
- Write the identity and state invariants.
- Trace success, exact replay, conflict and lost response.
- Add authorization, observability and a reconciliation owner.
Follow-up
- Which failure needs reconciliation rather than automatic retry?
Design a robotics robot pipeline
Ingest motion events from many producers, handle late data and expose a trustworthy view of robot behavior and sensor state. Cover partitioning, watermarks, backpressure and replay.
Approach
- Partition by the entity whose order matters.
- Define watermarks, retry budgets and a side-effect-free rebuild path.
Follow-up
- How would you rebuild a derived view without repeating an external effect?
Stop stale robot state from winning
A slow motion event response arrives after a newer robot state is accepted and regresses the UI or downstream record. Reproduce the race and specify server and client guards.
Approach
- Control response order in a deterministic test.
- Guard the authoritative write atomically and suppress stale generations at the caller.
Worked solution 35 min
- Build a test that controls response order.
- Log operation identity, expected version and resulting version.
- Add atomic server guards and stale-result suppression at the caller.
Follow-up
- What telemetry distinguishes a harmless stale response from state corruption?
A seven-session PracHub practice plan with one reviewable artifact per session. Adjust the pace to your experience and interview date; it is not a company hiring timeline.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Choose the role boundary
- Read the exact opening.
- List the product, service and operational responsibilities it names.
Deliverable: A one-page role-scope note
02Practice the domain boundary
- Run the robot window solution.
- Add touching, contained, empty and invalid operation windows cases.
Deliverable: A tested boundary contract
Practice prompt ↗Worked solution ↗03Protect event identity
- Model exact replay and conflicting reuse for motion events.
- State the atomic write boundary.
Deliverable: An idempotency table and invariant list
Practice prompt ↗Practice prompt ↗04Verify SQL grain
- Run the latest robot query.
- Draw the row grain before the aggregate join.
Deliverable: SQL results plus cardinality notes
Practice prompt ↗Practice prompt ↗Worked solution ↗05Design recovery first
- Trace success, conflict and lost robot response.
- Name the reconciliation owner.
Deliverable: A failure-path sequence diagram
Practice prompt ↗Practice prompt ↗Worked solution ↗06Reproduce stale state
- Resolve two motion event responses in reverse order.
- Add server and client generation checks.
Deliverable: A deterministic regression test
Practice prompt ↗Worked solution ↗07Rehearse evidence-based stories
- Practice two real examples aloud.
- Remove team-level claims you cannot attribute to your action.
Deliverable: Two concise STAR notes with observable evidence
Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Use real examples. Name your responsibility, the evidence available at the time, the trade-off and what changed after your decision.
Explain a safety trade-off
Describe a real project where you balanced safety, delivery speed and operational risk.
Approach
- Name your individual responsibility and the evidence available then.
- Explain the trade-off, action and observable result.
Follow-up
- What would you change with today’s information?
Communicate during a robot incident
Tell a story about a robot or production incident where symptoms crossed team or system boundaries.
Approach
- Separate confirmed impact from hypotheses.
- Describe how you kept stakeholders aligned while the investigation changed.
Follow-up
- Which signal would you add after the incident?
Protect robot behavior and sensor state quality
Describe a time you added a test, review or control that prevented a costly robot/task error.
Approach
- Explain the failure mode and why the guard belongs at that boundary.
- Show the result with a metric, escaped defect or reduced recovery time.
Follow-up
- How would you keep the control from becoming a false-positive burden?
- 01
Bring one result you improved and one decision you changed after seeing evidence.
Are these verified Humanoid interview questions?
No. They are PracHub editorial exercises informed by official Humanoid context and technical references. Team requirements and formats vary.
Humanoid — official company context ↗Which language should I use for the coding practice?
Use a language accepted for your interview and explain its collection, numeric and error-handling behavior. The Python examples emphasize the contract, not a required company stack.
Python — collections.deque ↗Is this Humanoid interview schedule?
No. It is a seven-session PracHub preparation checklist. Follow the timing and format in your invitation.
Sources & methodology 4 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01Humanoid — official company context ↗
Official company context only; it does not establish a universal interview sequence.
official · Accessed 2026-09-20 - 02PostgreSQL — Window functions ↗
Technical reference for latest-state SQL. Runnable fixtures use SQLite.
official · Accessed 2026-09-20 - 03Python — collections.deque ↗
Technical reference for the bounded event-window exercise.
official · Accessed 2026-09-20 - 04PracHub — Software Engineer practice ↗
Cross-company practice; not evidence of company interview questions.
platform · Accessed 2026-09-20
Explore related engineering environments and compare the preparation focus.
Verizon Software Engineer Interview Questions & Guide 2026
high-volume provisioning and observable network state
Thales Software Engineer Interview Questions & Guide 2026
high-assurance embedded and secure systems
TE Connectivity Software Engineer Interview Questions & Guide 2026
hardware-software integration and production traceability
Swedish Space Software Engineer Interview Questions & Guide 2026
telemetry ingestion, pass scheduling and mission reliability