Ajulia Executive Search Software Engineer Interview Guide

The 60-second brief

Candidates describe this Software Engineer role as building and maintaining software applications that support manufacturing processes and meet client needs. The reported day-to-day covers designing, writing and maintaining applications, reviewing teammates' code, taking part in sprint planning and retrospectives, and troubleshooting and resolving software issues together with product managers, QA and other engineering teams. The requirements candidates describe name Python, Java or C#, plus working experience with both SQL and NoSQL databases; cloud platforms such as AWS or Azure, DevOps tooling and some machine learning knowledge appear as extras rather than requirements.

This guide is for software engineers with roughly two to five years of experience (the range candidates report for this role) who are preparing for the Ajulia Executive Search loop. It covers the four reported stages, question-by-question approaches for the coding, concepts, debugging, design and behavioral questions candidates report, the manufacturing vocabulary that the reported topic areas point to, and a one-week plan that turns all of it into rehearsed answers.

Candidates report four stages over roughly three to five weeks: Initial Screening, Technical Interviews, Behavioral Interviews and Final Interviews, with the technical stage described as possibly including coding challenges and system design questions.

Focus areas

• Manufacturing Domain Knowledge
• Process Engineering Concepts
• Project Engineering

Overview

The work candidates describe is application engineering for manufacturing: building and maintaining software that supports production processes, reviewing code, working in sprints and fixing issues when something breaks. The reported questions mirror that mix closely. Alongside the coding questions you will find a production outage, a performance regression, a question about code quality and maintainability, and one on agile principles, so your preparation should cover how you run software day to day, not only algorithm practice.

The fourteen reported questions fall into four groups. Technical and domain questions ask you to explain object-oriented programming, compare SQL and NoSQL databases, describe a hard technical problem you solved, explain how you keep code maintainable, and lay out agile principles. Problem-solving cases ask how you would debug a system that went down, diagnose degrading performance, and design a basic inventory tracking system for a manufacturing facility. Behavioral questions cover working under pressure, resolving a conflict with a colleague and prioritizing several projects. Coding questions are reversing a linked list, explaining time and space complexity, and solving a problem with a stack or queue.

Most of the reported questions are standard topics, so preparation is mostly a matter of having a complete, specific answer ready for each. Practise reversing a linked list with its edge cases handled; end the SQL and NoSQL comparison in a choice for a concrete workload; structure the outage answer as an ordered sequence rather than a list of tools. Say each answer out loud, because several questions (OOP, agile, code quality) are easy to answer vaguely.

Candidates also report topic areas beyond general software engineering: Manufacturing Domain Knowledge, Process Engineering Concepts, Project Engineering, and Industrial Systems & Automation. The only reported question that touches them directly is the inventory design, so learn enough shop-floor vocabulary (work orders, bills of materials, work in progress, lot traceability, cycle counts) to model that system credibly. Also learn where plant software sits: PLC and SCADA at the machine layer, MES for production execution, ERP for planning, and OPC UA or MQTT for machine data. That placement helps when the inventory design is extended to machine readings: they arrive through their own ingestion path, separate from the stock ledger.

The Ajulia Executive Search interview process

The four stages below are the ones candidates describe, in the reported order; candidates also note that the process can vary by team. Only the technical stage has a reported format, so most of your technical preparation targets it, while your stories carry the behavioral and final stages.

Initial Screening

Candidates report an opening screen that looks at your qualifications at a basic level and how well you suit the role; no specific questions are reported for it. A sensible approach is to line your background up with the requirements candidates describe: Python, Java or C#, experience with both SQL and NoSQL databases, roughly two to five years in software engineering, and optionally AWS or Azure, DevOps and machine learning. Have a short walkthrough of your experience that touches each of those explicitly, with one project per point, and use the time to ask what the technical stage contains (live coding, system design or both), which language you may use, and which team or client work the role supports.

What to demonstrate

• Whether your background lines up with the reported requirements: Python, Java or C#, and SQL plus NoSQL experience
• Your experience level against the two to five years candidates describe for the role

How to prepare

• Write a walkthrough of your last two roles that names the language (Python, Java or C#) and the database type (relational or NoSQL) you used in each, with one measurable result per role.
• Prepare one sentence each on any AWS or Azure, DevOps or machine learning exposure, since those are the extras candidates list, and be honest where you have none.
• List three questions for the screener: the format of the technical interviews, the coding language allowed, and whether the work touches manufacturing systems directly.

Technical Interviews

Candidates report technical interviews that may include coding challenges and system design questions. The coding questions candidates report are fundamentals: reversing a linked list, explaining the time and space complexity of a solution, and solving a problem with a stack or queue. The one reported design question is a basic inventory tracking system for a manufacturing facility. Approach the coding by stating the approach and its complexity before writing, then writing working code in your strongest of Python, Java or C# and tracing it on a small input. Approach design by fixing the entities and operations first, then the data model, then concurrency and failure handling, and keep the scale assumptions explicit.

What to demonstrate

• Coding challenges, which candidates report the technical stage may include; the reported ones are reversing a linked list and solving a problem with a stack or queue
• The reported question 'Explain the time and space complexity of your solution.'
• System design questions, which candidates report the stage may include; the reported one is a basic inventory tracking system for a manufacturing facility

How to prepare

• Write iterative and recursive linked-list reversal from memory in your chosen language, then trace both on a three-node list and on an empty list so edge cases such as empty input are covered.
• Solve four stack and queue classics (valid parentheses, min stack, queue from two stacks, BFS on a grid) and state the complexity of each aloud.
• Sketch the manufacturing inventory system end to end: entities, a transaction ledger, how a stock decrement stays correct under concurrency, and how offline scanners sync.
• Rehearse the SQL versus NoSQL comparison ending in a concrete choice for inventory transactions versus high-volume machine readings.

Behavioral Interviews

Candidates report behavioral interviews that cover culture and values fit. The behavioral questions candidates report are about working under pressure, resolving a conflict with a colleague and prioritizing multiple projects; the areas candidates describe also mention collaboration, adaptability, communication, initiative and handling feedback. Approach each answer with a specific situation, the decision you personally made, the trade-off it involved and a result you can state concretely. Prepare more stories than prompts so you can pick the one that fits the question rather than bending one story to every prompt.

What to demonstrate

• Collaboration and communication in your own examples, as candidates report
• Adaptability when a plan changes, and initiative you took yourself
• How you prioritize and handle pressure, per the reported questions

How to prepare

• Write six stories in situation-decision-result form: a deadline under pressure, a disagreement with a colleague, competing projects, feedback you acted on, a plan you had to change, and something you led without being asked.
• For each story, underline the sentence that states your own decision; if there is none, pick a different story.
• Rehearse the conflict story so the other person's position is described fairly and the working relationship afterwards is part of the result.

Final Interviews

Candidates report final interviews where you present your strengths and talk through how you fit; no format or specific questions are reported for this stage. A reasonable approach is to go deeper on your strongest project, since describing a challenging technical problem you solved is among the reported questions and gives you the most room to show depth. Go in able to explain one system you built end to end: its design, a trade-off you would revisit, and how you tested and supported it in production. Bring your own questions about the team's development process and the manufacturing systems the software touches.

What to demonstrate

• Your strengths and fit for the role, which candidates report are covered in this stage
• Your strongest project, which is the natural material for the reported challenging-problem question

How to prepare

• Pick one project and prepare a deep dive: the problem, your design, one alternative you rejected and why, how you tested it, and what failed in production.
• Write down two trade-offs from that project you would make differently today, with the reason.
• Prepare questions about sprint practices, code review norms and which manufacturing processes the team's software supports.

Where candidates lose points

Reversing the linked list but losing the remainder of the list because curr.next is overwritten before it is saved, or leaving the old head pointing forward and creating a cycle.

Write the save-reverse-advance order (save next, point back, advance both pointers) as a fixed pattern, and trace it on an empty list, one node and three nodes every time you practise it.

Comparing SQL and NoSQL with slogans such as 'NoSQL scales and SQL does not' without ever choosing a database for a workload.

End the answer with a decision: name the workload (an inventory ledger with atomic moves, or a stream of machine readings), the consistency it needs, the access pattern, and the database type that fits, with the trade-off you accept.

Designing the manufacturing inventory system as a list of services and boxes without a data model, so nothing stops two stations from consuming the same last units.

Start from entities and the transaction ledger, then show the conditional update or row lock that prevents negative stock and the idempotency key that makes scanner retries safe.

Answering the outage or performance questions with a guess ('probably the database, add more servers') instead of an ordered diagnosis.

Rehearse a fixed sequence: quantify the symptom, mitigate, check what changed, locate the saturated layer with metrics, confirm with a profiler or EXPLAIN ANALYZE, fix one thing and verify with the same metric.

Behavioral and agile answers told in generalities or entirely in the plural, so there is no decision you can be credited with.

For every story and for the agile and code quality questions, include one concrete episode from your own work and one sentence that begins with 'I decided' or 'I changed'.

Questions & practice

Write a function to reverse a linked list.

Medium · Coding / Algorithms

Approach

1. Use the iterative three-pointer method: prev = null, curr = head; in a loop save nxt = curr.next, set curr.next = prev, then advance prev = curr and curr = nxt; return prev as the new head.
2. State the complexity: O(n) time and O(1) extra space; the recursive version (reverse the rest, then set head.next.next = head and head.next = null) is also O(n) time but uses O(n) call-stack space and can overflow on long lists.
3. Handle edge cases explicitly: empty list returns null, a single node returns itself, and the old head must end with next = null or the list becomes a cycle.
4. Trace the code on a three-node list out loud before declaring it done; the classic bug is overwriting curr.next before saving it, which loses the rest of the list.

Follow-up

• Reverse only the nodes between positions m and n.
• Reverse the list in groups of k nodes.
• Use reversal to check whether a linked list is a palindrome in O(1) extra space.

Explain the time and space complexity of your solution.

Medium · Coding / Algorithms

Approach

1. Derive time complexity from the code: count how often the innermost work runs as a function of input size, multiply for nested loops over the same input, and use a recurrence (or the master theorem) for divide-and-conquer recursion, e.g. T(n) = 2T(n/2) + O(n) gives O(n log n).
2. Report space as auxiliary space separately from the input, and include the recursion stack and any hash maps, copies or output structures you build.
3. Distinguish cases where it matters: average versus worst case for hash maps (O(1) average, O(n) worst) and quicksort (O(n log n) average, O(n squared) worst), and amortized O(1) for dynamic array appends.
4. Apply it to your actual solution: for iterative linked-list reversal, O(n) time and O(1) space; for the recursive version, O(n) time and O(n) space because of the call stack.

Follow-up

• What is amortized analysis? Explain it with a dynamic array.
• Can you trade more memory for a faster solution here?
• When would an O(n log n) solution beat an O(n) one in practice?

Solve a problem using a specific data structure (e.g., stack, queue).

Medium · Coding / Algorithms

Approach

1. Choose the structure from the access order: a stack (LIFO) for matching and undo-like problems, a queue (FIFO) for processing in arrival order and breadth-first search, and a deque for sliding windows.
2. Have the canonical problems ready: valid parentheses and evaluating reverse Polish notation with a stack; next greater element with a monotonic stack in O(n); min stack with a second stack for O(1) getMin; shortest path in an unweighted grid with BFS on a queue; sliding window maximum with a deque in O(n).
3. Use the right library type: Python collections.deque (list.pop(0) is O(n)), Java ArrayDeque rather than the legacy Stack class, C# Stack<T> and Queue<T>.
4. Cover edge cases: popping or peeking an empty structure, unbalanced input that ends with a non-empty stack, and visited-marking in BFS so nodes are not enqueued twice.

Follow-up

• Implement a queue using two stacks and explain why each operation is amortized O(1).
• How would you make a bounded queue safe for one producer and one consumer thread?
• Design a stack that returns its minimum element in O(1).

What are the differences between SQL and NoSQL databases?

Medium · Technical / Domain Questions

Approach

1. Start with the data model: SQL databases store rows in tables with a fixed schema, joins and ACID transactions; NoSQL is a family, so name the four kinds: document (MongoDB), key-value (Redis, DynamoDB), wide-column (Cassandra) and graph (Neo4j).
2. Compare on consistency and scaling: relational systems give multi-row transactions and usually scale reads with replicas and writes vertically or by careful sharding; many NoSQL stores partition horizontally by design and offer tunable or eventual consistency, trading cross-partition joins and transactions.
3. Compare on schema and queries: schema-on-write with SQL lets the database enforce constraints and supports ad hoc queries; document stores are schema-flexible but you design documents around known access patterns, and ad hoc queries become expensive.
4. Finish with a decision for a concrete workload: an inventory ledger where a stock move must debit one location and credit another atomically belongs in a relational database; a high-volume stream of machine sensor readings keyed by machine and time fits a wide-column or time-series store.
5. Mention that the line has blurred: PostgreSQL has JSONB columns, and MongoDB supports multi-document transactions, so the choice is about defaults and access patterns rather than absolutes.

Follow-up

• Explain the CAP theorem and where your chosen database sits during a network partition.
• How would you keep two documents consistent in a store without multi-document transactions?
• How would you migrate a growing relational table to a NoSQL store without downtime?

Find version gaps and relay lag with window functions

Medium · window functions · event tables · frame semantics

outbox_event holds event_id, aggregate_type, aggregate_id, aggregate_version, event_type, payload, status ('pending','published','dead'), attempts, created_at, published_at. A projection is missing rows and you must decide whether the relay skipped events or the consumer dropped them. Write three queries over the last seven days: one listing every aggregate_id whose published aggregate_version sequence has a hole, one giving per-day counts with a running total, and one returning the newest published event per aggregate. For each, say where the window function is evaluated relative to WHERE and LIMIT. PostgreSQL 16.

Approach

1. Gaps: compute lead(aggregate_version) OVER (PARTITION BY aggregate_id ORDER BY aggregate_version) in a subquery, then filter next_version <> aggregate_version + 1 in the outer query. Window functions are evaluated after WHERE, GROUP BY and HAVING and before the outer ORDER BY and LIMIT, so the predicate cannot sit in the same WHERE clause and PostgreSQL 16 has no QUALIFY.
2. Say what the seven-day filter does to the answer: it truncates every partition, so the first row per aggregate has no predecessor inside the window and a hole spanning the boundary is invisible. Widen the window, or join to resource.version as the authority for the true maximum.
3. Running total: SELECT date_trunc('day', created_at) AS d, count() AS n, sum(count()) OVER (ORDER BY date_trunc('day', created_at) ROWS UNBOUNDED PRECEDING). An aggregate inside a window call is legal because grouping runs before windowing. The grouping key is unique per row here so ROWS and RANGE agree, but write the frame anyway — over ungrouped rows with tied timestamps the default RANGE frame pulls in every peer row and the total jumps.
4. Newest per aggregate: DISTINCT ON (aggregate_id) ... ORDER BY aggregate_id, aggregate_version DESC is the cheap PostgreSQL-only form when an index matches that order; row_number() OVER (PARTITION BY aggregate_id ORDER BY aggregate_version DESC) = 1 is the portable form and needs a subquery for the same evaluation-order reason as the gap query.

Follow-up

• Relay failover redelivers events. Does a duplicate break the gap query, and how would you detect one from this table alone?
• Turn the gap check into a continuous monitor rather than a query someone runs after an incident. What does it watch?

Explain the concept of object-oriented programming and its benefits.

Medium · Technical / Domain Questions

Approach

1. Define the four pillars with one concrete example each: encapsulation (a class hides its state behind methods, e.g. an InventoryItem whose quantity changes only through receive() and consume()), abstraction (callers use an interface, not the implementation), inheritance (a subclass reuses and extends a base class), polymorphism (one call, different behaviour by runtime type).
2. Tie benefits to maintenance, not slogans: encapsulation protects invariants such as non-negative stock, interfaces let you swap implementations and mock them in unit tests, and polymorphism replaces long if/else chains on a type field.
3. Show you know the limits: deep inheritance hierarchies are brittle, so prefer composition and interfaces; mention the Liskov substitution principle (a subclass must be usable anywhere its base is) as the rule that keeps inheritance honest.
4. Answer in the syntax of your interview language: Python uses duck typing and abc.ABC for abstract classes, Java and C# have explicit interfaces and abstract classes, and C# adds properties for controlled access.

Follow-up

• When would you choose composition over inheritance? Give an example from your own code.
• What is the difference between an interface and an abstract class in Java or C#?
• Which SOLID principle do you break most often, and what does it cost?

Describe a challenging technical problem you faced and how you resolved it.

Medium · Technical / Domain Questions

Approach

1. Pick a problem that was hard for a technical reason (a race condition, a memory leak, a data corruption, a scaling limit), not one that was hard because of scheduling, and make sure you personally drove the diagnosis.
2. Structure it as symptom, hypotheses, evidence, fix: say what you observed, the two or three explanations you considered, the measurement or experiment that ruled each out, and the change you made.
3. Quantify the outcome (error rate, latency, hours saved, incidents avoided) and state what you added so it would not recur, such as a test, an alert or a design change.
4. Avoid the story that sinks this answer: one told entirely in the plural, where the listener cannot tell what you did, or one where the fix was luck rather than reasoning.

Follow-up

• What would you have done if your first hypothesis had been right but the fix had not worked?
• What did you change in your process or tooling afterwards?
• How did you explain the problem and the fix to non-engineers?

How do you ensure code quality and maintainability?

Medium · Technical / Domain Questions

Approach

1. Answer as a layered system: automated checks (formatter and linter in CI, such as ruff or flake8 for Python, Checkstyle or SpotBugs for Java, Roslyn analyzers for C#), tests, code review, and design habits.
2. Describe your testing approach concretely: many fast unit tests around business logic, fewer integration tests against a real database, and a handful of end-to-end tests; mention dependency injection so units can be tested with fakes.
3. Say what you look for in a code review: correctness and edge cases first, then naming, single responsibility, error handling and test coverage of the change; keep pull requests small so reviews are real.
4. Address existing code: write characterization tests before refactoring legacy code, refactor in small steps, and track technical debt as visible backlog items rather than silent rewrites.
5. Give one example where a practice caught a real bug or made a change cheap, so the answer is not only a list.

Follow-up

• How do you write unit tests for code that talks directly to a database or a machine interface?
• Is a code coverage target useful? What number would you set and why?
• How do you handle a review where you and the author disagree on a design choice?

What are the principles of agile software development?

Medium · Technical / Domain Questions

Approach

1. State the Agile Manifesto's four values: individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan; note that the right-hand items still have value.
2. Pick four or five of the twelve principles and explain them in practice: deliver working software frequently, welcome changing requirements, business people and developers work together daily, sustainable pace, and regular reflection to adjust.
3. Connect to Scrum as you have run it: sprint planning, daily stand-up, sprint review and retrospective, with product owner, Scrum master and team roles; contrast with Kanban's continuous flow and work-in-progress limits.
4. Give one example from your own team: a retrospective action that changed something, or how you handled a requirement change mid-sprint.

Follow-up

• What do you do when scope changes in the middle of a sprint?
• How does your team estimate work, and how accurate has it been?
• When have you seen agile practices fail, and why?

Given a scenario where application performance is degrading, what steps would you take to diagnose the issue?

Medium · Problem-Solving / Case Studies

Approach

1. Turn 'slow' into numbers first: which endpoints or jobs, p50 versus p95 and p99 latency, throughput, error rate, and when it started; a sudden step suggests a change, a gradual slope suggests growth or a leak.
2. Check resources with the USE method (utilization, saturation, errors for CPU, memory, disk, network) and services with RED (rate, errors, duration) to find which layer is saturated.
3. For the database, read the slow query log and run EXPLAIN ANALYZE on the worst queries: look for missing indexes, full table scans on tables that grew, N+1 query patterns from the ORM, and lock contention.
4. For the application, profile under load (py-spy for Python, Java Flight Recorder, dotnet-trace for C#) and check garbage collection pauses, thread or connection pool exhaustion, and memory growth over time.
5. Fix one thing, verify with the same metrics or a load test, and add an alert or performance test so the regression is caught next time.

Follow-up

• Performance degrades slowly over several days and recovers after a restart. What do you suspect?
• Only one customer or one facility sees the slowness. How does that change your approach?
• Would you add a cache? What could go wrong with it?

Design a basic system for tracking inventory in a manufacturing facility. What factors would you consider?

Medium · Problem-Solving / Case Studies

Approach

1. Clarify scope and entities: items (SKUs with units of measure), locations (receiving, storage bins, work-in-progress at stations, finished goods), lots or serial numbers for traceability, and work orders that consume components according to a bill of materials.
2. Model stock as an append-only transaction ledger (receive, move, issue to work order, produce, scrap, adjust) plus an on-hand balance per item and location updated in the same database transaction; the ledger gives auditability and lets you rebuild balances.
3. Handle concurrency explicitly: decrement with a conditional update such as UPDATE balance SET qty = qty - :n WHERE item = :i AND location = :l AND qty >= :n, or a row lock, so two stations cannot consume the same units; give scanner requests idempotency keys so retries do not double-count.
4. Cover the physical-world issues: barcode or RFID input, handheld devices that go offline and sync later (queue locally, resolve conflicts on sync), cycle counts that produce adjustment transactions, and reorder-point alerts. For machine data, know the plant layers: PLC and SCADA at the machine, MES for production execution, ERP for planning, and OPC UA or MQTT carrying readings into your ingestion path.
5. Choose a relational database for the ledger because of multi-row atomic moves, state the scale assumption (transactions per minute per facility is modest), and name the reports needed: on-hand by location, lot genealogy, consumption per work order.

Follow-up

• A cycle count finds fewer units than the system shows. How does your design record and investigate that?
• Machines on the line report readings and production counts. Where do they enter your design, and how do they relate to the stock ledger?
• Two handheld scanners were offline and both issued the last units of a part. How do you resolve it?

How would you approach debugging a system that has gone down unexpectedly?

Medium · Problem-Solving / Case Studies

Approach

1. Mitigate before diagnosing: confirm the outage and its scope (all users or some, one service or many), declare an incident, and restore service by the fastest safe route, such as rolling back the latest deploy, failing over or restarting a stuck component.
2. Then work from what changed: deploys, configuration changes, infrastructure events, traffic spikes, certificate expiry, a full disk; correlate the start time on dashboards with the change log.
3. Narrow the failing layer in order: health checks and load balancer, application logs and error rates, then dependencies (database connections, message queues, DNS, third-party APIs); use the boundary where requests stop succeeding to bisect.
4. Keep communication running: a status update cadence to stakeholders and a single incident lead so actions are not duplicated.
5. Close with a blameless postmortem: timeline, root cause versus trigger, and action items such as an alert that would have fired earlier or a test that would have caught it.

Follow-up

• The rollback did not fix it. What do you check next?
• There are no useful logs from the failing component. How do you proceed?
• How would you prevent this class of outage from recurring?

Suggested practice checklist

Each day targets one group of the questions candidates report for this loop, in the order of the technical stage first and stories last, and ends with an artifact you can rehearse from in the final days.

Day 1 — Map the loop and prepare the screen

• List the four reported stages (Initial Screening, Technical Interviews, Behavioral Interviews, Final Interviews) and note what is reported about each.
• Match your background line by line to the reported requirements: Python, Java or C#, SQL and NoSQL experience, and any AWS or Azure, DevOps or machine learning exposure.
• Write a short spoken walkthrough of your experience and the three questions you will ask at the screen.

Deliverable: A one-page loop map, a requirements match table with a project for each line, and a rehearsed walkthrough with screen questions.

Day 2 — Linked lists and complexity

• Write iterative and recursive linked-list reversal in your interview language from memory, then trace both on empty, one-node and three-node lists.
• Extend to reversing positions m to n and reversing in groups of k.
• For every solution, state time and auxiliary space out loud, including the recursion stack.

Deliverable: Four working reversal functions (iterative, recursive, positions m to n, groups of k) with traced test cases and a written complexity line for each.

Day 3 — Stacks and queues

• Solve valid parentheses, min stack and next greater element with a stack.
• Solve shortest path in a grid with BFS and implement a queue from two stacks.
• Write down the stack, queue and deque types and their costly operations in your language.

Deliverable: Five solved problems with complexity notes and a one-page cheat sheet of your language's stack and queue APIs.

Day 4 — Concepts: OOP and databases

• Write a small class design (for example an inventory item and stock locations) that shows encapsulation, an interface and polymorphism, and explain where you used composition instead of inheritance.
• Build a comparison table of relational, document, key-value, wide-column and graph databases on schema, transactions, scaling and query flexibility, with one workload you would assign to each.
• Solve the window-function practice problem on version gaps and relay lag to keep your SQL fluent.

Deliverable: A short class design with a spoken explanation, a database comparison table ending in decisions, and a solved window-function query.

Day 5 — Design the manufacturing inventory system

• Learn the vocabulary the reported topic areas imply: bill of materials, work order, work in progress, lot traceability, cycle count, reorder point, plus the plant layers (PLC and SCADA, MES, ERP, OPC UA or MQTT).
• Write the data model: items, locations, lots, the transaction ledger and the on-hand balance table.
• Write the conditional update that prevents negative stock, and outline offline scanner sync with idempotency keys.
• Present the full design aloud in one pass, then answer the machine-readings and cycle-count follow-ups.

Deliverable: A glossary, a schema sketch, a concurrency-safe stock decrement and a recorded design walkthrough.

Day 6 — Outages and performance

• Write your ordered outage runbook: scope, mitigate, what changed, layer-by-layer narrowing, communication, postmortem.
• Write your performance diagnosis sequence with the tools you would use: metrics, slow query log, EXPLAIN ANALYZE, a profiler for your language.
• Run one real EXPLAIN ANALYZE on a slow query with and without an index and note the difference.

Deliverable: Two one-page diagnostic sequences and an annotated query plan comparison you can cite as an example.

Day 7 — Stories and engineering practice

• Write six stories for the challenging technical problem, working under pressure, a conflict with a colleague, juggling several projects, feedback you acted on and a plan you had to change, each with your own decision underlined.
• Prepare your code quality answer (CI checks, test layers, review checklist, legacy code) and your agile answer with one episode from your own sprints.
• Rehearse the final-stage project deep dive and run every story aloud once.

Deliverable: Six written stories, two practice answers with real examples, and a rehearsed project deep dive.

Behavioural preparation

Candidates report a behavioral stage covering culture and values fit, and the areas they describe include collaboration, adaptability, communication, initiative and taking feedback. For an engineer working on manufacturing software with product, QA and other engineering teams, build stories around shipping under a deadline, resolving technical disagreements and handling changing priorities, each with a decision you made yourself.

1. How do you handle feedback from colleagues or supervisors?
2. Describe a time when you had to pivot from your original plan; what did you do?
3. What motivates you to contribute to a team?

Describe a time when you had to work under pressure. How did you manage your time and resources?

Medium · Behavioral / Leadership

Approach

1. Choose a situation with real pressure and a real constraint (a production issue during a release, a client deadline moved up), where you made the prioritization calls.
2. Spend most of the answer on the decisions: what you cut or deferred, how you split work or asked for help, and how and when you told stakeholders about the trade-off.
3. State the result honestly, including what slipped, and one thing you now do earlier to avoid the same squeeze.
4. Avoid the answer that is only about working late: long hours show effort, not judgment about time and resources.

Follow-up

• What did you decide not to do, and how did you communicate that?
• How did you make sure quality did not drop under the deadline?
• What would you do differently if the same deadline came up again?

Can you give an example of a conflict you had with a colleague and how you resolved it?

Medium · Behavioral / Leadership

Approach

1. Pick a substantive disagreement, ideally technical (a design choice, a code review dispute, ownership of a bug), not a personality clash.
2. Describe the colleague's position fairly and what was reasonable about it before giving yours; this shows you understood the conflict rather than just won it.
3. Explain how it was resolved: agreeing on criteria, gathering data or building a small prototype, or escalating with both options written down; say what you conceded.
4. End with the outcome and the working relationship afterwards; a story where the other person is simply wrong and you prevailed tends to sink this answer.

Follow-up

• What would you have done if the data had supported your colleague?
• When is escalating to a manager the right move in a disagreement like this?
• How did you work with that person on the next project?

How do you prioritize tasks when managing multiple projects?

Medium · Behavioral / Leadership

Approach

1. Give your method, then prove it with one real example: rank work by impact and urgency, account for hard deadlines and dependencies (unblock others first), and estimate effort so small high-value items are not starved.
2. Make trade-offs visible: when two projects compete, put the conflict in front of the product manager or lead with options and consequences instead of silently choosing.
3. Limit work in progress: finish or hand off one item before starting another, and protect focus time for deep work.
4. Show how you re-plan when priorities change, for example a production issue arriving mid-sprint, and how you tell the people whose work slips.

Follow-up

• Two stakeholders both say their request is the top priority. What do you do?
• How do you keep track of commitments across several projects?
• Tell me about a time your prioritization turned out wrong.