Bobrick Washroom Equipment Software Engineer Interview Guide

The 60-second brief

Bobrick Washroom Equipment makes washroom products, and the software engineering role described to candidates sits beside that manufacturing business. Reported projects range from ERP system enhancements to IoT integrations in the products themselves, and the topics candidates connect to the role are ERP systems, Infor CloudSuite Industrial, Infor Syteline, manufacturing systems and operational technology (OT). The engineer works with product managers and other engineers on requirements, builds and reviews code, and fixes issues found during development or after release. In practice that means business software that touches production and product data, so general engineering skill and comfort with that vocabulary both matter.

This guide is for candidates interviewing for the Software Engineer role at Bobrick Washroom Equipment. It covers the three reported stages, every reported question with a worked approach (technical, problem-solving, coding and behavioral), the ERP and manufacturing vocabulary worth knowing, and a seven-day plan. The reported role lists Java, C# or Python, web frameworks and databases as must-haves, and typically 3-5 years of experience.

Candidates report three stages over roughly 3-5 weeks: a Recruiter Phone Screen, Technical Interviews with technical team members, and a possible Facility Tour.

Focus areas

• ERP Systems
• Infor CloudSuite Industrial
• Manufacturing Systems

Overview

The work candidates describe is software for a manufacturer: enhancements to an ERP system on one side, IoT integrations in the products on the other. The topics attached to this role are ERP Systems, Infor CloudSuite Industrial, Infor Syteline, Manufacturing Systems and Operational Technology. You are not expected to have used every one of these. ERP familiarity is reported as a nice-to-have, while Java, C# or Python plus web frameworks and databases are reported as must-haves. Prepare to talk about the general shape of this kind of work: data moving between a business system and other software, imports that must be safe to re-run, and changes that must not disturb a running operation.

The reported questions are general software engineering questions rather than ERP-specific ones. They fall into four groups: technical and domain (your languages, a recent technology project, debugging, object-oriented versus functional programming, Git), problem-solving (designing a feature, improving a legacy codebase, speed versus quality, an at-risk deadline, a complex problem), coding (reversing a linked list, stating complexity, using a stack or queue, optimizing search over a large dataset, error handling), and behavioral. Most of your preparation is therefore fundamentals you can explain aloud and a small set of real stories with specific details.

Candidates describe a typical experience level of 3-5 years, so choose stories where you owned a decision, not ones where you followed instructions. Work with product managers and other engineers is part of the reported role, so keep at least one story about explaining a technical constraint to a non-engineer. If you have no ERP or manufacturing exposure, say so plainly in the recruiter call and point to the nearest thing you have done, such as integrating with an external system, running scheduled data jobs, or supporting users after release.

The Bobrick Washroom Equipment interview process

Candidates describe three stages over about 3-5 weeks. The final stage is described as a possible facility tour, so confirm with the recruiter what your own schedule includes.

Recruiter Phone Screen

Candidates report a first call with a recruiter about your background and your fit for the Software Engineer position. The role as described lists Java, C# or Python, web frameworks and databases as must-haves, ERP familiarity as a nice-to-have, and typically 3-5 years of experience, so line up your history against those points before you dial in. Use the call to learn the shape of the rest of your loop, because the stages above are what candidates describe and not a fixed published process.

What to demonstrate

• Your background and fit for the Software Engineer position, which is how candidates describe the call
• How clearly you summarise your own experience and the languages and databases you have used
• Whether your experience, including any ERP or manufacturing exposure, matches what the role describes

How to prepare

• Write a short career summary that names your main language, one web framework and one database you have shipped with, and one project with a result you can state.
• Prepare an honest answer on ERP: if you have touched Infor Syteline, CloudSuite Industrial or any other ERP, say what you did; if not, name the closest work, such as integrating with an external business system or supporting a production release.
• Ask which stages remain, who the technical interviewers are, and whether the facility visit is part of your loop; candidates also report a hybrid working model, so ask about location expectations.

Technical Interviews

Candidates report interviews with technical team members focused on your technical skills and problem-solving. The reported question list for the role is general software engineering: your strongest languages and a recent project with a new technology, debugging, object-oriented versus functional programming, Git, designing a feature, taking over a legacy codebase, trading speed against quality, and coding topics such as reversing a linked list, complexity, stacks and queues, search over large data and error handling. Candidates are told that practical exercises or whiteboard challenges may appear. The reports do not say which question belongs to which stage, so prepare the whole set and practise reasoning aloud.

What to demonstrate

• Working code and clear reasoning on the coding topics, including time and space complexity
• Technical knowledge across the languages, tools and practices you claim, such as debugging and Git
• Problem-solving on open scenarios like designing a feature or improving a legacy codebase
• How you explain technical choices to colleagues

How to prepare

• Write the iterative linked-list reversal in your main language from memory, test it on empty, single-node and long lists, and state its time and space cost.
• Practise the debugging answer as a sequence: reproduce, narrow down, form a hypothesis, test it, fix, add a regression test.
• Prepare a two-sided comparison of object-oriented and functional programming, with one example from your own code for each.
• Rehearse the design and legacy-code scenarios with a structure: clarify requirements, list risks, propose small steps, say how you would verify each step.

Facility Tour

Candidates describe the last stage as a possible tour of the facilities, meant to show you the work environment and team dynamics. Since the tour is described as possible, confirm whether it is part of your loop. The reported question list contains no tour-specific questions, so treat it as a chance to meet the team, see what the software supports, and show how you work with others. Bring your behavioral stories and a few questions about how the software relates to the physical operation.

What to demonstrate

• How you fit with the work environment and the team, which is the purpose candidates describe for the stage
• How you communicate and collaborate with people from product, engineering and other groups

How to prepare

• Have the stories for the collaboration, difficult colleague and team success questions ready with specific details.
• Write questions about the work itself: which systems the software connects to, how ERP and shop-floor software exchange data, and how changes reach a running operation.
• Be ready to explain a technical idea, such as an integration or a debugging finding, to someone outside engineering using no jargon.

Where candidates lose points

Reversing the linked list but losing the rest of the list, or failing on an empty or single-node input

Name the three pointers (previous, current, next) before you write code, save the next node before you overwrite the link, and trace an empty list, a one-node list and a three-node list by hand. Then state O(n) time and O(1) extra space for the iterative version, and the O(n) call stack of the recursive one.

Answering the question about your strongest languages with a list of names and no depth

Pick the one language you will code in, preferably one of Java, C# or Python, and back it with a project: a feature you shipped, a library or framework you used, and a trade-off you made. Be ready to say where it is a poor fit.

Giving a debugging answer such as 'I add print statements until I find it' with no method

Describe a sequence: reproduce the failure, find the smallest failing case, check recent changes, form one hypothesis at a time, confirm with a log, test or debugger, fix the cause, and add a regression test. Close with a real bug you tracked down this way.

Telling behavioral stories entirely in 'we', with no result you can state

For each prepared story write what you decided, what you did, and what changed afterwards, with a number or an observable outcome. Rehearse the challenge, prioritization, difficult colleague and team success stories aloud so each has a distinct example.

Treating the role as generic web work and being unable to say anything about ERP, manufacturing systems or software connected to equipment

Learn the basic vocabulary of ERP (orders, inventory, production data) and of software that exchanges data with equipment. Say honestly what you have not used, and describe your nearest experience, such as an integration with an external system or a scheduled data job.

Questions & practice

Write a function to reverse a linked list.

Medium · Coding / Algorithms

Approach

1. Iterative three-pointer reversal: prev = null and curr = head. Loop while curr is not null: next = curr.next, curr.next = prev, prev = curr, curr = next. Return prev as the new head. O(n) time, O(1) extra space.
2. Recursive version: reverse the rest, which returns the new head, then set head.next.next = head and head.next = null. It is also O(n) time but uses O(n) call-stack space, so a long list can overflow the stack (Python's default recursion limit is 1000).
3. Edge cases: an empty list (head is null), a single node, and two nodes. Make sure the old head's next ends up null; otherwise the result contains a cycle.
4. Test by walking the reversed list against the expected sequence and checking that the length is unchanged. For a doubly linked list, swap each node's prev and next pointers and return the last node.

Follow-up

• Reverse only the sublist between positions m and n.
• Reverse the list in groups of k nodes.
• How would you detect a cycle before reversing (Floyd's tortoise and hare)?

Explain the time and space complexity of your solution.

Medium · Coding / Algorithms

Approach

1. Define the terms: Big-O is an upper bound on growth as input size grows. Count the dominant operations, drop constants and lower-order terms, and keep separate variables for separate inputs (O(n + m), not O(n)).
2. Time: sequential loops add, nested loops over the same input multiply (O(n^2)), and recursion gives a recurrence. For example, merge sort's T(n) = 2T(n/2) + O(n) solves to O(n log n). Hash map operations are O(1) on average but O(n) in the worst case.
3. Space: separate auxiliary space from the input and output, and count recursion depth. Linear recursion uses O(n) stack; recursive binary search uses O(log n).
4. Separate worst, average and amortised cost: dynamic-array append is amortised O(1) because capacity doubles; quicksort is O(n log n) on average and O(n^2) in the worst case.
5. Apply it to my own solution aloud. For linked-list reversal, the iterative version is O(n) time and O(1) space, and the recursive one is O(n) space because of the call stack.

Follow-up

• Compare sorting plus two pointers with a hash-set approach for the same problem, in time and space.
• Explain why appending to a dynamic array is amortised O(1).
• Can you trade space for time in your solution? What would it cost?

Can you solve a problem using a specific data structure, such as a stack or queue?

Medium · Coding / Algorithms

Approach

1. Match the structure to the access pattern. A stack (LIFO) fits nesting, undo, backtracking and most-recent-unmatched problems: balanced brackets, expression evaluation, iterative DFS, monotonic-stack next-greater-element. A queue (FIFO) fits arrival order: BFS shortest path in an unweighted graph, task scheduling, sliding windows with a deque.
2. Worked example, valid brackets: push each opening bracket; on a closing bracket, check that the stack is non-empty and its top matches, then pop; at the end the stack must be empty. O(n) time, O(n) space.
3. Pick the right library type: Java ArrayDeque (its Javadoc recommends it over the legacy synchronised Stack class), C# Stack<T> and Queue<T>, and in Python a list for a stack but collections.deque for a queue, because list.pop(0) is O(n) while deque.popleft() is O(1).
4. Know the classic variants: a queue built from two stacks (amortised O(1) per operation), and a min-stack that returns its minimum in O(1) by storing (value, current min) pairs or keeping an auxiliary stack.
5. Edge cases: popping or peeking an empty structure, input made only of openers, and a closing bracket that comes first.

Follow-up

• Implement a queue with two stacks and state the amortised cost.
• Design a stack that returns its minimum in O(1).
• For each element of an array, find the next greater element.

How would you optimize a search algorithm for a large dataset?

Medium · Coding / Algorithms

Approach

1. Clarify the workload first: data size relative to memory, static or frequently updated data, query type (exact match, range, prefix, full-text, nearest neighbour), read/write ratio and latency target.
2. Pick the structure for the query type. Use a hash index for exact match (O(1) average). Use binary search on sorted data (O(log n) per query after a one-off O(n log n) sort, which pays off over many queries). Use a balanced tree or B-tree for ranges (O(log n + k) for k results).
3. Prefix and text search: a trie for prefixes and an inverted index for full-text, the structure Lucene-based engines use. Data in a database needs a B-tree index rather than a scan. Confirm with EXPLAIN that the index is used, and avoid wrapping the indexed column in a function unless an expression index exists.
4. Beyond one machine, partition or shard by key and search the partitions in parallel, and cache hot results with LRU eviction. A Bloom filter can skip partitions that certainly lack a key: false positives are possible, false negatives are not.
5. Measure before and after with realistic data distributions, and state the costs: memory for the index and slower writes to keep it current.

Follow-up

• How would you search data that does not fit in memory?
• What changes if the data is updated constantly?
• Which queries can a B-tree index serve that a hash index cannot?

Discuss how you would implement error handling in your code.

Medium · Coding / Algorithms

Approach

1. Classify errors: expected, recoverable conditions (invalid input, record not found, timeouts) versus programming bugs and broken invariants. Validate input at system boundaries and fail fast with a clear message.
2. Handle each error where something useful can be done (retry, fallback, translate it for the user), otherwise let it propagate. Never swallow an exception in an empty catch, and keep the cause when wrapping: Java exception chaining, C# InnerException, Python raise ... from err.
3. Release resources deterministically with try-with-resources in Java, using in C#, with blocks in Python, or finally. Keep multi-step writes in a transaction that rolls back on failure.
4. For calls to external systems, set timeouts and retry transient failures with exponential backoff and jitter, but only for idempotent operations or with an idempotency key. Add a circuit breaker so a failing dependency does not exhaust threads.
5. Make failures visible: structured logs with context such as a correlation id and no secrets, metrics and alerts, consistent error responses (status and error code) for APIs, and tests that exercise the error paths explicitly.

Follow-up

• When do you choose exceptions, and when result or return values?
• How would you make a retried call to an external system safe from double-processing?
• What should the user see, and what should go only into the log?

Hold a per-tenant active cap against concurrent creates

Hard · write skew · isolation levels · constraints

A tenant on the standard plan may hold at most 50 resources with status='active'. The create handler runs SELECT count(*) FROM resource WHERE tenant_id = $1 AND status = 'active', compares to 50, then inserts. Two creates arrive 3 ms apart on different instances and the tenant lands at 51. Name the anomaly, say whether PostgreSQL 16 READ COMMITTED or REPEATABLE READ prevents it and why, then give an implementation that holds the cap at READ COMMITTED with the exact statements. Finally, say what changes when the cap is 'at most one running export per tenant' on job_run.

Approach

1. Name it: write skew. The two transactions read an overlapping set and write disjoint rows, so there is no row-level conflict for the engine to detect and each commit is individually legal.
2. Rule out the levels precisely. READ COMMITTED takes a fresh snapshot per statement and takes no lock on the counted rows, so both see 49. PostgreSQL's REPEATABLE READ is snapshot isolation: it removes non-repeatable reads and phantoms within the snapshot but still admits write skew, because the anomaly is not a re-read of a changed row, it is a read of a set that a concurrent transaction invalidates. Only SERIALIZABLE closes it, by tracking the read dependency and aborting one transaction with SQLSTATE 40001 — a guarantee that exists only if the application re-runs the whole transaction from the read.
3. Convert the set predicate into a single-row conflict: keep tenant.active_resource_count and run UPDATE tenant SET active_resource_count = active_resource_count + 1 WHERE tenant_id = $1 AND active_resource_count < 50 in the same transaction as the INSERT. Zero affected rows is the cap, returned as 409. The row lock serialises the decision at any isolation level, and contention is bounded to one tenant's row — which is also the fair-scheduling unit, unlike a global counter that would convoy every tenant behind one row.
4. State the cost you just took on: a counter is a second source of truth that can drift, so every path that changes status must adjust it inside the same transaction, and a periodic reconciliation has to exist, with resource_revision as the authority for what the count should have been.

Follow-up

• A resource moves from archived back to active. Which statements change, and what breaks if the counter update and the status change land in different transactions?
• The cap becomes plan-dependent and a plan can change mid-month. Where does the number 50 live, and who reads it?

Write the update path that detects a concurrent edit

Medium · optimistic concurrency · transactional outbox · audit history

resource carries version INT NOT NULL DEFAULT 1. resource_revision holds revision_id, resource_id, version, actor_user_id, change_kind, patch JSONB, request_id, created_at with UNIQUE (resource_id, version). outbox_event holds aggregate_type, aggregate_id, aggregate_version, event_type, payload, status. A PUT carries the version the client read. Write the exact statements for the single transaction that applies the edit, records the revision and enqueues 'resource.updated', and give the handler's branch on zero affected rows. Then say what PostgreSQL 16 does under READ COMMITTED when two of these updates hit one row at once.

Approach

1. One transaction, three writes, no network call inside it: UPDATE resource SET title = $3, version = version + 1, updated_at = now() WHERE resource_id = $1 AND tenant_id = $4 AND version = $2; then INSERT the resource_revision row at version $2 + 1; then INSERT the outbox_event row at the same aggregate_version. The event goes to a table rather than a broker because no transaction spans both.
2. Branch on the affected-row count before doing anything else. Zero has three causes — stale version, wrong tenant, row gone — so re-read once and map to 409 carrying the current version, or 404 for an id outside the caller's tenant, which also stops the endpoint confirming that another tenant's id exists.
3. State the engine behaviour instead of assuming it. Under READ COMMITTED the second UPDATE blocks on the row lock, and when the first commits PostgreSQL re-evaluates the WHERE clause against the newly committed row, so the version predicate now fails and the statement reports zero rows. Under REPEATABLE READ the identical collision raises SQLSTATE 40001 instead, so the handler must fold both shapes into one conflict response.
4. Keep UNIQUE (resource_id, version) even though the predicate already serialises writers. It is what makes a lost update unwritable if any other path ever reaches the revision table, and it converts a logic bug into 23505 rather than into a silently missing history row.

Follow-up

• A client sends the version it read ten minutes ago and the resource has moved three versions. What is in your 409 so it can resolve the conflict without a full re-fetch?
• Two editors, two disjoint fields, no overlap. Does your answer still refuse the second write, and should it?

What programming languages are you most proficient in, and why?

Medium · Technical / Domain Questions

Approach

1. Lead with one primary language and back it with evidence: what I shipped in it, on which runtime (JVM, .NET, CPython) and how recently. Then rank the others honestly instead of listing everything I have touched.
2. Explain the 'why' through properties, not taste: static typing, IDE refactoring and mature tooling in Java or C# for large line-of-business codebases; Python for scripting, data movement and integration glue. Tie this to the Java, C# or Python requirement candidates report for this role.
3. Prove depth with one precise detail: C# async/await and using/IDisposable, Java generics and type erasure, or how the GIL in standard CPython builds stops threads running Python bytecode in parallel, so CPU-bound work goes to multiprocessing.
4. Name a bug class the language allowed and how I guard against it: null references (Optional, C# nullable reference types), Python's mutable default arguments, unchecked casts.

Follow-up

• If you had to write a service that reads from and writes to an ERP database, which of your languages would you pick, and why?
• Which feature of your main language would you keep out of production code?
• How does memory management differ between your two strongest languages?

Can you describe a recent project where you implemented a new technology?

Medium · Technical / Domain Questions

Approach

1. Open with the problem the existing tool could not solve, then the options I compared, including doing nothing, and the criteria: team skills, licensing and support, how well it fit the existing systems, and operating cost.
2. Explain how I reduced the risk: a spike on one narrow slice, a parallel run or feature flag next to the old path, and a rollback plan written before go-live.
3. Give one concrete integration problem I hit (authentication, a data-format or encoding mismatch, a version conflict) and exactly how I fixed it. Detail like this shows I did the work myself.
4. Close with a measured outcome and with adoption: documentation, handover, and who maintains it now. The answer that sinks this question describes the technology's feature list instead of my own decisions.

Follow-up

• What result would have made you abandon it?
• How did you get the rest of the team to adopt and maintain it?
• Knowing what you know now, would you choose the same technology?

What are the key differences between object-oriented and functional programming?

Medium · Technical / Domain Questions

Approach

1. State the core difference. OOP bundles state with behaviour in objects and controls change through encapsulated mutation. FP builds programs from pure functions over immutable data and keeps side effects at the edges.
2. Name the mechanisms on each side. OOP has encapsulation, inheritance and subtype polymorphism through interfaces and virtual dispatch. FP has first-class and higher-order functions (map, filter, reduce), immutability, referential transparency, and, where the language supports them, algebraic data types with pattern matching.
3. Give the trade-off known as the expression problem. With classes, adding a new type is easy (one new subclass) but adding a new operation means touching every class. With algebraic data types it is the other way round.
4. Give the practical consequences. Pure functions are easy to unit test and safe to run concurrently because nothing shared is mutated. Copying data costs allocations, which persistent data structures with structural sharing reduce.
5. Show that mainstream languages mix both styles: Java streams, lambdas and records (Java 16), C# LINQ and records (C# 9), Python comprehensions and functools. Note that Python has no tail-call optimisation, so deep recursion is not idiomatic there. Give one real example of replacing a mutating loop with a pipeline.

Follow-up

• What makes a function pure? Give an example of an impure function that looks pure.
• When would you prefer composition over inheritance?
• How does immutability help with concurrency, and what does it cost?

How would you approach designing a software solution for a new product feature?

Medium · Problem-Solving / Case Studies

Approach

1. Start with requirements: who uses the feature, the core user flows, functional versus non-functional needs (volume, latency, availability, security, audit), and what is explicitly out of scope, written as acceptance criteria.
2. Model the data before the code: entities, relationships and which system owns each record. If the feature touches an ERP system (candidates report ERP topics for this role), decide which side is the system of record and how sync conflicts are resolved.
3. Define the API contract (endpoints or messages, payloads, error responses, versioning) and pick the simplest architecture that meets the requirements, stating each trade-off: synchronous call versus queue, relational versus document store, build versus buy.
4. Plan delivery: a thin vertical slice behind a feature flag; unit, integration and contract tests; logs, metrics and alerts; and a rollout and rollback path.
5. Finish with the main risks and the measure that will show whether the feature worked.

Follow-up

• How would the design change if usage grew a hundredfold?
• What would you cut to ship a first version sooner?
• How do you change the API once other clients depend on it?

If you were given a legacy codebase to improve, what steps would you take?

Medium · Problem-Solving / Case Studies

Approach

1. Understand it before changing anything: get it building and running locally, trace the entry points and data flows, find the people who know it, and use git log churn plus bug history to find hot spots that change often and break often.
2. Build a safety net: characterisation (golden-master) tests that pin current behaviour, quirks included, before any refactor, and monitoring wherever it is missing.
3. Change it incrementally: introduce seams to break hard-wired dependencies so code becomes testable, refactor in small reviewable steps, and use the strangler fig pattern to route functionality to new code gradually rather than attempting a big-bang rewrite.
4. Prioritise by risk and value: unsupported or vulnerable dependencies first, then the modules with the most defects, then code that blocks upcoming features. Agree the order with stakeholders.
5. Measure progress with defect rate, build and deploy time, and test coverage of the areas I touched, and keep every change reversible.

Follow-up

• When would you argue for a full rewrite instead?
• How do you test code that calls the database or the system clock directly?
• How do you persuade stakeholders to fund refactoring time?

Describe a situation where you had to make a trade-off between speed and quality in your work.

Medium · Problem-Solving / Case Studies

Approach

1. Pick a real case where both options had a concrete cost. State what drove the deadline and what quality meant in that case: tests, edge-case handling, design cleanliness.
2. Explain the decision criteria: is the shortcut reversible, how large is the blast radius, and what does a defect cost in this area? Data integrity or financial records differ from an internal screen.
3. Show that I bounded the shortcut: what I refused to compromise (correctness, data migrations, security), what I deferred, and how I tracked it as a ticket with an owner, behind a feature toggle where possible.
4. Give the outcome and the follow-through: whether and when I paid the debt back, with numbers. The answers that sink this question are a shortcut taken with no plan, or a claim never to compromise.

Follow-up

• Did you go back and pay down the shortcut? How?
• Where would you refuse to cut corners whatever the deadline?
• How did you explain the risk to the people waiting on the work?

How would you handle a situation where a project deadline was at risk due to unforeseen issues?

Medium · Problem-Solving / Case Studies

Approach

1. Raise it early and quantify it: remaining work, a new estimate with a confidence level, and the cause, given as soon as the slip is visible rather than at the deadline.
2. Diagnose the type of problem: scope growth, an external dependency, or a technical unknown. Time-box a spike to turn the unknown into an estimate.
3. Present options with their trade-offs and a recommendation: cut or defer scope using must-have versus nice-to-have, ship in phases, add people only where the work splits cleanly (Brooks's law says adding people to a late project can make it later), or move the date. Let the stakeholder choose.
4. Carry out the new plan: track the critical path closely, keep the quality gates on whatever ships, and report status at an agreed rhythm.
5. Close with a retrospective: the early signal I missed, and the process change it led to, such as earlier integration or explicit buffers for external dependencies.

Follow-up

• What do you do if the date cannot move and the scope cannot be cut?
• How do you tell your manager about the slip without it sounding like an excuse?
• How would you make sure the same surprise does not happen again?

Provide an example of a complex problem you solved and the process you followed.

Medium · Problem-Solving / Case Studies

Approach

1. Choose a problem with real technical depth whose difficulty I can state in one sentence, such as data drifting out of sync between two systems, a slow query or batch job, or a concurrency bug.
2. Walk through the process: how I scoped it, which hypotheses I ruled out and with what evidence, and the tools I used (profiler, query plans via EXPLAIN, logs, tracing).
3. Explain the solution, the alternatives I rejected and why, and the cost of the chosen fix in complexity, performance or maintenance.
4. Quantify the result and how I verified it: a before-and-after metric, a regression test, and monitoring that would catch a recurrence.
5. Show what I generalised afterwards: a postmortem, a shared tool, or documentation that kept the next person from repeating the investigation.

Follow-up

• What was your hardest dead end, and how did you recognise it as one?
• If you had half the time, which steps would you skip?
• How did you confirm the fix did not introduce a regression?

How do you approach debugging and troubleshooting in your code?

Medium · Technical / Domain Questions

Approach

1. Reproduce first: get a minimal, deterministic reproduction and record the inputs, environment and version. If I cannot reproduce it, I add logging at the boundaries (inputs, outputs, external calls) until I can.
2. Read the whole error and stack trace and find the first point where state goes wrong, not the line where it finally crashes.
3. Narrow the search space by halving: git bisect between a known-good and a known-bad commit (git bisect run with a test script automates it in O(log n) steps), halve the input data, or set breakpoints and watch expressions instead of scattering print statements.
4. Test one hypothesis at a time with an observation that could disprove it, and change one variable at a time so the result is attributable.
5. Fix the cause, not the symptom: add a regression test that fails before the fix and passes after, and search for the same pattern elsewhere. For a production incident, mitigate first (roll back or disable the feature), then find the root cause.

Follow-up

• How do you debug a failure that only happens in production, where you cannot attach a debugger?
• How would you approach an intermittent failure such as a race condition?
• Walk me through using git bisect on a regression.

Suggested practice checklist

The plan follows the three reported stages and the question groups candidates report: fundamentals and coding first, then debugging and design scenarios, then behavioral stories, and a final run-through.

Day 1 — Map the loop and write your pitch

• Write out the three reported stages and mark what you still need to confirm with the recruiter, including whether the facility tour is part of your loop.
• Write a career summary naming your main language (Java, C# or Python), one web framework, one database and one project with a measurable result.
• Write a short glossary in your own words for ERP, manufacturing systems and operational technology, and note what you have actually used.

Deliverable: A written career summary and a one-page glossary with an honest note on your ERP and manufacturing exposure.

Day 2 — Linked lists and complexity

• Write the iterative linked-list reversal in your main language, then the recursive version, and test both on empty, single-node and long lists.
• Write the time and space complexity for each version and explain the cost of recursion in plain words.
• Explain aloud how you would state complexity for any solution you write.

Deliverable: Two tested reversal functions and a spoken complexity explanation for each.

Day 3 — Stacks, queues, search and error handling

• Solve two problems that use a stack and one that uses a queue, and write down why each structure fits.
• Outline how you would speed up search over a large dataset: sorted data with binary search, a hash index, a database index, and what each costs in memory and updates.
• Write how you would handle errors in a small function: validate input, raise or return errors consistently, avoid swallowing exceptions, and log with context.
• Work through the two database concurrency practice exercises to refresh your database habits.

Deliverable: Three solved problems, a one-page note on search trade-offs, and a short error-handling checklist.

Day 4 — Debugging, paradigms and design scenarios

• Write your debugging sequence and attach one real bug you have fixed to each step.
• Write a comparison of object-oriented and functional programming with one example from your own code for each.
• Outline answers for designing a new product feature and improving a legacy codebase: requirements questions, risks, small steps, tests added first, and how you would verify each step.

Deliverable: A debugging sequence with a real example, a paradigm comparison, and two outlined scenario answers.

Day 5 — Experience and judgment answers

• Prepare a Git answer covering your branching workflow, merge versus rebase, and one recovery or bisect story.
• Choose the project where you adopted a new technology and write what you evaluated, why you chose it and what you would change.
• Write the speed-versus-quality, at-risk deadline and complex-problem stories, each with a decision, a trade-off and an outcome.

Deliverable: Five written story outlines, each with a decision, a trade-off and a result.

Day 6 — Behavioral stories aloud

• Say aloud your stories for the significant challenge, prioritizing multiple projects, a difficult team member and contributing to team success.
• Prepare a short answer on what motivates you, tied to something you have actually done.
• Tighten each story so it names your own action and a stated result.

Deliverable: Five rehearsed answers, each with an action in 'I' and a stated result.

Day 7 — Full run-through and questions to ask

• Run a mixed mock: your pitch, a linked-list reversal, a debugging answer, one scenario and one behavioral story, all aloud.
• Write questions to ask about how the software connects to the physical operation and how changes reach production.
• List your two weakest answers and rework them.

Deliverable: A completed mock run, a list of questions to ask, and two reworked answers.

Behavioral stories for the Bobrick loop

The behavioral questions candidates report are about handling a hard project, ranking competing work, working through friction with a colleague, contributing to a team and what drives you. The reported role involves product managers and other engineers, and the typical experience level is 3-5 years, so each story should show a decision you made and what changed.

1. How would you handle a situation where a project deadline was at risk due to unforeseen issues?

Describe your experience with version control systems, such as Git.

Medium · Technical / Domain Questions

Approach

1. Anchor the answer in a real team workflow: how branches were organised (short-lived feature branches off a main branch, or trunk-based with feature flags), how changes reached review through pull requests, and how releases were tagged. Mention the checks that ran on each pull request.
2. Show command fluency with reasons: merge versus rebase (rebase to tidy your own unpublished branch, merge to keep shared history), interactive rebase to squash fixups, cherry-pick to carry a hotfix to a release branch, and revert for a pushed commit versus reset for local work only.
3. Include one diagnosis or recovery moment: git bisect to find the commit that broke a test, git reflog to recover work after a bad reset, or a conflict where both sides changed the same function and you re-ran the tests after resolving it.
4. If you have worked on configuration-heavy or packaged business systems, say how you kept configuration exports, scripts or database changes under version control, since not everything is plain source. Say it only if it is true.
5. Close with a practice you introduced or changed, such as a commit message convention, branch protection or a pre-merge check. The weak version is a list of commands with no workflow or consequence.

Follow-up

• When would you rebase and when would you merge, and what should you never rebase?
• A commit that breaks the build is already on the shared main branch. What do you do?
• How do you resolve a merge conflict safely in code you did not write?

Describe a time when you faced a significant challenge in a project. How did you handle it?

Medium · Behavioral / Leadership

Approach

1. Choose a challenge with real substance: a production defect with an unclear cause, a migration, an integration that kept failing, or a requirement that changed late. A heavy workload on its own is not a challenge story.
2. Use STAR but weight the Action: give the situation in two sentences, then spend most of the time on the options you weighed, why you chose one, and what you personally did as opposed to what others did.
3. Show how you reduced uncertainty: what you reproduced or measured, who you consulted, and what you tried that did not work. A story where the first idea worked hides your judgment.
4. End with a concrete result (error rate, a release date held, manual steps removed) and one thing you would change. If there is no number, state the observable outcome. A story with no resolution, or one that blames others, sinks the answer.

Follow-up

• What was the hardest decision in that story, and what were the alternatives?
• Who disagreed with your approach, and how was it settled?
• What would you do differently if you faced it again?

How do you prioritize your tasks when working on multiple projects simultaneously?

Medium · Behavioral / Leadership

Approach

1. Lead with a method, then prove it with a case: list everything competing for your time, rank by business impact and deadline, note dependencies and who is blocked on you, then decide what you do first, delegate, defer or decline.
2. Use one real collision, such as a production bug against a planned feature or two stakeholders who each call their request urgent. Say what you chose, what you gave up and who you told.
3. Show communication: you renegotiated scope or dates in writing before anything slipped, instead of going quiet. Name how you track work (a board, a short daily list) and when you re-rank.
4. Because the role involves product managers and other engineers, show that you ask which item matters more to the business this week instead of guessing. Answers like 'I work longer hours' or 'everything is a priority' sink this question.

Follow-up

• Two managers each say their task is top priority. What do you do?
• How do you protect time for important but not urgent work, such as tests or refactoring?
• Describe a time you ranked the work wrongly and how you recovered.

Tell us about a time you had to collaborate with a difficult team member. What was the outcome?

Medium · Behavioral / Leadership

Approach

1. Pick a real friction over working style or standards, such as missed handoffs, harsh review comments or a colleague who is hard to reach, and describe the behavior and its effect on the work in neutral words, not as a verdict on the person.
2. Show the order of your actions: you checked your own part first, spoke to the person directly and privately, agreed on something specific (review turnaround, decisions written down), and involved a manager only if that did not work.
3. State the outcome honestly: improved, partly improved or still unresolved, and how you adapted. Ending at 'it was fine in the end' leaves the question unanswered.
4. Keep the colleague credible in your story as a competent person with a different view; a villain makes you look like the problem.

Follow-up

• What did you learn about your own part in the friction?
• If the conversation had changed nothing, when would you escalate and to whom?
• How did you keep delivering while it was unresolved?

Can you give an example of how you have contributed to team success?

Medium · Behavioral / Leadership

Approach

1. Choose a contribution that changed the team's results, not only your tickets: a review habit that cut rework, a test or deploy script that removed a manual step, documentation that unblocked new joiners, or an integration you untangled for others.
2. Say 'I' for your own actions and name teammates for theirs. Describe the team outcome (a release held, fewer reopened bugs, shorter handoffs) and how you know your contribution caused it.
3. Add a cross-functional moment: product managers and other engineers are the partners candidates report, so include a time you explained a technical constraint to someone outside engineering in plain terms.
4. A story where the only subject is 'the team did' hides your role, and a hero story that leaves teammates out undermines the idea of team success.

Follow-up

• How did you know the change helped the team?
• What did a teammate do in that story that you could not have done?
• How would you contribute in your first months on a codebase you do not know?

What motivates you to perform well in your role?

Medium · Behavioral / Leadership

Approach

1. Name two or three specific, true drivers, such as finishing work that runs in production and is used by real people, learning an unfamiliar domain, or mentoring, and attach a short example to each so it does not sound rehearsed.
2. Tie it to this role honestly. The reported work places software next to manufacturing, ERP systems and physical products. If building software that supports physical operations appeals to you, say why with something you have actually done, and do not claim to share values you have not seen.
3. Keep it short. This question does not need a full STAR frame, but one two-sentence example prevents a list of adjectives.
4. Avoid 'I love challenges', reciting a mission statement, or naming only pay or title. Finish by connecting your motivation to the kind of work you would do in your first months.

Follow-up

• Tell me about a time your motivation dropped. What did you do?
• What kind of work drains you, and how do you handle it when it lands on your plate?
• What would make you want to leave a role?