A plan is useful only when its assumptions are visible. A supplier delay can affect several dependent activities. Practise explaining which inputs changed, what needs recomputation and why a result belongs to a particular scenario revision.
Kinaxis describes Maestro as a supply chain planning and decisioning platform built around concurrent planning. That product description motivates these preparation topics; it does not reveal the company’s internal algorithms or establish a hiring sequence.
Separate planning from execution. A hypothetical scenario can explore a change without authorizing a real order. In the examples, publishing a result means making a computed scenario visible, not triggering a purchase. State this boundary before discussing retries or user actions.
Choose a small, testable model. Use a directed acyclic dependency graph, integer quantities and immutable scenario revisions. Real supply chains can involve cycles, uncertain lead times and optimization objectives. Explain where the simplified model stops rather than describing a toy calculation as a complete planning engine.
Define the scenario data
editorialGive a scenario immutable inputs and a revision. Distinguish an item identifier from a tenant-scoped item identity and document what a missing demand row means.
What to demonstrate
- Keep units, scope and revision explicit.
- Reject inconsistent inputs before computing results.
How to prepare
- Create a small demand-and-stock fixture.
- Add an item with no demand and the same item ID in another tenant.
Explain the dependency algorithm
editorialDraw a graph before reaching for an optimization technique. A topological order is enough for one simple acyclic propagation exercise, but it does not solve every planning problem.
What to demonstrate
- State an invariant and complexity bound.
- Detect invalid cycles rather than returning a partial plan.
How to prepare
- Implement the dependency-order exercise.
- Compare a chain, a diamond and a disconnected task.
Publish a result from one consistent revision
editorialA long calculation can finish after a planner changes the inputs. Identify the scenario revision that produced the result and decide whether it is still eligible to become current.
What to demonstrate
- Prevent stale work from replacing a newer result.
- Keep performance comparisons tied to the same inputs and output meaning.
How to prepare
- Trace an old worker finishing after a replacement.
- Prepare a story where measurement changed a performance decision.
PracHub editorial advice for the preparation topics above.
Which calculation result can become current?
Choose a scenario to trace what changes.
The current owner completes the job.
- 01QueuePersist the scenario revision and input manifest before a worker claims the job.
- 02Run with tokenAllocate a token that identifies this worker’s current ownership. Store calculated output under its attempt ID.
- 03Commit current tokenCompare the token and eligible input revision while atomically selecting the published result.
Publish the artifact only when the ownership token and intended input revision still match in the atomic commit.
PracHub calculation-worker model: compare a current worker, a late worker and a retry. A token identifies ownership of the result publication step; these are teaching scenarios, not Kinaxis infrastructure.
Returning a majority candidate without verification
Pair cancellation finds a candidate, not proof of a majority. Count it again when no majority is guaranteed.
Dropping tasks from a cyclic graph
A partial topological order is not a valid plan. Detect the unresolved cycle and expose a useful error.
Benchmarking different scenarios
Hold the inputs and output semantics constant. Record algorithm version, workload shape and correctness checks alongside timing.
Publishing results from stale work
Tie the atomic commit to the current token and input revision. A lease check performed earlier leaves a race.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Order dependent planning tasks
Given unique task IDs and directed prerequisite edges (before, after), return a valid execution order or reject a cycle. Reject unknown endpoints. Duplicate edges should not inflate indegrees.
Approach
- Deduplicate adjacency edges, initialize every task including isolated ones, and count incoming prerequisites.
- Process zero-indegree tasks with a queue and decrement each outgoing neighbor. If fewer than all tasks are produced, a cycle remains. This is O(V+E) time and space.
Worked solution 35 min
- Initialize every node so isolated tasks are retained.
- Increment indegree only when an edge is first inserted. Process tasks only after all prerequisites have been removed.
- Compare output length with node count. A shorter output is a cycle failure, not a partially successful plan.
from collections import deque
def task_order(tasks, edges):
if len(set(tasks)) != len(tasks):
raise ValueError("duplicate task")
adj = {x: [] for x in tasks}
degree = {x: 0 for x in tasks}
seen = set()
for a, b in edges:
if a not in adj or b not in adj:
raise ValueError("unknown endpoint")
if (a,b) not in seen:
seen.add((a,b)); adj[a].append(b); degree[b] += 1
ready = deque(x for x in tasks if degree[x] == 0)
result = []
while ready:
a = ready.popleft(); result.append(a)
for b in adj[a]:
degree[b] -= 1
if degree[b] == 0:
ready.append(b)
if len(result) != len(tasks):
raise ValueError("cycle")
return result
Scroll sideways to view long lines.
Follow-up
- How would you return only tasks affected by changing one input?
Detect a strict majority signal
Given a list of categorical supplier signals, return a value occurring more than half the time, or None. The input may be empty. Distinguish more than half from at least half.
Approach
- Use pair cancellation to find a candidate, then verify its actual count in a second pass.
- Explain why the candidate alone proves nothing if the input has no guaranteed majority. Test two different values in a two-element input.
Follow-up
- What changes if the threshold becomes one-third or the data is an unrepeatable stream?
Count recent planning input arrivals
Given nondecreasing integer timestamps, count events in (now − 10, now]. Each event counts once. The clock can advance without a new event; an event at the lower boundary has expired.
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 planning input arrivals at 0, 5, 10, 14 and 19 seconds, each with weight one. Drag the clock: at 10 seconds only 5 and 10 count; at 30 seconds none remain. The lower boundary is excluded.
Approach
- Keep a deque and remove timestamps at or before now − 10 before reporting a count. Equal timestamps represent distinct events unless a separate event ID says otherwise.
- Expose both add(time) and count(now). Reject a backward clock and document the O(k) retained-event memory cost. Each event is inserted and removed once, giving amortized O(1) updates.
Follow-up
- How would late arrivals, multiple producers or a per-customer limit change the contract?
Calculate shortage without mixing tenants
For each stock item in tenant a, return max(total demand − stock, 0). Stock has one row per tenant/item, demand has multiple nonnegative request rows, and absence of demand means zero.
Approach
- Aggregate demand by tenant and item before joining it to stock. Do not sum stock after a one-to-many join.
- Keep both tenant and item in the join, and preserve stock rows with no demand. State that this snapshot ignores reservations and future replenishment.
Worked solution 35 min
- Aggregate demand at the same tenant/item grain as stock.
- Join both key parts and convert missing demand to zero.
- The CASE expression reports shortage, not negative surplus. This exercise assumes one consistent snapshot.
CREATE TABLE stock (tenant TEXT, item TEXT, qty INTEGER, PRIMARY KEY(tenant,item));
CREATE TABLE demand (tenant TEXT, item TEXT, qty INTEGER);
INSERT INTO stock VALUES ('a','x',5),('a','y',10),('b','x',100);
INSERT INTO demand VALUES ('a','x',4),('a','x',4),('b','x',900);
WITH totals AS (SELECT tenant,item,SUM(qty) AS needed FROM demand GROUP BY tenant,item)
SELECT s.item,CASE WHEN COALESCE(d.needed,0)>s.qty THEN d.needed-s.qty ELSE 0 END
FROM stock s LEFT JOIN totals d ON d.tenant=s.tenant AND d.item=s.item
WHERE s.tenant='a' ORDER BY s.item;
Scroll sideways to view long lines.
Follow-up
- How would adding scenario revision to every key change the query?
Find the latest completed calculation per scenario
Given runs(tenant, scenario, input_revision, run_id, status, completed_at), select the latest completed run per scenario. Completion time and run ID form a deterministic order; failed runs cannot hide earlier completed results.
Approach
- Filter completed runs before ranking and partition by tenant and scenario.
- Distinguish the latest completed result from a result matching the current input revision. Label stale results instead of pretending the two queries are equivalent.
Follow-up
- Which result should a planner see while the current revision is still computing?
Design a reproducible scenario calculation
Accept a scenario revision, run a long calculation, and publish the result without mixing input revisions. A worker can crash or complete after losing its lease.
Approach
- Freeze the input manifest and calculation version before enqueueing. Give each attempt its own ID and artifacts.
- Publish through an atomic check of current ownership and intended revision. A late worker must not overwrite the result selected by a newer attempt.
Worked solution 35 min
- Freeze a manifest containing tenant, scenario revision, input versions and algorithm version.
- Claim an attempt with a monotonically increasing fencing token. Write results to an attempt-specific artifact path.
- Atomically publish only when the token is still current and the intended revision is eligible. Do not rely on a worker politely stopping after cancellation.
- Keep old results visible as explicitly older revisions while current computation is pending. Garbage-collect unselected artifacts after a safe retention period.
Follow-up
- How would you compare two algorithm versions fairly on the same scenario?
Recompute only affected planning outputs
Given a dependency graph and a changed input, design an incremental recomputation service. Results must identify which input revision they represent.
Approach
- Track dependencies and find the transitive affected subgraph. Reuse an output only when its dependency fingerprints match.
- Coalesce rapid changes, version queued work and define a full-recompute fallback. Measure invalidation cost as well as saved calculation time.
Follow-up
- How would an unknown dependency invalidate your correctness argument?
Reject a stale worker result
Worker A pauses. Its lease expires, B computes a newer result, and A resumes and overwrites it. Explain why cancellation or a separate pre-write lease check is insufficient.
Approach
- Construct a timeline with the pause immediately after A checks ownership. B can acquire the lease before A writes.
- Move the fencing token and revision comparison into the atomic result publication. Store attempt artifacts separately until publication succeeds.
Worked solution 35 min
- Record a timeline: A owns token one, A pauses, B receives token two, B publishes, A resumes.
- A separate ownership read can become stale before the write. Require the conditional publication itself to compare the token.
- Verify the failing commit affects zero rows and leaves the selected artifact unchanged. Keep the stale artifact unreferenced for cleanup.
Follow-up
- What cleanup policy removes abandoned artifacts without deleting the selected result?
A PracHub practice schedule with one outcome 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 done01Model one scenario
- Draw inputs, dependencies and result revisions.
- State which actions are hypothetical calculations.
Deliverable: A scenario contract
02Order dependencies
- Implement topological ordering.
- Test duplicates, a cycle and an isolated task.
Deliverable: A tested graph routine
Practice prompt ↗03Check shortage grain
- Run the stock-and-demand SQL.
- Add colliding tenant IDs and empty demand.
Deliverable: A verified shortage fixture
Practice prompt ↗04Trace one calculation
- Create an immutable manifest.
- Walk a worker failure and a new attempt.
Deliverable: A reproducible run design
Practice prompt ↗05Challenge stale ownership
- Resume an old worker after replacement.
- Identify the exact atomic check.
Deliverable: A failure timeline
Practice prompt ↗06Explain performance evidence
- Prepare one benchmark story.
- Name the correctness check and the workload limitation.
Deliverable: A defensible performance explanation
Practice prompt ↗07Rehearse the full model
- Explain the majority follow-up and dependency invalidation.
- Use the clock diagram to test stale input assumptions.
Deliverable: A focused practice review
Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Use a real project. Explain your responsibility, the decision you made, the evidence you used and what you would change.
Make a performance claim defensible
Describe a slow calculation or query you improved. Explain how you chose the workload and checked output equivalence.
Approach
- Name the assumption, your responsibility and the experiment or evidence you used.
- Describe the decision, limitations and follow-up. Keep your personal contribution separate from the whole team’s outcome.
Follow-up
- What new evidence would cause you to reverse that decision?
Resolve competing planning assumptions
Describe a technical disagreement caused by different assumptions about the same requirement.
Approach
- Name the assumption, your responsibility and the experiment or evidence you used.
- Describe the decision, limitations and follow-up. Keep your personal contribution separate from the whole team’s outcome.
Follow-up
- What new evidence would cause you to reverse that decision?
Reduce an ambiguous problem
Tell a story where you turned an underspecified request into a small, verifiable first result.
Approach
- Name the assumption, your responsibility and the experiment or evidence you used.
- Describe the decision, limitations and follow-up. Keep your personal contribution separate from the whole team’s outcome.
Follow-up
- What new evidence would cause you to reverse that decision?
- 01
Choose examples you can discuss without sharing confidential customer data.
Do I need to build a complete optimization solver?
These exercises focus on general software engineering: graphs, state, data and reproducibility. Optimization-heavy roles may require additional mathematics and algorithms; use the exact posting to determine that depth.
Are these verified company interview questions?
These are PracHub practice exercises informed by the supplied guide themes and official product context. They include original constraints and worked solutions; they are not an independently verified list of questions asked by the employer.
Why include SQL alongside coding and design?
SQL is supplemental practice for inspecting system state and checking invariants. Its inclusion does not mean every role has a SQL interview. Prioritize the skills in your exact opening.
How should I use the seven-day checklist?
Attempt each task before opening its solution. Save one artifact per session, such as a tested function, fixture or failure timeline. Repeat weak areas and adjust the pace instead of treating seven days as a readiness guarantee.
Sources & methodology 3 sources ↗
Official role evidence, timestamped platform data and clearly labeled preparation advice.
- 01Kinaxis — official engineering and product context ↗
Company context only; preparation recommendations are PracHub editorial advice.
official · Accessed 2026-09-20 - 02PostgreSQL — Window functions ↗
Technical reference for SQL reasoning. Runnable teaching fixtures below use SQLite.
official · Accessed 2026-09-20 - 03PracHub — 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.
ALICE Technologies Software Engineer Interview Questions & Guide 2026
Prepare for construction-optimization engineering by making project and task identity, scenario versioning, constraint feasibility, reproducible simulations and stakeholder explanations explicit.
Air Canada Software Engineer Interview Questions & Guide 2026
Prepare for airline engineering by making booking identity, flight state, safety-sensitive recovery and operational observability explicit.
TeamViewer Software Engineer Interview Questions & Guide 2026
Prepare for remote-session engineering by defining authorization, connection lifecycle, device state and safe recovery across unreliable networks.
Verizon Software Engineer Interview Questions & Guide 2026
high-volume provisioning and observable network state