Interview guides · Bekaert

Bekaert Software Engineer Interview Guide

Bekaert Software Engineer interview guide: five reported rounds, behavioral and steel-process questions, answer outlines and a 7-day preparation plan.

The 60-second brief

Bekaert works in steel wire transformation and coating technologies, so its software sits next to physical production lines rather than only next to office systems. Candidates describe the Software Engineer role as turning manufacturing processes into software: process modelling, shop floor data analytics, troubleshooting live manufacturing data and tools that remove bottlenecks. The work is done alongside materials scientists, mechanical engineers, process engineers and production managers, which is why the reported questions mix software judgement with steel-process knowledge.

This guide is for candidates interviewing for a Software Engineer position at Bekaert. It covers the five reported rounds, outlines for the four behavioral questions, a way to prepare the steel-process and reasoning questions candidates report, and a seven-day plan that ends with a full spoken run-through. It assumes you can already code; the preparation here is about explaining your work, reasoning aloud and connecting software to a production environment.

Candidates report five rounds over roughly four to six weeks: an HR Screening, a Technical Assessment, Face-to-Face Interaction, a Plant Tour and a Meeting with Engineers. Some accounts add that the pace can be faster when a role is urgent.

Focus areas

Technical interviewing (thought process)
Problem solving / reasoning
Solidification process (steel)

Overview

The reported questions fall into three groups. Four are behavioral: handling a senior colleague who rejects your idea, leading hourly workers without formal authority, explaining why you want this company and this position, and approaching an application the company has never handled before. Three are domain and structure questions: the solidification of a steel grade, the hot dip galvanizing process (with a request to describe your own relevant experience) and how to structure a solution to a novel technical challenge. Two more are reported as question types rather than single questions: scenario-based logic problems using physics or mathematics, and case studies on process optimization or troubleshooting.

Candidates describe the job as building software around physical processes. The listed responsibilities include turning technical specifications into code, troubleshooting problems in real-time manufacturing data streams, and working with non-technical colleagues to find bottlenecks that automation could remove. The requirements candidates describe are a solid grasp of the software development cycle, strong problem-solving and the ability to work across functions; industrial automation, data analytics, process engineering or earlier time in a manufacturing setting count as extras. Preparation therefore means two things: being able to explain your own engineering decisions to people who do not write code, and knowing enough of the steel process to talk about it without bluffing.

Because the loop reportedly ends with a plant tour and a meeting with engineers, treat the later rounds as conversations held on the factory floor, not as a whiteboard. Bring stories where a physical or operational constraint changed your design, prepare questions about where the data comes from and what happens when a sensor or line stops, and rehearse reasoning aloud with simple physics and arithmetic, stating units and assumptions as you go. The seven-day plan below spends two days on behavioral stories, two on the steel-process topics and one on reasoning and troubleshooting before a full mock.

The Bekaert interview process

Candidates describe the five rounds below, in this order, over roughly four to six weeks. Formats are not published, so the preparation advice is built from each round's name and what candidates say it covers.

HR Screening

Candidates describe this stage as an initial screening of your qualifications and fit for the role. Relocation has reportedly come up in past interviews for global roles, so settle your position before the call. Approach it as the first telling of your story: a clear walk through your CV, a specific reason for this company and this position, and plain answers on logistics.

What to demonstrate

Whether your background matches the Software Engineer role
Your reasons for applying to this company and position
Practical fit such as location, relocation and availability

How to prepare

Rehearse a spoken walk through your CV that ends on why a manufacturing-facing software role appeals to you, using the answer you built for the why-this-company question.
Decide in advance whether you would relocate and under what conditions, and be ready to say it plainly.
Write two sentences on what Bekaert makes (steel wire transformation and coating) in your own words, and tie one past project of yours to physical or operational data.
Ask the recruiter to confirm the remaining stages, locations and any site visit.

Technical Assessment

This stage is reported as an evaluation of technical skills relevant to the software engineering position. Candidates do not describe a fixed format, so prepare for both conversation and problem solving: your core stack, the development cycle you work in, and logic problems that use basic physics or mathematics. Narrate your reasoning, because the reported emphasis on thought process is stronger than on a single final answer.

What to demonstrate

Technical skills relevant to software engineering work
Ability to break an ambiguous problem into smaller parts
Use of basic physics and mathematics when reasoning about a problem

How to prepare

Pick one project you can defend end to end: requirements, design choices, testing, deployment and what failed, and practise explaining it to a non-programmer.
Practise the reported scenario-based logic questions aloud: restate the problem, list assumptions, estimate with round numbers, check units and sanity-check the result.
Rehearse a repeatable outline for the novel-challenge question: clarify the goal, split known from unknown, test the riskiest assumption first.

Face-to-Face Interaction

Candidates describe Face-to-Face Interaction as in-person meetings that may include visits to manufacturing facilities. The steel-process questions candidates report (solidification of a steel grade, hot dip galvanizing) are the kind of domain conversation to expect in a setting like this. Approach it as a professional conversation: concrete examples, honest limits to your knowledge and visible curiosity about the plant.

What to demonstrate

How you communicate in person with technical and non-technical colleagues
Depth of your own experience, including any process or manufacturing exposure
Willingness to engage with the physical side of the work

How to prepare

Write a one-page outline of how liquid steel solidifies (liquidus and solidus, the phases that form on cooling, why carbon content matters) and of the hot dip galvanizing sequence from surface preparation through the zinc bath to cooling.
Prepare an honest bridge sentence for domain gaps, for example naming the closest process or data work you have done and what you would ask a process engineer.
Confirm the meeting location and logistics in writing ahead of time, and carry a short list of project examples.
Prepare the new-application and rejected-idea stories so they are ready when the conversation turns to teamwork.

Plant Tour

Candidates describe a tour of the manufacturing environment intended to show you where the software will be deployed. It is a rare chance to see the machines, operators and data sources behind the requirements, so use it as discovery: notice how work flows, where measurements are taken and where people work around the current tools.

What to demonstrate

Your interest in the physical environment where the software runs
How you connect software to plant or product outcomes
How you interact with people on the floor

How to prepare

Before the visit, learn the broad stages of wire production and coating so the vocabulary on the floor is familiar.
Write five questions about data: which signals are measured, how often, how they reach software, what happens when a sensor drifts or a line stops.
Practise linking a technical idea to its plant impact, for example how a faster alert would change what an operator does.
Prepare your hourly-workers leadership story, since you may talk with operators during the visit.

Meeting with Engineers

This stage is described as a discussion with managing engineers about cultural fit and teamwork. The rejected-proposal and unfamiliar-application questions are the natural material here. Approach it as a working conversation between peers: share how you collaborate and disagree, and ask about how the team works.

What to demonstrate

Teamwork and how you handle disagreement
Communication style across levels
How you would approach problems the team has not met before

How to prepare

Have a rehearsed STAR story where a senior colleague rejected your idea, with what you changed and what you learned.
Prepare a case study from your own work on process optimization or troubleshooting, with the diagnostic sequence you followed and the measurable result.
Write questions for the engineers: how software and process engineers split responsibilities, how changes reach the line, and how issues are escalated.
Practise explaining a technical decision twice, once for an engineer and once for a production manager.

Where candidates lose points

Answering the solidification or hot dip galvanizing question with generic software language or a confident guess

Learn an outline of each process and say where your knowledge ends. For galvanizing, the question asks for relevant professional experience, so name the nearest process, data or equipment work you did instead of inventing a connection.

Defending your idea when a senior rejects it

Ask for the specific objection, restate it, and propose a small test or narrowed scope. Prepare a story that shows what you changed, including one where you turned out to be wrong.

Describing hourly-worker leadership as giving instructions or relying on a manager

Use a story where you spent time on the floor, explained the reason, involved operators in the tool and measured whether the change held. Show shared ownership.

Going silent or jumping to a number on a physics or mathematics scenario

Speak your assumptions, work with round figures, keep track of units and compare the result with a known sanity check. Practise this aloud, because the reported emphasis is on thought process.

Giving a generic reason for applying and treating the plant tour as a formality

Link your reasons to the role's listed duties and a past project with operational data, then arrive at the tour with questions about data sources, sensors and what happens when a line stops.

Questions & practice

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

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.
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.
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.
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?

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

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.
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.
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.
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?

Find overlapping job attempts and peak concurrency from lease records

Medium · sweep line · intervals · leases

A day of job_run history yields about 50,000,000 attempt records: (job_run_id, job_type, attempt, started_at, finished_at which is NULL when the worker died, lease_expires_at). Leases expire on a clock, so a job that outran its lease ran twice. Produce (a) every job_run_id whose attempts overlapped in wall-clock time and (b) the peak number of simultaneously running attempts per job_type with the minute it occurred. Target O(n log n). State how you treat a NULL finished_at and what clock skew does to your answer.

Approach

Define the interval before sorting anything: an attempt occupies [started_at, COALESCE(finished_at, lease_expires_at)). finished_at is observed and lease_expires_at is only a promise, so every attempt without a finish contributes an estimate and the whole result is a lower bound on overlap rather than an exact count.
For peak concurrency, sweep: emit 2n endpoints, sort by (timestamp, kind) with ends ordered before starts at equal timestamps, then walk the sequence maintaining a counter per job_type and record each type's maximum with its timestamp. O(n log n) dominated by the sort, O(n) space, or O(1) extra if the sort is external and the walk streams.
For overlap detection, do not compare attempts pairwise. A single global sort by (job_run_id, started_at) gives both the grouping and the order; within a group, keep the maximum end seen so far and report an overlap exactly when the next start is less than that running maximum, which is one linear pass after the sort.
Half-open intervals matter and are easy to get wrong: with closed intervals an attempt ending at the same millisecond another begins reads as concurrency two, and across 50,000,000 records that artefact swamps the real signal.

Follow-up

A handler is not idempotent and you have found 400 overlapping jobs. Which of them actually caused damage, and what would you query to find out?
Peak concurrency for one job_type is 4 against a configured cap of 4. Is the cap working, or is the data hiding attempts that never started?

Explain why the owner filter ignores the listing index

Medium · composite index · query plans · sort elimination

The only index on resource is (tenant_id, status, updated_at DESC, resource_id DESC). A new endpoint returns one user's resources across all statuses, newest created first: WHERE tenant_id = $1 AND owner_user_id = $2 ORDER BY created_at DESC LIMIT 20. On a tenant with 2M rows it takes 900 ms and EXPLAIN shows a sort above a large scan. Explain precisely why the existing index cannot serve it, give the index that can, and state which of these the new index still will not help: owner_user_id alone across tenants; the same query ordered by updated_at. PostgreSQL 16.

Approach

Separate the two jobs an index does. For filtering, a composite btree is seekable only on a left prefix, so with no predicate on status the scan can at best range over tenant_id and test owner_user_id per row; PostgreSQL 16 has no btree skip scan to jump the unconstrained column.
For ordering, the index is sorted by (status, updated_at) within a tenant and not by created_at, so the LIMIT cannot stop early: every matching row is read and then sorted. That is the 'Sort Method: top-N heapsort' line, and it is why the plan reads 2M rows to answer with 20.
Derive the replacement from the access path — equality, equality, then the ordering column: CREATE INDEX CONCURRENTLY ON resource (tenant_id, owner_user_id, created_at DESC). The scan seeks to the (tenant, owner) range and walks 20 entries in order, so the Sort node disappears along with the row-read.
Treat INCLUDE (title, status) as conditional, not free. An index-only scan still visits the heap for any row whose page is not marked all-visible, so on a table taking 1.2k writes/second the win depends on autovacuum keeping the visibility map current, and the wider index costs more on every insert.

Follow-up

90% of rows are status='active'. Would a partial index WHERE status = 'active' change your answer, and for which of the three queries?
A dashboard runs this for 40 owners in one page load. What changes about the design?

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

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.
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.
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.
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?

Describe the solidification process of our grade of steel, including approximate temperatures and phase charac

Medium · Technical and Domain Expertise

Describe the solidification process of our grade of steel, including approximate temperatures and phase characteristics.

Approach

Ask which grade and carbon content the question means first, because carbon decides the solidification path. If no grade is given, I walk through a plain carbon steel and say where alloying would change the picture.
Anchor the temperatures on the Fe-C diagram: pure iron melts at 1538 °C, the peritectic sits at about 1495 °C, and the liquidus drops as carbon rises. Between liquidus and solidus the steel is a mushy zone of solid dendrites in liquid.
Name the path by carbon content. Below about 0.09 wt% C the melt solidifies as delta ferrite (BCC) and turns to austenite (FCC) in the solid state. From about 0.09 to 0.53 wt% C the peritectic reaction L + delta -> austenite occurs. Above about 0.53 wt% C the melt solidifies directly as austenite.
Continue below the solidus. Austenite is stable down to about 727 °C, where eutectoid steel (about 0.77 wt% C) transforms to pearlite: lamellar ferrite plus cementite (Fe3C). Hypoeutectoid grades form proeutectoid ferrite first and hypereutectoid grades form proeutectoid cementite first. Faster cooling gives finer pearlite, or bainite or martensite if it is fast enough.
Cover cast structure and defects: chill, columnar and equiaxed zones, interdendritic segregation of C, Mn, S and P, centreline segregation and shrinkage porosity. Then name the measurements a process model would need: temperatures, cooling rates and chemistry.

Follow-up

Why are peritectic grades harder to cast continuously than low-carbon or high-carbon grades?
How does cooling rate change the final microstructure, and how would you represent that in a model?
Which sensor data would you want in order to predict a casting defect?

Describe the process of hot dip galvanizing and elaborate on any relevant professional experience.

Medium · Technical and Domain Expertise

Approach

Walk through the process in order. Surface preparation comes first: alkaline degreasing, rinse, acid pickling in hydrochloric or sulphuric acid to remove scale and rust, rinse again. Then fluxing, immersion in molten zinc, withdrawal, wiping, cooling and inspection.
Explain the metallurgy. The bath runs at roughly 450 °C (zinc melts at about 420 °C). The flux, typically zinc ammonium chloride, removes the last oxide film so the zinc wets the steel. Iron and zinc then diffuse into each other and form Fe-Zn intermetallic layers (gamma, delta, zeta) under an outer layer of nearly pure zinc (eta).
Say why the coating protects. It acts as a barrier, and because zinc is more electrochemically active than iron it corrodes sacrificially, so it still protects steel exposed at scratches and cut edges.
Name the controls and failure modes. Coating mass (g/m²) depends on immersion time, bath temperature, withdrawal speed and wiping. Silicon and phosphorus in the steel raise reactivity and can give thick, dull, brittle coatings. Poor cleaning or fluxing leaves bare spots. On continuous wire or strip lines, wiping after the bath trims the coating mass.
Answer the experience half honestly. If I have not worked on a galvanizing line, I say so, then connect my closest work (process data, quality measurement, sensor pipelines) to tracking coating mass, bath temperature and line speed against specification.

Follow-up

What would you check first if coating mass drifted above specification on one line?
How does continuous galvanizing of wire differ from batch dipping of fabricated parts?
How would you store and alert on coating-mass measurements so out-of-spec product is caught before it ships?

How would you structure a solution for a novel technical challenge?

Medium · Technical and Domain Expertise

Approach

Restate the problem and its constraints first: what the system must do, who will use it, a numeric success measure, and the hard limits in a plant setting such as safety, uptime and the equipment and data that already exist.
Break the problem into parts and rank them by uncertainty: data availability, sensor quality, latency, and integration with the machines and software already running. Then work on the most uncertain part first instead of the easiest one.
Look for prior art before building anything: an analogous problem in another domain, a standard algorithm, or an off-the-shelf tool. Compare two options on cost, risk and maintainability, and state which one I pick and why.
Test the riskiest assumption with the smallest experiment, such as a spike, a replay of recorded data, or a pilot on one machine or line. Define the success metric and a rollback path before it runs.
Close the loop: review results with the people who run the process, record the decision, and add monitoring so drift shows up. Ground the framework in one real example from my own work, with the outcome in numbers.

Follow-up

How do you decide between building a tool and buying one?
What do you do when the pilot results are ambiguous?
How would you bring operators who distrust the new system on board?

[Scenario-based logic problems involving physics or mathematics principles]

Medium · Problem-Solving and Logic

Approach

Write down the knowns, unknowns and units before any arithmetic, and state the assumptions (steady state, no losses, constant density). Check the units of the final answer, since dimensional analysis catches most slips.
Reach for conservation laws first: mass (volume flow is constant for an incompressible material), energy (Q = m·c·ΔT for heating; steel has a specific heat of about 0.46-0.5 kJ/kg·K and a density of about 7,850 kg/m³), and force balance.
Practise one worked example out loud, such as drawing wire. Drawing a wire from diameter d1 to d2 at constant volume multiplies its length and exit speed by (d1/d2)², so halving the diameter makes it four times longer and four times faster.
For estimation puzzles, use Fermi decomposition: split the quantity into factors I can bound, keep about one significant figure, and give a range rather than a falsely precise number.
Sanity-check the result against limiting cases, for example a dimension going to zero or a rate doubling. When I am stuck, I say the next step I am trying instead of going silent.

Follow-up

Which assumption matters most to your answer, and how would the result change if it were wrong?
How would you check this estimate against measured data?
Can you solve it a second way to cross-check the number?

[Case studies regarding process optimization or troubleshooting]

Medium · Problem-Solving and Logic

Approach

Turn the symptom into a metric with a baseline (throughput, scrap or defect rate, downtime), then establish when it changed and on which line, shift, product or material lot.
Check the data before the process. Sensor calibration drift, missing or duplicated readings, clock skew between machines and unit changes can all create a fake drop, so I compare against an independent count such as output actually shipped.
Narrow it down by segmenting and by Pareto analysis. Split the metric by machine, shift, lot and product, rank defect causes by count or cost, and work on the top one. For throughput, find the bottleneck station: the slowest step caps the line, so speeding up any other step does not raise output.
Separate signal from noise with a control chart (mean ± 3 sigma limits). A point outside the limits, or a long run on one side of the mean, suggests a special cause. Variation inside the limits is common cause, which needs a process change rather than a hunt for one event.
Change one variable at a time to test each hypothesis. Then confirm the fix with before-and-after data on the same metric, and add monitoring or an alert so a recurrence is caught early.

Follow-up

Defects rose in the same week a new material supplier and a new shift pattern started. How do you tell which one caused it?
What would you do if the sensor data has gaps exactly around the failures?
How would you roll out the fix without stopping production?

Suggested practice checklist

The plan opens with the loop map, spends two days on behavioral stories, two on the steel-process topics, one on reasoning and troubleshooting, and finishes with a full spoken run-through. Each day produces something you can reuse in the interview.

Day 1 — Map the loop and the role

List the five reported rounds in order (HR Screening, Technical Assessment, Face-to-Face Interaction, Plant Tour, Meeting with Engineers) and note what you will need for each.
Write a short paragraph on what Bekaert makes and what the Software Engineer role works on, in your own words, then list the projects of yours that involved hardware, sensor or operational data.
Sort the nine reported questions into behavioral, steel-domain and reasoning groups and mark your weakest group.

Deliverable: A one-page loop map, a company-and-role paragraph, a project list and a ranked list of the nine reported questions by weakness.

Day 2 — Stories for disagreement and leadership

Write a STAR outline for a time a senior colleague rejected your idea, including the objection, what you tested and the outcome.
Write a STAR outline for leading people without formal authority, ideally involving operators, technicians or another group not reporting to you.
Say each story aloud and trim until the key action and result come quickly.

Deliverable: Two STAR outlines (rejected idea, leadership without authority), each rehearsed aloud once.

Day 3 — Motivation and unfamiliar work

Write the answer to why you applied for this company and this position, linking duties in the role to a past project.
Decide and write down your stance on relocation and site time.
Outline how you would approach an application the company has never dealt with, then attach a real story where you did it.

Deliverable: A short spoken motivation answer, a stated relocation position and a novel-application outline with one supporting story.

Day 4 — Solidification of steel

Study the iron-carbon phase diagram and write an outline of how a steel melt solidifies: liquidus and solidus, the phases that form on cooling and how carbon content changes the path.
Look up the approximate temperatures for a typical carbon steel grade and note which numbers you are sure of and which you would present as approximate.
Explain the outline aloud as you would to a non-metallurgist, then to a materials engineer.

Deliverable: A one-page solidification outline with approximate temperatures, plus two spoken explanations at different technical levels.

Day 5 — Hot dip galvanizing and your experience

Write the process sequence: surface preparation (degreasing, pickling, fluxing), immersion in molten zinc, withdrawal and cooling, and how a zinc-iron coating forms.
Note quality variables you could discuss (coating thickness, adhesion, surface condition) and what data a software system could capture at each step.
Write your answer for the experience part: the closest relevant work you have done, or a plain statement of what you would ask a process engineer.

Deliverable: A galvanizing process outline, a list of data points per step and a written experience-bridge answer.

Day 6 — Reasoning and troubleshooting

Solve three physics or arithmetic estimation problems aloud (flow, heat, throughput or speed), writing assumptions and units before calculating.
Write your outline for structuring a novel technical challenge and test it on one example from your own work.
Walk through a troubleshooting case: a measured value on a data stream drifts. Order your checks (sensor and calibration, data pipeline, recent changes, the process itself) and what each rules out.

Deliverable: Three worked estimation problems, a novel-challenge outline and a troubleshooting checklist for a drifting data stream.

Day 7 — Full spoken run-through

Give your CV walk and motivation answer, then your two behavioral stories, without notes.
Explain the solidification and galvanizing outlines in sequence, then work one reasoning scenario aloud.
Write your plant-tour questions on data sources and failure handling, and your questions for the managing engineers.

Deliverable: A recorded or timed-by-you full run-through, a refined question list for the tour and a list of the two weakest answers to fix.

Behavioral stories for a plant-floor software role

Four behavioral questions are reported for this loop: a senior who rejects your proposal, leadership of hourly workers without formal authority, why you applied here, and handling an application the company has not dealt with before. Candidates also report that the STAR method (situation, task, action, result) is a useful frame. Prepare stories that show you listening, adapting and working across levels in a production setting.

Tell me about a time you persuaded stakeholders to adopt a technical approach they initially resisted.
Describe a time you explained a technical decision to someone outside engineering.

If you were to work with a senior and he rejects your proposal, how would you tackle it?

Medium · Behavioral and Interpersonal Skills

Approach

Use a real story in STAR form and open with the specific objection. Say how you found out why the senior disagreed: you asked for the concrete concern and restated it, before defending anything.
Separate the type of objection: technical correctness, risk or downtime cost, history you did not know, or a priority conflict. In a plant setting a rejected change often reflects the cost of stopping a line, so show you took that constraint seriously.
Show how you moved the idea forward without winning an argument: a small reversible pilot, a measurement, a prototype run off the live system, or a narrowed scope that addressed the concern.
State the outcome honestly. If the senior was right, say what you changed; if you proved the idea, say how the relationship stayed intact. Add a disagree-and-commit line and how you documented the decision.
Avoid the sinking mistakes: presenting the senior as an obstacle, saying you would go around them, or folding immediately with no attempt to understand.

Follow-up

What would you do if the senior's decision created a quality or safety risk?
What did the objection teach you that changed the proposal?
How did you work with that person afterwards?

How do you provide leadership to hourly workers without formal authority?

Medium · Behavioral and Interpersonal Skills

Approach

Choose a story with a shared outcome (fewer scrap events, less manual re-entry, a smoother handover) where you needed operators or technicians to change a routine and nobody reported to you.
Show influence mechanics: you went to the floor and learned how the work is really done, explained the reason for the change in terms of their daily work, and involved the people affected in shaping the tool or process.
Describe how you reduced the effort of adopting it: a pilot on one shift, a simple interface, a short walk-through at the line, and a named person who could answer questions.
Close with evidence that it stuck (usage, error counts, feedback) and credit shared with the team.
Avoid the mistakes: relying on a manager to push it, talking down to shift workers, or describing a change you announced rather than agreed on.

Follow-up

What did you do when someone refused to change how they worked?
How did you handle different shifts or teams with different habits?
How did you know the change was still working after you stepped away?

Why did you apply for us and why this position?

Medium · Behavioral and Interpersonal Skills

Approach

Structure the answer in three links: the company, the work, and you. Say plainly that Bekaert works in steel wire transformation and coating, that the role places software next to physical processes, and what in your history points to that kind of work.
Use specifics you can verify: the role's listed duties (turning specifications into code, troubleshooting live manufacturing data, finding bottlenecks with non-technical colleagues) and one past project where data from hardware or an operational process mattered.
Explain why this position rather than any software job: you want the effect of your code to show up on a line or in a product, and you are comfortable learning process knowledge from engineers.
Keep it short and conversational. Address practical points such as relocation honestly, because candidates report the topic has come up.
Avoid generic praise of size or reputation, and avoid an answer that would be identical for any employer.

Follow-up

What part of this role do you expect to be hardest?
Would you relocate, and are you comfortable spending time at a manufacturing site?
What would make you leave a role like this?

How would you deal with an application the company has never dealt with before?

Medium · Behavioral and Interpersonal Skills

Approach

First clarify what 'application' means: a new use case, a new machine or data source, or an unfamiliar software system. State what success looks like and who owns the process.
Describe a method: split the problem into known and unknown parts, list the assumptions that could break the plan, and test the riskiest one with the smallest spike or prototype before committing to a design.
Name the people you would consult early: process or production engineers for the physical behaviour, colleagues who ran similar projects, and the operators who will use the result.
Mention safeguards for a live environment: test on recorded data or an offline copy first, add logging and rollback, and agree checkpoints so scope changes are visible.
Ground it in a STAR story of your own where you faced unfamiliar work and what you learned. Avoid claiming you would work it out alone or that it is just like previous work.

Follow-up

How do you decide when to stop researching and start building?
What if a process engineer disagrees with your approach?
Tell me about a prototype that failed and what you did next.