BHP Software Engineer Interview Guide

The 60-second brief

BHP is a mining and resources company, and the Software Engineer role candidates describe sits where code meets physical operations. The work named for this role includes software for mining sites in South Australia, ventilation in underground mines and power systems, plus controls for electrical and instrumentation infrastructure. Day to day, candidates describe developing and maintaining that software, working out how it talks to sensors, controllers and machinery, upgrading older control systems, building monitoring dashboards and improving the data pipelines that feed site decisions.

This guide is for candidates applying to BHP as a Software Engineer, especially those from backend, embedded, data or platform work who need to translate that experience into an industrial setting. It covers the three reported rounds, the twelve reported questions (six reliability and design scenarios, six experience stories), the languages and tools candidates list, and a seven-day plan. It does not assume mining experience, which candidates describe as a nice-to-have rather than a requirement.

Candidates report three rounds over roughly 3-5 weeks: Initial Screening, Technical Deep-Dives and Behavioral Assessments. These stages are what candidates describe rather than a published process, and they say the loop can shift with location and seniority.

Focus areas

• Power Systems Engineering
• Electrical Engineering (E&I)
• Reliability Engineering

Overview

The reported questions show where the weight sits. Six are reliability and design scenarios: software controls for high-reliability hardware, keeping systems up in remote or mission-critical environments, integrating new software into legacy operational infrastructure, a reliability issue you found and fixed, rapid deployment versus system safety, and analysing large datasets to improve operational efficiency. The other six are experience stories about troubleshooting a failure, handling vague requirements, influencing other teams, juggling priorities, explaining a failure to a site manager, and building a safety culture. Several of the design-labelled questions are really asked as 'tell me about a time', so each needs a real project behind it, not a generic architecture talk.

The common thread is software that has to keep working next to physical equipment. Candidates describe sensors, controllers, remote sites and older instrumentation, and also report scenarios such as designing for a site with intermittent connectivity and doing a root-cause analysis on a recurring bug. Prepare answers that start from failure: what happens when the network drops, a sensor reports garbage, a deployment goes wrong, or the new system must run beside the old one. Concrete mechanisms (local buffering, idempotent retries, watchdogs, staged rollouts, rollback paths, alerts on silence) carry more weight than the word 'reliable'.

Candidates also report that people are part of the job: you work with electrical, mechanical and mining engineers, and the questions about site managers and cross-functional standards reflect that. Practise explaining a technical risk without jargon, in terms of what stops, what is at risk and what you need decided.

On the stack, candidates list Python, C++ or specialised industrial languages, solid grasp of the software development lifecycle and version control, and experience with large systems or industrial automation. Cloud or IoT platforms and data visualisation tools appear as nice-to-haves. None of the reported questions is an algorithm puzzle, so spend your time on design reasoning, debugging stories and clear communication rather than on coding drills.

The BHP interview process

Candidates describe three stages, and the descriptions below are what they report about each, with advice on how to prepare. Which question types you meet in which stage varies by team.

Initial Screening

Candidates report this as the opening conversation about your background and your interest in the position. No reported questions are tied to it, so treat it as the place to connect your experience to physical, operations-facing software and to show you have read the posting. Have a short account of your career that leans toward reliability, data or hardware-adjacent work, and a specific reason this role appeals.

What to demonstrate

• How your background maps to the role as listed
• Your interest in the position and the division
• Practical fit such as location, since candidates say many roles are site-based or hybrid

How to prepare

• Write a tight career walk-through that highlights one project where software touched hardware, data feeds or uptime
• Check the posting for the languages it lists (Python, C++ or an industrial language) and be ready to say where you have used each
• Find out whether the team works on mining, ventilation, power or logistics, and write one sentence on why that area interests you
• Decide your questions about site presence and hybrid expectations before the call

Technical Deep-Dives

Candidates describe detailed technical assessments. The reported technical material covers designing software controls for high-reliability hardware, uptime in remote environments, legacy integration, reliability incidents, deployment speed versus safety and large-dataset analysis; candidates also name fault tolerance, scalability and bridging modern software with older instrumentation as areas to know. Practise saying why you chose each mechanism, since candidates report the reasoning mattering more than abstract coding.

What to demonstrate

• Depth on fault tolerance, uptime and failure handling in realistic scenarios
• Ability to integrate new software with legacy instrumentation without disrupting operations
• Reasoning behind technical choices, including trade-offs between speed and safety
• Evidence from past work of finding and fixing reliability problems or analysing operational data

How to prepare

• Sketch an architecture for a remote site with intermittent connectivity: local buffering, store-and-forward with idempotent retries, clock handling and alerting on missing data
• Write a six-step root-cause routine for a recurring bug: reproduce, timeline, narrow the layer, test one hypothesis at a time, fix, add a guard
• Outline a staged rollout for a control-adjacent change: shadow mode, limited site, rollback trigger, safety checks before wider release
• Prepare one dataset story with the question, the data size, the method and the operational change that followed

Behavioral Assessments

Candidates report this stage as an assessment of alignment with core values and of team dynamics. The reported prompts include troubleshooting an electrical or instrumentation failure, ambiguity, influencing a cross-functional team, competing priorities, explaining a failure to a site manager and fostering a safety culture. Candidates also advise framing failure and design answers through safety and reliability, and using the STAR structure.

What to demonstrate

• Alignment with the values candidates describe, including safety and sustainability
• How you work with other engineering disciplines and non-technical site staff
• How you handle ambiguity, priorities and your own failures

How to prepare

• Build a story bank of five real examples that each end in a result you can describe, and map each to several prompts
• Rehearse each story aloud in STAR order with the decision you personally made in the middle
• Write a plain-language version of one technical failure as you would give it to a site manager
• Prepare a concrete safety or quality practice you introduced or improved, with what changed afterwards

Where candidates lose points

Telling a failure story that ends at the fix, with no root cause or prevention

For the troubleshooting and reliability questions, state how you isolated the layer, what evidence confirmed the cause, and what guard you added so it cannot recur silently. End with how you knew it stayed fixed.

Treating safety and reliability as a slogan instead of showing the mechanism

Candidates advise framing answers through safety, but a sentence about safety proves nothing. Name the concrete mechanism in each design answer: rollback path, staged release, alert on missing data, fail-safe default.

Assuming a reliable network and a clean greenfield in the design answers

Open every design scenario by asking what fails: connectivity at a remote site, an older controller you cannot change, a deployment that goes wrong. Design buffering, idempotent retries and a coexistence plan from the start.

Explaining a technical failure to a site manager in engineering vocabulary

Practise the version with impact first, then status, cause in one plain sentence and what you need from them. Test it on a non-engineer before the interview.

Giving influence and priority stories with no resistance, trade-off or number

Pick stories where someone disagreed or something was dropped. State what you gave up, who was affected and the result, so the story shows a decision rather than a process description.

Questions & practice

Canonicalise a request body into a stable idempotency fingerprint

Medium · parsing · canonicalisation · hashing

idempotency_key.request_fingerprint is a SHA-256 over the method, path and canonicalised body, and a retry whose fingerprint differs must be rejected with 422 rather than served the stored response. Write the canonicaliser. Bodies are JSON up to 256 KB nested at most 32 levels; clients vary key order, whitespace and unicode escaping, and some send 64-bit ids as JSON numbers. Produce a deterministic byte string such that semantically identical bodies match and any semantic difference does not. State your complexity and name two normalisations you refuse to perform.

Approach

1. Parse once into a tree, then re-serialise under fixed rules: object keys sorted, array order preserved, one escaping convention, no insignificant whitespace. Parsing is O(n) and sorting keys is O(k log k) per object, so O(n log n) overall with O(depth) stack, and the 32-level cap is enforced during parsing because hostile nesting is how a canonicaliser becomes a stack overflow.
2. Sort keys by their UTF-8 bytes and say why the obvious implementation is wrong in some runtimes: a default string comparison that orders by UTF-16 code units places surrogate pairs, meaning code points from U+10000 up, below U+E000 to U+FFFF, which is not UTF-8 byte order, so two services written in different languages disagree on the same document.
3. Do not re-encode numbers through a double. IEEE-754 binary64 represents integers exactly only up to 2^53, so normalising a 19-digit id through a float changes it, and 1 against 1.0 cannot be reconciled without deciding whether they are the same value. Preserve the literal token, and require ids as strings at the API boundary if you want them comparable.
4. Reject duplicate keys rather than picking one. JSON permits them and parsers disagree, most keeping the last, so any choice you make ties the fingerprint to a parser detail that the code handling the request does not necessarily share.

Follow-up

• A client sends the same logical request with an extra field your API ignores. Same key, different fingerprint, so you return 422. Is that the right answer?
• Where does the fingerprint get computed relative to request decompression and the body-size limit?

Diff a projection against the primary without per-row point reads

Hard · reconciliation · range hashing · throttling

The listing projection has drifted and some rows show a stale version. The primary holds 40,000,000 resource rows across 12,000 tenants while serving 1,200 writes and 14,000 reads per second. The obvious repair, reading each resource row and comparing its version against the projection, is correct and would eventually finish. Explain precisely why it is unacceptable here, then give a diff that finds the differing rows, state its complexity, and make it safe to run against a live primary. Replication lag is usually under 100 ms and is not bounded.

Approach

1. Quantify the naive cost rather than calling it slow: 40,000,000 point reads at even 0.5 ms each is over five hours serialised, and the only lever is concurrency, which is exactly what you cannot spend. The primary's pool is sized for the write path, and 40,000,000 random reads evict the buffer cache that sustains the 85 percent cache hit rate, so the audit degrades the system it is auditing.
2. Replace random access with one ordered pass per side. Both sides can be read in (tenant_id, resource_id) order, which is a sequential scan on each and a merge join in O(n) time and O(1) memory. For a dense diff that is the whole answer, and it reads the primary once instead of 40,000,000 times.
3. For the expected sparse case, compare range hashes instead of rows: partition the key space, compute per range an order-independent aggregate over hash(resource_id, version), compare aggregates, and descend only into ranges that differ. With d differing rows and branching factor B, at most d ranges mismatch per level, so the drill-down examines O(d log_B(n/d)) ranges and reads full rows only in mismatching leaves.
4. Aggregate with a sum modulo 2^64 or a multiset hash, never XOR. XOR is order-independent but self-cancelling, so two rows wrong in the same way, or a row duplicated on one side, leave the range aggregate matching and the range is declared clean.

Follow-up

• The diff reports 900 stale rows. How do you decide between patching those rows and rebuilding the projection from resource_revision?
• Same job, but the projection lives in a search index that cannot be scanned in key order. What changes?

Identify the heaviest tenants in a five-minute window under memory pressure

Medium · top-k · heavy hitters · streaming

The edge service handles about 3,000 requests per second across roughly 50,000 tenants, peaking near 9,000. Expose the 50 heaviest tenants by request count over the trailing five minutes so limits can be tightened before one tenant's backfill starves the fleet. You may not retain five minutes of raw records. Give the exact solution and its memory, then the bounded-memory approximation with its error stated as a formula, and say which you would ship and at what tenant cardinality that choice changes.

Approach

1. Do the exact version first, because it is affordable at this cardinality: a ring of 300 one-second counters per tenant, advanced lazily, is 1,200 bytes of counters per tenant and roughly 60 to 90 MB for 50,000 tenants with overhead. Carry a running total and subtract the bucket you overwrite so a window read is O(1) rather than 300 adds.
2. Extract the top 50 with a size-k min-heap over the tenant sums: O(d log k) for d tenants, against O(d log d) to sort them all. Maintaining the heap continuously instead of on query requires a tenant-to-heap-index map, because incrementing a count already inside the heap means sifting from a known position, and without that map you rebuild the heap on every request.
3. State the approximation precisely rather than gesturing at sketches. Misra-Gries with m counters retains every item whose true count exceeds N/(m+1), and each retained count underestimates the truth by at most N/(m+1). With m = 1,000 and N = 900,000 requests in the window the error is roughly 900 requests, which is fine for spotting a tenant sending 50,000 and useless for ranking two tenants 200 apart.
4. Say what breaks when the window slides: Misra-Gries and Space-Saving are insert-only and cannot be decremented as records age out. The workable construction is one summary per sub-window, say ten seconds, with 30 summaries merged at query time, and the merged error is the sum of the per-summary errors, so the bound degrades linearly in the number of sub-windows.

Follow-up

• The heaviest tenant is heavy because of one export job rather than user traffic. Should the limiter treat those as the same tenant?
• Two tenants sit tied at the boundary of the top 50. Does your answer flap, and does the flapping matter?

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?

Stop tag and share joins from fanning out a page

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

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

Approach

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

Follow-up

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

How do you approach the design of software controls for high-reliability hardware?

Medium · Technical and Domain Expertise

Approach

1. Start from a hazard analysis rather than from code: list the failure modes of each sensor, actuator and comms link (an FMEA), and define the safe state for each one. Usually that is de-energise-to-trip, so losing power or signal drives the output safe.
2. Keep safety functions separate from normal control. Interlocks and trips belong in an independent safety layer (IEC 61508 / IEC 61511 terms: a safety instrumented function with a SIL target), so a bug in the control or HMI code cannot defeat them.
3. Distrust every input. Check range, rate of change and staleness (a value frozen at a plausible number is the dangerous case), use redundant sensors with voting, and treat bad-quality data as a fault state with a defined response.
4. Make the control loop deterministic: a fixed scan cycle, no dynamic allocation or unbounded work inside the loop, an explicit state machine (startup, run, fault, maintenance) with guarded transitions, and a hardware watchdog that forces safe outputs if the loop stops kicking it.
5. Name the voting trade-off. 1oo2 trips if either sensor demands it (safer, more spurious trips), 2oo2 needs both (fewer spurious trips, less safe), and 2oo3 balances the two. Back the design with traceability from hazard to requirement to test, plus fault-injection and hardware-in-the-loop tests.

Follow-up

• What do you do when de-energising is not the safe state, for example a fan or pump that must keep running?
• How would you detect a sensor that has frozen at a normal-looking value?
• What happens if the watchdog or the safety controller itself fails?

What methodologies do you use to ensure system uptime in remote or mission-critical environments?

Medium · Technical and Domain Expertise

Approach

1. Put a number on it: availability = MTBF / (MTBF + MTTR). At a remote site MTTR is long because a person may need to travel, so the design has to cut failures and make recovery possible without anyone on site.
2. Remove single points of failure: active/standby hosts with automatic failover, a second network path (for example fibre plus cellular or satellite), UPS-backed power, and a quorum or witness so a broken link between the pair cannot cause split brain.
3. Keep the site autonomous. Local control must never depend on the WAN or the cloud. Telemetry goes through a bounded store-and-forward buffer with sequence numbers, so replay after an outage is idempotent and gaps can be detected.
4. Detect and heal automatically: process supervisors with restart policies, application and hardware watchdogs, health checks, and a heartbeat to central monitoring that alerts when it goes missing, not only on error messages. Add out-of-band management (a console server or IPMI) so a hung host can be recovered remotely.
5. Treat change as the main risk to uptime: staged rollouts, A/B system partitions or images so a bad update rolls back without a site visit, runbooks for the common failures, and planned failure drills to prove the failover works.

Follow-up

• How do you stop split brain when the primary and the standby lose contact with each other but both stay up?
• The site link is down for a week and the local buffer fills. What do you drop first, and how do you decide?
• How do you roll out security patches to hosts reachable only over a slow, metered link?

Explain your process for integrating new software solutions into legacy operational infrastructure.

Medium · Technical and Domain Expertise

Approach

1. Observe before touching anything. Inventory the protocols (Modbus TCP or RTU, OPC DA or OPC UA, serial), the register or tag maps, and which system writes to which device, then capture a traffic and load baseline. The first connection is read-only.
2. Put a gateway or adapter (an anti-corruption layer) between the legacy equipment and the new software, so the new code sees a clean, versioned interface and the legacy protocol quirks stay in one place. Replace functionality piece by piece in strangler-fig style instead of a big-bang cutover.
3. Respect the legacy limits: older PLCs and RTUs handle few connections and limited polling, so one gateway polls at a controlled rate instead of many clients. Plain Modbus has no authentication, so keep OT and IT in separate network zones with a DMZ (Purdue model / IEC 62443 thinking).
4. Run the new system in shadow mode first. It computes its outputs and compares them with the legacy system's without acting, against agreed acceptance criteria for divergence. Only then does it get write access, behind a switch that restores the legacy path.
5. Plan the cutover as an operation: a maintenance window, a tested rollback, operator training and updated documentation. Name the trade-off of a longer parallel run (more cost, lower risk).

Follow-up

• The legacy system has no documentation. How do you work out its register map safely?
• How do you prove the new system behaves like the old one before you let it write to equipment?
• What do you do if the legacy controller cannot handle the extra polling load?

Walk us through a scenario where you identified a critical reliability issue; how did you resolve it?

Medium · Problem-Solving and Reliability

Approach

1. Choose an incident you drove, and open with how it was detected (an alarm trend, repeated restarts, a gap in data) and its measured impact: downtime, lost data, or the safety exposure.
2. Show the diagnosis method, not only the answer: build a timeline, list hypotheses, reproduce the failure or narrow it with logs and metrics, and push past the first symptom with five whys or a fault tree until you reach a cause you can test.
3. Describe the fix in layers: immediate mitigation to restore service, the root-cause fix, and better detection so the same failure is caught earlier next time.
4. Prove it worked with before-and-after numbers over a long enough period to cover the conditions that triggered it, and say how you checked the same flaw was not present in similar systems.
5. The answer that sinks this question is a fix with no evidence it addressed the cause. Close with what the blameless review changed in process, tests or monitoring.

Follow-up

• How did you know you had found the root cause and not a correlated symptom?
• What would you have done if you could not reproduce the failure?
• What did you change so that the next engineer would catch it sooner?

How do you balance the need for rapid deployment with the requirement for absolute system safety?

Medium · Problem-Solving and Reliability

Approach

1. Reject the either-or framing by classifying changes by consequence. A dashboard or reporting change can ship fast; anything that touches control logic, interlocks or setpoints goes through management of change, independent review and re-verification.
2. Make the fast path safe through automation: CI with unit tests, static analysis, simulation or hardware-in-the-loop tests and small batches, so speed comes from short feedback loops and not from skipped checks.
3. Use progressive delivery: feature flags off by default, shadow mode, a canary on one asset or site before the rest, automated rollback triggers, and for controllers a deployment inside a maintenance window with a tested rollback image.
4. Architect for it: independent safety interlocks mean a fast-moving application layer cannot defeat them, which is what makes frequent releases above that layer acceptable.
5. Measure both sides: change failure rate and time to restore next to deployment frequency, plus safety incidents and near misses. State plainly that when the two conflict, safety wins and the plan absorbs the delay.

Follow-up

• An urgent fix is needed but the safety review will take days. What do you do in the meantime?
• How do you test a change that can only be fully validated on live equipment?
• Who should have the authority to stop a release, and how would you set that up?

Describe a challenge where you had to analyze large datasets to improve operational efficiency.

Medium · Problem-Solving and Reliability

Approach

1. Start from the operational metric and the decision it feeds (throughput per hour, energy per unit produced, unplanned downtime), with a baseline and a target, before describing any tooling.
2. Show you handled sensor data properly: resample to a common interval, align clocks and time zones, treat gaps and stuck values explicitly, check units and sensor drift, and handle outliers deliberately instead of silently deleting them.
3. Match the tools to the size of the data: columnar storage such as Parquet partitioned by time and asset, aggregate before joining, and pandas or Polars on one machine versus Spark or SQL in a warehouse once the data does not fit in memory.
4. Analyse beyond averages: segment by asset, shift and operating mode, look at distributions and time-of-day patterns, and watch for confounders such as production rate or season. A before/after comparison needs a control group or an adjustment for those confounders.
5. Close with the measured result and how you made it last: the effect with its uncertainty, a pilot on a subset before the full rollout, and a pipeline or dashboard so the improvement keeps being tracked.

Follow-up

• How did you separate the effect of your change from normal seasonal or production variation?
• How did you decide the data quality was good enough to act on?
• What did you do when the data no longer fit on a single machine?

Every query on one table stalls for forty seconds mid-deploy

Medium · lock contention · ddl · migrations

During a release on PostgreSQL, every query touching resource times out for about 40 seconds and then recovers with no intervention. The release ran one migration, ALTER TABLE resource ADD COLUMN archived_reason TEXT, and the migration log shows it completing in 6 ms. Unrelated tables showed no change in error rate. Explain how a 6 ms statement caused a 40-second stall, give the ordered checks you would run on a live system to confirm it, and give the migration procedure that prevents a repeat.

Approach

1. Separate the statement's duration from the lock's duration. ADD COLUMN with no default is a catalogue-only change and genuinely runs in milliseconds, but it requires ACCESS EXCLUSIVE, and it cannot acquire that until every transaction already touching the table has finished.
2. Account for the queueing, which is the part that surprises people. A lock request that is waiting blocks later requests for conflicting modes behind it rather than letting them overtake, so one long-open transaction holds the DDL and the DDL holds all the traffic. The stall length is set by the longest open transaction, not by the size of the change.
3. Confirm on a live system in this order: pg_stat_activity for that table ordered by xact_start, looking for the oldest transaction and specifically for state = idle in transaction; then pg_locks where granted = false to find the waiter; then join them on pid to name blocker and blocked. pg_blocking_pids() does that join for you and is the fastest single call.
4. Prevent rather than merely time it better. Set lock_timeout to a second or two on the migration session so the DDL abandons the queue after a bounded wait and is retried, instead of holding it for as long as the oldest transaction lives. Be exact about what that buys: queries arriving during the wait still queue behind the pending ACCESS EXCLUSIVE request, so each attempt costs them up to one lock_timeout of added latency. The outage goes from 40 seconds to about one second per attempt, not to zero. Also run migrations away from deploy-time peaks, and put a statement timeout and an idle-in-transaction timeout on the analytics role that opens the long transactions.

Follow-up

• The same release also wants NOT NULL on that column. What is the sequence that gets there without a long lock?
• Your lock_timeout retry fails ten times in a row because the analytics transaction is always open. What do you change?

Suggested practice checklist

The plan follows the three reported rounds: map the loop and the site context first, then build a story bank, then practise the reliability and design scenarios, then the data and debugging story, then run the behavioral questions aloud and finish with a full pass.

Day 1 — Map the loop and the asset

• Write the three reported rounds on one page, then sort the twelve reported questions into reliability and design scenarios versus experience stories.
• Read the posting and note which of Python, C++ or an industrial language it lists, whether the role is site-based or hybrid, and whether the team works on mining, ventilation, power or logistics.
• List your projects that touched hardware, sensors, uptime, legacy systems or operational data.

Deliverable: A one-page loop map, a question sort by type, and a project list tagged by which reported question each could answer.

Day 2 — Build the story bank

• Pick five stories from your own work and write each in STAR order with the decision you personally made and a measurable result.
• Map each story to the failure-troubleshooting question, the reliability-issue question and the ambiguity question, and note gaps.
• Replace any story you cannot support with evidence, such as a ticket, a metric or a postmortem.

Deliverable: A five-row story table with situation, your decision, result and the reported questions each story can answer.

Day 3 — Reliability design aloud

• Answer the high-reliability control design question and the remote-uptime question aloud, covering failure modes, redundancy, watchdogs and alerting.
• Sketch a remote site with intermittent connectivity: local buffer, store-and-forward, idempotent retries, timestamps and what the site does while offline.
• Write down the first three things you would check when a site goes silent.

Deliverable: Two spoken answers and one architecture sketch that shows buffering, retry and alerting for an offline site.

Day 4 — Legacy integration and safe deployment

• Outline how you would add a new monitoring service beside a legacy control system: read-only first, shadow mode, comparison with the old output, then limited cutover.
• Write a release checklist with a rollback trigger, a safety review step and a stop condition, then answer the rapid-deployment versus safety question using it.
• Name two things you would refuse to speed up and the reasoning for each.

Deliverable: A staged-integration outline and a one-page release checklist that you can quote when answering.

Day 5 — Data analysis and root-cause practice

• Write your large-dataset story: the question, data volume, method, validation and the operational change that followed.
• Work the practice SQL drill on version gaps and lag with window functions to keep your data skills sharp.

Deliverable: One written dataset story with a number attached, plus a spoken root-cause narration from the debugging drill.

Day 6 — Behavioral stories aloud

• Say the failure-troubleshooting, ambiguity, cross-functional standard and competing-priorities stories aloud, in order, and record them.
• Cut each to its decision and result, and remove any sentence that describes what the team did instead of what you did.
• Add the strongest objection or trade-off to each story.

Deliverable: Four recorded answers, each with the decision and a named trade-off or objection.

Day 7 — Plain language, culture and full run-through

• Write and say a failure explanation for a site manager: impact, status, plain cause, what you need.
• Prepare your safety and continuous-improvement example with the mechanism and its result.
• Run one pass through all three rounds: the career walk-through, two design answers, and two behavioral stories.

Deliverable: A one-paragraph manager briefing, a safety-practice example and a complete round-by-round run-through.

Behavioral and operations-facing stories

Candidates report that the final stage looks at alignment with core values and team dynamics. For this role the prompts centre on failures in physical systems, working with other engineering disciplines, and explaining problems to site staff. Prepare stories where you made a decision, say how safety or reliability shaped it, and give the result.

Describe a time you had to troubleshoot a complex failure in an electrical or instrumentation system.

Medium · Technical and Domain Expertise

Approach

1. You may not have electrical engineering experience, so choose the nearest honest equivalent: a failure at the boundary of software and a device, sensor, network link or controller, such as telemetry gaps, wrong readings or a device fleet dropping offline. Do not claim electrical work you did not do.
2. Structure it as symptom, blast radius, hypotheses, isolation, root cause, fix, prevention. Spend most of the time on isolation: how you narrowed the chain (sensor, signal, gateway, ingest, application) by comparing timestamps, swapping a component, replaying captured data or testing one layer alone.
3. Name the evidence that closed each hypothesis, such as a log line, a packet capture or a reading from a spare unit. A story that ends in 'I restarted it' has no root cause, so say what actually failed and how you confirmed it.
4. Close with prevention: an alert on silence, a validation check on sensor ranges, a runbook entry or a regression test, plus how you knew the failure stopped recurring.

Follow-up

• How did you rule out the software before blaming the hardware, or the reverse?
• What would you instrument differently so you would find it faster next time?
• Who else did you need to involve to fix it, and what did you hand them?

How do you handle ambiguity when system requirements are not fully defined at the start of a project?

Medium · Problem-Solving and Reliability

Approach

1. Pick a project where requirements really were open. Say what was unknown in one sentence, then show how you reduced the uncertainty rather than waiting for it to go away.
2. Describe concrete moves: list assumptions and rank them by cost if wrong, ask the person who can answer the top ones, write the agreed assumptions down and send them back for confirmation, and build the smallest slice that tests the riskiest one.
3. Show you kept decisions reversible: interface boundaries, configuration over hard-coding, a short feedback loop with the stakeholder after the first slice.
4. Include what changed when an assumption proved wrong and the cost. Avoid two failure modes: stalling until everything is specified, or guessing and building everything before checking.

Follow-up

• Which assumption turned out wrong, and what did it cost you?
• How did you decide when you knew enough to start building?
• How do you handle ambiguity differently when safety is involved?

Tell us about a time you had to influence a cross-functional team to adopt a new technical standard.

Medium · Behavioral and Leadership

Approach

1. Choose a case where you had no authority over the other team, such as a logging format, a review checklist, a naming convention for signals or a deployment standard. Say who needed to adopt it and why they would not just agree.
2. Start from their pain, not your preference: find what the standard fixed for them, such as fewer false alarms or faster handover, and quantify it if you can. Describe how you listened to objections and changed the proposal in response.
3. Lower the cost of adoption: a pilot with one friendly team, a template or tooling that made the standard the easy path, and a migration path for existing work. Show the result with a measure of uptake or a problem that disappeared.
4. Be honest about the resistance. A story where everyone agreed immediately, or where you simply mandated it, does not show influence.

Follow-up

• Who pushed back hardest, and what did you change because of them?
• How did you measure whether the standard was actually being followed?
• What would you do if the team had still refused?

How do you manage competing priorities when working on multiple high-impact engineering projects?

Medium · Behavioral and Leadership

Approach

1. Give a real situation with at least two projects competing, and state the stakes of each: what breaks, who is waiting and by when. Vague busyness is not an answer.
2. Explain your sorting method in specific terms: safety or reliability risk first, then cost of delay, then dependencies and effort. Show you checked with the people who own each priority instead of ranking alone.
3. Describe a trade-off you made and communicated: one item deferred, one scoped down, one delegated, with the reason told to whoever was affected.
4. Finish with the outcome and what you learned, such as a standing weekly review of the list or an agreed escalation path. Avoid answers that rely only on working longer hours.

Follow-up

• What did you drop or delay, and how did that person react?
• How do you handle an urgent request that arrives mid-project?
• How would your approach change if one task affected site safety?

Describe a situation where you had to explain a complex technical failure to a site manager or operational lea

Medium · Behavioral and Leadership

Describe a situation where you had to explain a complex technical failure to a site manager or operational lead.

Approach

1. Choose a failure with real impact on operations and name who needed to hear about it. Show you adjusted the message for them: they want to know what stopped, what is at risk, what is being done and what you need from them, not the stack trace.
2. Lead with impact and status in plain words, then the cause in one sentence they can repeat, then the fix and the next update time. Show the actual words, for example 'the sensor feed stopped updating, so the dashboard showed old data; I have switched to the backup feed and will confirm by afternoon'.
3. Be honest about uncertainty: say what you know and what you are still checking. Do not assign blame, and do not hide your team's share of the cause.
4. Cover follow-through: a written summary afterwards, the change that prevents a repeat, and how the manager's reaction or decision shaped your next step.

Follow-up

• What did you leave out of the explanation, and why?
• How did you handle it when you did not yet know the cause?
• Did the manager push back or change a decision because of what you said?

How do you foster a culture of safety and continuous improvement within your engineering team?

Medium · Behavioral and Leadership

Approach

1. Anchor the answer in mechanisms you actually ran, not slogans. Examples: blameless post-incident reviews with tracked actions, a pre-release safety or rollback checklist, a way for anyone to report a near miss, code review rules for risky changes.
2. Show how you made the habits stick: you modelled them, you made reporting safe by not punishing people who raised problems, and you followed actions to closure instead of letting them lapse.
3. Tie it to a result such as fewer repeat incidents, quicker detection, a bug caught by the checklist or a near miss reported before it mattered. Tell it as one story, not a list of principles.
4. If you have not led a team, describe what you did as an individual contributor: raised a risk, improved a review, wrote the runbook. Candidates report framing answers through safety and reliability, so show it in decisions you made.

Follow-up

• How did you get teammates to report near misses rather than hide them?
• What improvement did you push that the team initially resisted?
• How do you tell whether the culture is improving or just compliant?