The reported question set for BASF is mostly experience-based and open-ended. Five questions are behavioral stories: the introduction, working under pressure, a difficult stakeholder, preferred work environment, and leadership or an inclusive mindset. The rest ask how you work: your CI/CD experience with Jenkins and GitHub Actions, test plan creation and test case management, an automation test strategy for a data-driven application, debugging legacy code under deadline pressure, handling a vague requirement, a plant digitalization case, a recent project and its architecture trade-offs, prioritizing competing deliverables, and learning a new language or framework. None of the reported questions is an algorithm or data-structure puzzle, so preparation is about being specific on real engineering work, not grinding problem sets.
Reported loops weight CI/CD, performance testing, Jenkins, test case management and problem solving most heavily. The take-home is described as a three-day project involving programming, test case management or CI/CD setup. Because that description names three possible emphases, build one small repository that exercises all of them: a program in Python, Java or JavaScript (the languages the requirements list), a written test plan with structured test cases, and a pipeline that runs the tests on every push. That repository then doubles as material for the panel, because you have a real pipeline to describe stage by stage.
The requirements candidates describe list industrial automation and control systems as nice-to-have rather than must-have, so prepare to reason from software fundamentals instead of claiming plant expertise you do not have. What you can bring is a clear view of software that touches physical operations: what a failed deployment means for the people running a plant, why every change needs a rollback path, and how data from machines and enterprise systems ends up on a dashboard. Read about how manufacturers connect software to production, and treat the manufacturing and digitalization questions as reasoning exercises where you state assumptions first.
Panels with various stakeholders and a full-day group assessment mean the same stories reach different audiences. Candidates report that behavioral questions in the panels follow the STAR pattern, with conflict resolution, inclusive teamwork and adaptability named as themes. Prepare each story at two depths: a short version for a non-technical listener and a longer one with the technical decisions, so you can adjust to whoever is across the table.
HR Phone Screening
reportedCandidates describe this as an initial call to confirm basic eligibility, your background and your salary expectations. Nothing technical is reported for this stage, so the work is logistics and a clean introduction. Settle your salary expectation before the call from local market research, know your notice period and location constraints, and have your eligibility facts ready. Use the call to ask which of the later stages apply to your team and region, whether the take-home is part of your loop, and which languages the interviews may use.
What to demonstrate
- Basic eligibility for the role
- A concise account of your background
- Whether your salary expectations fit the role
How to prepare
- Write the introduction in three beats: what you build now, one project with a result that involves testing or automation, and why industrial software interests you.
- Prepare a salary expectation range you can justify, plus notice period and location constraints.
- Write three questions for the recruiter: the remaining stages, whether a take-home applies, and the work arrangement for the plant or office you would join.
Panel Interviews
reportedCandidates describe a series of interviews, held virtually or on-site, with various stakeholders. Behavioral questions are reported as the main emphasis, with conflict resolution, inclusive teamwork and adaptability named as themes, alongside technical discussion of CI/CD, test plans and performance testing. Because the audience varies, expect to explain the same project to engineers and to people outside software. Prepare a bank of STAR stories and a short technical walk-through of one real pipeline you have built.
What to demonstrate
- Behavioral competencies reported for panels: conflict resolution, inclusive teamwork, adaptability
- Technical discussion of CI/CD with Jenkins or GitHub Actions, test plans and performance testing
- Explaining past projects clearly to a mixed audience
How to prepare
- Build five STAR stories: pressure, a difficult stakeholder, changing requirements, leadership or inclusion, and a missed deadline or failure.
- Rehearse a pipeline walk-through naming each stage, what it protects against, and one thing you measured or improved.
- Practise explaining one technical decision to a non-technical stakeholder in plain words.
- Write an answer to the test plan and performance testing question with scope, risks, test levels and pass criteria.
Take-Home Technical Challenge
reportedCandidates describe a three-day project involving programming, test case management or CI/CD setup. The description does not say which of the three you receive, so a small repository covering all of them is the safest preparation. Use a language from the requirements (Python, Java or JavaScript), write unit tests, add structured test cases and a short test plan, and configure a pipeline in GitHub Actions or Jenkins that runs on every push. Finish with a README that states how to run everything from a clean checkout and which trade-offs you made.
What to demonstrate
- Working code that runs from a clean checkout
- Test design and test case management as a written artifact
- A pipeline configuration that builds, tests and reports
- How clearly you explain your trade-offs in the write-up
How to prepare
- Rehearse the project once end to end: scaffold and tests first, pipeline second, README and cleanup last.
- Keep a reusable GitHub Actions workflow and an equivalent Jenkinsfile so the pipeline step is quick.
- Clone your own repository into an empty folder and run the README steps before submitting.
- Write a short section on what you left out and why, so the scope looks deliberate.
Group Assessment Center
reportedCandidates describe a full-day assessment in which candidates collaborate to solve problems. No exercise format is reported in more detail, so prepare the skills any group problem needs: restating the goal, stating assumptions, splitting the work, and keeping every voice in the discussion. The reported digitalization question about optimizing efficiency in a manufacturing plant and the ambiguous-requirement question are good rehearsal material, since both are open-ended and reward a visible structure.
What to demonstrate
- Collaboration with other candidates on shared problems
- Breaking down an open-ended problem in a visible structure
- Communication and inclusion within a group
How to prepare
- Practise a group problem with two or three people: restate the goal, list assumptions, assign parts, then check in on progress.
- Prepare the plant digitalization case as a structure: data sources, the users, the first measurable improvement, the risks.
- Have one story ready about drawing in a quieter teammate or resolving a disagreement inside a team.
PracHub editorial advice for the preparation topics above.
Answering the CI/CD experience question with a list of tool names (Jenkins, GitHub Actions) and no pipeline you actually shaped
Pick one pipeline and walk through its stages, what each stage prevents, what failed once, and what you measured when you fixed it. If you have used only one tool, say so and explain the concept mapping.
Treating the test plan and performance testing question as a list of test types
Structure the answer: scope, main risks, test levels, test data and environments, how cases are written and tracked, and for performance a workload model, a baseline and a pass threshold you would agree before running anything.
Submitting a take-home that works on your machine but fails from a clean checkout, or whose pipeline is red
Clone the repository into an empty folder, follow the README exactly, and watch the pipeline pass before you submit. Pin dependency versions and list the run commands.
Telling behavioral stories in the plural ('we decided') so the panel cannot see what you personally did
For each story, write one sentence on your decision, one on your action and one on the result. Keep the team context short and name the trade-off you accepted.
Answering the plant digitalization, legacy debugging and prioritization questions like generic web-app questions
State operational constraints first: who relies on the system, what a failure costs them, when changes can be released, and how you roll back. Then give your debugging order or priority rule.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
Walk us through your problem-solving process when faced with a vague or ambiguous technical requirement.
Walk us through your problem-solving process when faced with a vague or ambiguous technical requirement.
Approach
- Restate the requirement as a problem and a user: who uses the result, what decision or task it supports, and what done looks like. Ask those questions before choosing any technology.
- List the unknowns and sort them into blocking ones (ask now) and safe ones (assume, write down, confirm); turn the agreed version into acceptance criteria, for example Given/When/Then statements, and send them back in writing.
- Reduce risk with a thin vertical slice or prototype shown early, so feedback arrives before the design hardens; keep the parts built on weak assumptions easy to change, for example behind configuration.
- Back it with one concrete story: the vague request, the questions you asked, the assumption that turned out wrong, and what the early slice saved compared with building the full version first.
- Cover the hard case: when stakeholders disagree or nobody can answer, pick a sensible default, record who agreed to it, and make the decision visible rather than silently choosing.
Follow-up
- The stakeholder changes the requirement after you have built half of it. What do you do?
- How do you decide which assumptions are safe to make without asking?
- Give an example where an early prototype showed the requirement itself was wrong.
Canonicalise a request body into a stable idempotency fingerprint
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
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
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?
Replace offset paging on the resource feed with keyset
resource holds resource_id, tenant_id, owner_user_id, title, body_ref, version, status ('draft','active','archived','deleted'), created_at, updated_at, deleted_at, with an index on (tenant_id, status, updated_at DESC, resource_id DESC). The listing endpoint returns active resources for one tenant, newest update first, 50 per page, today with LIMIT 50 OFFSET n. Tenants reach page 400 and rows are created while they read. Write the keyset query, define what the cursor carries and how it is encoded, and say which part of the index each predicate uses. Assume PostgreSQL 16.
Approach
- Name the two failures separately. OFFSET 20000 makes the server produce and discard 20,000 rows, so page cost grows with depth rather than with page size. Independently, any write that changes how many rows sort above the offset moves the window between two fetches, and the direction decides which anomaly you get: an insert lands at the head of updated_at DESC and pushes already-returned rows down past the boundary, so they are returned a second time; a delete above the offset, or a row whose updated_at is bumped above the cursor, pulls rows up and one is never returned at all. Nothing in the response reveals either.
- Write the seek: WHERE tenant_id = $1 AND status = 'active' AND (updated_at, resource_id) < ($2, $3) ORDER BY updated_at DESC, resource_id DESC LIMIT 50. The row-value comparison is one index range rather than a disjunction, and both columns are NOT NULL, which is what makes that comparison well defined.
- Map each predicate onto the index: tenant_id and status are equality on the leading columns, (updated_at, resource_id) is the range, and the ORDER BY matches the index order so no Sort node appears and the scan stops after 50 rows. The DESC in the definition only matters for mixed directions — a plain ascending btree on the same columns is read backwards for this query.
- Put both sort columns in the cursor and nothing the client can tamper with into another tenant: base64 of (updated_at, resource_id), validated server-side, with tenant_id taken from the principal.
Follow-up
- The client asks for 'jump to page 400'. What do you offer instead, and what does the honest version cost?
- Sort order becomes user-selectable across four columns. How many indexes is that, and which would you refuse to add?
Can you explain your approach to test plan creation, test case management, and performance testing?
Can you explain your approach to test plan creation, test case management, and performance testing?
Approach
- Build the test plan from risk, not from screens: list the requirements, rank them by impact if they fail, and write down scope (in and out), test levels (unit, integration, system, acceptance), environments, test data, entry and exit criteria, and who signs off.
- Keep a traceability matrix from each requirement to the cases that cover it, so an uncovered requirement or an orphaned case is visible. Each case carries preconditions, steps, expected result, priority and a linked requirement, and lives in a tool such as TestRail, Xray or Azure Test Plans, or as versioned test code.
- Manage the suite over time: tag cases as smoke, regression or release-only, retire cases for removed features, and quarantine and fix flaky tests instead of rerunning them until green.
- Name the performance test types and what each finds: load (expected traffic, checks targets), stress (past capacity, finds the breaking point and how it fails), soak (sustained load, finds memory leaks and connection-pool exhaustion) and spike. Tools: JMeter, Gatling, k6 or Locust.
- State targets as p95/p99 latency, throughput and error rate, never averages; warm up first, compare against a stored baseline, and prefer an open arrival-rate model, because a closed loop that waits for responses sends fewer requests as the system slows and under-reports tail latency.
Follow-up
- How do you decide which test cases to automate and which to keep manual?
- Your load test passed but the service degrades after two days in production. What test was missing and how would you set it up?
- How would you run performance tests in CI without flaky failures from noisy shared environments?
How would you design an automation test strategy for a complex data-driven application?
How would you design an automation test strategy for a complex data-driven application?
Approach
- Shape it as a test pyramid: many fast unit tests on the transformation and validation logic written as pure functions, fewer integration tests against a real database (for example in Testcontainers), and a small set of end-to-end tests on the critical user paths.
- Make the tests data-driven: parametrized cases (pytest.mark.parametrize or JUnit @ParameterizedTest) fed by small input and expected-output tables, plus property-based tests (Hypothesis) for invariants such as row counts preserved, totals reconciled, or a re-run being idempotent.
- Keep fixture data small, deterministic and versioned with the code; generate synthetic data with a fixed seed rather than copying production data that may be sensitive, and compare floating-point outputs with an explicit tolerance.
- Add data-quality checks at the boundaries: schema, nulls, uniqueness, ranges and referential integrity (Great Expectations, pandera or dbt tests), plus contract tests between producer and consumer so a column change fails in CI, not in a report.
- List the edge cases out loud: empty input, duplicates, nulls, unit mismatches, time zones and daylight-saving shifts, late or out-of-order records, and volumes far larger than the fixtures. Run the fast suite on every pull request and the slow suite nightly.
Follow-up
- How do you test a transformation whose correct output nobody can compute by hand?
- How do you keep test data representative of production shapes without copying production data?
- The end-to-end suite now blocks merges for too long. What do you cut or move, and what risk do you accept?
What do you know about industrial processes or manufacturing systems, and how does software integrate with the
What do you know about industrial processes or manufacturing systems, and how does software integrate with them?
Approach
- Describe the general automation layers (the ISA-95 / Purdue model): field sensors and actuators, control (PLCs, DCS, SCADA), manufacturing operations (MES, historians, quality and batch records) and business planning (ERP). Say where application software usually sits: reading from the control and operations layers and feeding planning and analytics.
- Name the common integration mechanisms: OPC UA for structured access to control data, Modbus on older equipment, MQTT for publish-subscribe telemetry, and a process historian for time-series storage. Distinguish batch processes (recipes, often modelled with ISA-88) from continuous ones (steady flows, setpoints).
- Treat the control layer as safety-relevant: software reads by default, writes only through controlled and audited interfaces, and never bypasses safety instrumented systems. Mention network segmentation between plant and office networks (IEC 62443) as the reason direct connections are restricted.
- Cover the data issues software has to handle: timestamps and clock drift, differing sampling rates, sensor quality flags, gaps during connectivity loss (store-and-forward buffering at the edge), and unit consistency.
- Be honest about your level: say what you have worked with and what you know only from reading, then show how you would learn the plant side from process engineers and operators rather than claiming expertise you lack.
Follow-up
- Why should an analytics application not write setpoints directly to a PLC?
- A sensor feed drops out for an hour and then backfills. How does your pipeline handle the gap and the late data?
- How would the data model differ for a batch process compared with a continuous one?
How would you approach a digitalization challenge to optimize efficiency in a manufacturing plant?
How would you approach a digitalization challenge to optimize efficiency in a manufacturing plant?
Approach
- Define efficiency in measurable terms before proposing software: throughput, unplanned downtime, energy or material per unit, or OEE (availability x performance x quality). Measure a baseline first, otherwise no improvement can be shown.
- Map the current process and its data: which steps are manual (paper logs, spreadsheets, re-keyed data), which systems already exist, and where the largest losses are. A Pareto chart of downtime causes is a quick way to pick the first target.
- Outline an architecture for the chosen problem: read-only collection from the control layer at the edge, buffering for connectivity loss, a time-series store, dashboards and alerts for operators, and links to maintenance or planning systems for work orders.
- Pilot on one line or unit, compare against the baseline, then scale; involve operators early, because a tool they do not trust goes unused. Treat safety and change management as requirements, not afterthoughts.
- State the trade-offs: build versus buy, edge versus cloud processing (latency and connectivity against central management), and how much data quality work is needed before any analytics is credible.
Follow-up
- How would you show that the improvement came from your tool and not from a change in product mix or season?
- Operators keep using the paper log instead of your tool. What do you do?
- What happens to your design when the plant loses its connection to the central systems for a shift?
Describe a hands-on technical project you completed recently and the architectural trade-offs you made.
Describe a hands-on technical project you completed recently and the architectural trade-offs you made.
Approach
- Pick a recent project where you made the technical decisions yourself, and open with the constraints in numbers: users or data volume, team size, deadline, and what already existed.
- Walk through two or three real decisions, each with the alternatives considered and the cost accepted, for example a modular monolith versus separate services, a relational database versus a document store, or a synchronous call versus a queue.
- Be ready to sketch the architecture: components, data flow, where state lives, and what happens when each dependency fails.
- Show evidence of the outcome: before-and-after metrics, how you tested it, how it was deployed (the CI/CD pipeline, rollout and rollback), and something that broke and how you fixed it.
- End with the decision you would change now and why. Saying what it cost is stronger than defending every choice.
Follow-up
- Which decision would you reverse today, and what would it cost to change now?
- What breaks first if the load grows tenfold?
- How did you test and deploy it, and what did you do when a release went wrong?
How do you prioritize tasks when managing multiple competing software deliverables simultaneously?
How do you prioritize tasks when managing multiple competing software deliverables simultaneously?
Approach
- Make every commitment visible in one list, and for each note impact, deadline, dependencies, effort and cost of delay. Name a method such as MoSCoW, or WSJF (cost of delay divided by job size), to show the ordering is reasoned.
- When two deliverables collide, put the trade-off in front of the stakeholders with options (what slips, by how much, what each choice risks) instead of quietly choosing; agree the order and write it down.
- Limit work in progress: finish or hand off before starting the next item, and keep capacity for unplanned work such as production incidents so it does not silently push every deadline.
- Tell one concrete story: the competing deliverables, the order you chose and why, what you dropped or deferred, how you told the affected people, and the result.
- Watch for the weak version: an answer that only says you work harder or longer hours shows no prioritization method.
Follow-up
- Two managers each say their deliverable is the top priority. What do you do?
- A production incident lands in the middle of your plan. How do you re-plan and communicate it?
- Looking back, how do you know you chose the right order?
What are your primary strengths and weaknesses when tackling a brand-new programming language or framework?
What are your primary strengths and weaknesses when tackling a brand-new programming language or framework?
Approach
- Describe a repeatable learning method: official documentation and tutorial, a small project end to end, reading well-regarded code in that ecosystem, porting something you already built, and letting the linter and formatter teach the idioms.
- Give a strength with evidence: a language or framework you picked up, how quickly you shipped something real with it, and what helped you get there.
- Give a real but manageable weakness, for example carrying idioms from your previous language (Java-style classes in Python) or going too deep into internals before delivering, together with what you now do about it, such as asking for reviews from an experienced user of that stack.
- Tie it to the stack candidates describe for this role, Python, Java or JavaScript and CI tools such as Jenkins or GitHub Actions: say which you know well and how you would close the gap on the others.
- Avoid disguised strengths such as being a perfectionist; they come across as evasive and leave no room for a credible improvement story.
Follow-up
- What is the last language or framework you learned, and how long before you shipped something with it?
- How do you know your code in a new language is idiomatic and not just working?
- How would you learn a new framework when a deadline does not allow a full ramp-up?
How do you approach debugging complex legacy codebases under tight operational deadlines?
How do you approach debugging complex legacy codebases under tight operational deadlines?
Approach
- If production is affected, mitigate before diagnosing: roll back, revert the config or turn off the feature flag, and say that restoring service and finding the cause are separate tasks.
- Reproduce with evidence: collect logs, inputs, versions and the exact time the behaviour started, then capture the failure as a failing automated test so the fix can be proven.
- Narrow the search systematically: git bisect between a known-good and a known-bad commit takes about log2(n) test runs; bisect inputs and configuration the same way, and add logging or breakpoints at module boundaries rather than reading the whole codebase.
- In code with no tests, write characterization tests that pin current behaviour around the area you change, make the smallest fix that passes, and leave refactoring for after the deadline with a ticket that records why.
- Close the loop: keep the regression test, write a short root-cause note, and add the monitoring or alert that would have caught it earlier.
Follow-up
- You cannot reproduce the bug locally. What do you do next?
- At what point under a deadline do you stop debugging alone and escalate?
- How do you make sure your fix does not break other callers of that legacy code that have no tests?
Seven days built around the four reported rounds and the 15 reported questions. The first days build the CI/CD, testing and take-home material, the middle days cover debugging and the plant cases, and the last day rehearses stories and a group exercise.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the loop and write your introduction
- List the four reported rounds and group the reported questions under them as stories, technical explanations and open-ended cases.
- Write the three-beat introduction and say it aloud until it fits your own words without reading.
- Write a fact sheet for the HR phone screening: salary expectation with your reasoning, notice period, location constraints and three questions for the recruiter.
Deliverable: A one-page loop map, a written introduction and an HR-call fact sheet.
Practice prompt ↗02Build the pipelines in Jenkins and GitHub Actions
- Create a small repository and write a GitHub Actions workflow with pull_request and push triggers, a matrix over two language versions, dependency caching, tests and an uploaded artifact.
- Write the same pipeline as a declarative Jenkinsfile and note three differences you hit (agents, credentials, syntax).
- Speak your answer to the CI/CD experience question, naming each stage and what it protects.
Deliverable: A working workflow file, a Jenkinsfile and a spoken CI/CD answer.
Practice prompt ↗03Test plan, test cases and performance testing
- Write a test plan for a data-driven application you know, covering scope, risks, test levels, test data, environments and entry and exit criteria.
- Write eight to ten structured test cases with ID, precondition, steps, expected result, priority and a link to the requirement.
- Write a performance test outline with workload, baseline, thresholds and what you would do if the threshold fails.
Deliverable: A test plan, a test case table and a performance test outline for one application.
Practice prompt ↗Practice prompt ↗04Rehearse the take-home project
- Build a small data-processing tool in Python, Java or JavaScript, for example one that reads a file of timestamped readings and reports summaries.
- Add unit tests, put your Day 3 test cases in the repository, and connect the Day 2 pipeline so it runs on every push.
- Write the README with run commands and a section on trade-offs, then verify it from a clean clone.
Deliverable: A repository with code, tests, a green pipeline and a README that works from a clean clone.
Practice prompt ↗Practice prompt ↗05Performance bottlenecks and legacy debugging
- Profile a slow script you wrote or found, locate the hotspot and record before and after timings.
- Write your legacy-debugging sequence: reproduce, find what changed, add a characterization test, bisect, fix, then add a regression check.
- Do the SQL practice drills on why a filter ignores an index and on replacing offset paging with keyset paging, as exercises in reading query plans on data-heavy workloads.
Deliverable: A profiling write-up with timings, a written debugging sequence and worked answers to the two SQL drills.
Practice prompt ↗Practice prompt ↗Practice prompt ↗06Manufacturing context and open-ended cases
- Write one page on how software connects to plant control systems and enterprise resource planning software, using public sources, and mark what you could not verify.
- Outline a structure for the plant digitalization question: users, data sources, the first measurable improvement, risks and rollback.
- Practise the ambiguous-requirement question with a real example, listing the clarifying questions you asked, and prepare the architecture trade-offs of one recent project.
Deliverable: A one-page manufacturing software note, a digitalization case structure and written answers for the ambiguous requirement and project trade-off questions.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗07Speak the stories and run a group exercise
- Record answers to the pressure, difficult stakeholder, work environment and leadership questions in STAR form and check each for a clear personal decision.
- Answer aloud the prioritization question and the question about strengths and weaknesses with a new language or framework, using real examples.
- Run a short group exercise with two or three people on the digitalization case, practising goal restating, assumptions, task split and check-ins.
Deliverable: Recorded STAR answers, a story-to-question matrix and notes on what to improve from the group exercise.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗Expand any day for tasks and deliverables. Your progress is saved on this device.
Candidates report that the panels lean on behavioral questions, with conflict resolution, inclusive teamwork and adaptability named as themes, and that the group assessment day is built around collaborating. Each story should show what you personally decided and what it cost, in STAR order. The introduction question belongs to the HR phone screening and is covered in the first plan day.
Tell us about yourself and describe your background in brief.
Tell us about yourself and describe your background in brief.
Approach
- Use three beats instead of a chronological CV: what you do now, one or two projects with an outcome, and why this role next. Choose projects that involve testing, CI/CD or automation, because those are the reported topics for this loop.
- Give one number per project (pipeline time cut, defects caught earlier, manual steps removed) and say how you measured it. Skip employers' names and job titles unless they add meaning.
- Name the languages and tools you used (Python, Java, JavaScript, Jenkins, GitHub Actions) only where you actually built something with them, so the later technical questions have a thread to follow.
- Close with a specific reason for industrial software, such as software that has to work with machines and plant operators, not a generic line about liking the company.
- Keep it short enough to leave room for questions; end on a sentence that invites a follow-up on your strongest project.
Follow-up
- Which project on your CV are you proudest of, and what was your personal contribution?
- Why industrial or manufacturing software rather than a pure product company?
- What would you want to learn most in a new team?
How do you deal with pressure or stressful situations, and can you share an example?
How do you deal with pressure or stressful situations, and can you share an example?
Approach
- Pick a real incident with stakes you can state in one sentence: a failed release, a broken pipeline before a deadline, a production bug found late. Avoid stories where the stress came from your own late start.
- Show a repeatable method under pressure: triage what is affected, decide what to cut or defer, tell stakeholders the status in plain words, and ask for help early. Describe those actions in the first person.
- Include the aftermath, because that is what distinguishes a method from heroics: the test, alert, pipeline check or runbook you added so the same pressure would not recur.
- Give the result with a measure (time to restore, deliverable shipped, defects avoided) and say what it cost, such as a deferred feature.
- Avoid answering only in the abstract ('I stay calm and prioritize') with no example, and avoid a story where you worked all night with no change to the process.
Follow-up
- What did you decide to drop, and who agreed to it?
- How did you keep stakeholders informed while you were fixing it?
- Did the same problem come back, and what would you change now?
Tell me about a time when you had to collaborate with a difficult stakeholder or team member.
Tell me about a time when you had to collaborate with a difficult stakeholder or team member.
Approach
- Choose a disagreement where the other person had a legitimate goal, for example a plant-side user wanting stability while you wanted to refactor, or a product owner wanting a feature date you thought unsafe. A story where they were simply wrong sounds like blame.
- State their goal and constraint first, then yours. Show that you listened and restated their point before arguing yours.
- Describe the action that moved things: finding a shared measure, showing data, offering two options with trade-offs, or involving a neutral third person at the right moment.
- Report the outcome and the relationship afterward, and state what you gave up. A compromise you can describe honestly is stronger than an unqualified win.
- Avoid 'we' throughout; say what you did, said and decided.
Follow-up
- What would you have done if they had still said no?
- When did you decide to escalate, and to whom?
- What did you change in how you communicate after that?
What type of work environment do you prefer, and how do you adapt to changing project requirements?
What type of work environment do you prefer, and how do you adapt to changing project requirements?
Approach
- Answer in two halves. First, an honest preference stated in terms of how you work best (clear goals, fast feedback, direct access to the people who use the software), without dismissing other setups.
- Second, show adaptability with one real change in requirements: say what changed, how you assessed the impact on scope and timeline, and how you told stakeholders before touching code.
- Show how engineering practice made the change safer, for instance tests and a CI pipeline that let you rework code quickly, or small increments that limited wasted work.
- Connect it to cross-functional work: plant operators, product owners and engineers have different priorities, and you adapted by confirming the goal behind each request.
- Avoid describing an ideal environment that conflicts with a global, multi-team role, such as 'I need fully specified requirements before starting'.
Follow-up
- When do you push back on a change instead of absorbing it?
- How do you handle a change that makes work you already finished obsolete?
- How do you work with colleagues in other locations or time zones?
Describe a situation where you demonstrated leadership or an inclusive mindset within a project team.
Describe a situation where you demonstrated leadership or an inclusive mindset within a project team.
Approach
- Show leadership without a title: you spotted a gap and acted on it, such as setting up a review checklist, introducing a pipeline check, mentoring a newer engineer or running a design discussion.
- For the inclusive angle, give concrete mechanics: collecting written input before a meeting, rotating who presents, asking quieter members directly, or adapting documentation for colleagues who work in another language or time zone.
- State the result in terms a listener can verify: onboarding was faster, review defects dropped, a decision incorporated a view that would have been missed.
- Say what you did when someone disagreed with your approach, since leading includes handling resistance.
- Avoid abstract claims ('I treat everyone equally') and avoid taking sole credit for what the team did.
Follow-up
- Tell me about someone who disagreed with your approach and what happened.
- How did you know the change actually helped?
- Describe a time your attempt to include others did not work.
What is your experience with CI/CD pipelines, such as Jenkins and GitHub Actions?
What is your experience with CI/CD pipelines, such as Jenkins and GitHub Actions?
Approach
- Tell it as a pipeline story, not a tool list. Describe one pipeline you built or maintained in stages: checkout, build, unit tests, static analysis, integration tests, packaging an artifact, deploy to a test environment, then a gated promotion.
- Show command of both tools. In Jenkins: a declarative Jenkinsfile, agents, multibranch pipelines, the credentials store and shared libraries. In GitHub Actions: workflow YAML with pull_request and push triggers, jobs and steps, matrix builds, dependency caching, repository secrets and environments with required approvals.
- Compare them honestly: Jenkins means you run and patch the controller, agents and plugins; Actions is hosted next to the repository and cheaper to start but ties you to its runners and syntax. If you have used only one, say so and map the concepts.
- Include one problem you solved and measured, such as flaky tests quarantined, a slow pipeline cut by caching and parallel jobs, or a secret that leaked into logs and how you masked it.
- Cover the failure paths: how you roll back a bad deployment, what blocks a merge, and how test results are reported.
Follow-up
- How would you speed up a pipeline that takes too long?
- How do you manage secrets and credentials in the pipeline?
- What happens when a deployment fails halfway, and how do you roll back?
- 01
How do you deal with pressure or stressful situations, and can you share an example?
- 02
Tell me about a time when you had to collaborate with a difficult stakeholder or team member.
- 03
What type of work environment do you prefer, and how do you adapt to changing project requirements?
- 04
Describe a situation where you demonstrated leadership or an inclusive mindset within a project team.
- 05
Tell me about a time when you had to explain a complex technical concept to a non-technical stakeholder.
- 06
Describe a situation where a project failed or missed a deadline, and how you managed the aftermath.
How technical is the BASF Software Engineer loop?
Candidates report four stages: an HR phone screening, panel interviews, a take-home challenge and a group assessment center. The technical content is CI/CD with Jenkins and GitHub Actions, test plans and test case management, performance testing and debugging. The reported questions are discussion-style rather than algorithm puzzles, so prepare specific examples from real projects.
BASF Software Engineer candidate reports ↗How long does the process take?
Candidate reports put the loop at about 3-5 weeks across four rounds, while other accounts describe four to eight weeks from the first phone screen to a decision. Timing varies by region and department, so ask your recruiter for the sequence that applies to you.
BASF Software Engineer candidate reports ↗What should I build for the take-home?
The reported take-home is a three-day project involving programming, test case management or CI/CD setup. Prepare one repository that covers all three: a small program in Python, Java or JavaScript, unit tests with a written test plan and cases, and a pipeline that runs on every push. Verify it from a clean clone and explain your trade-offs in the README.
BASF Software Engineer candidate reports ↗Do I need manufacturing or industrial experience?
The requirements candidates describe list industrial automation and control systems as nice-to-have, while Python, Java or JavaScript, CI/CD and software testing are must-have. Do not claim plant knowledge you lack; read how manufacturers connect software to production and reason from what you know, stating assumptions.
PracHub Software Engineer practice ↗Is the role remote, hybrid or on-site?
Candidates report that arrangements depend on the plant location and department, with roles tied to physical operations more likely to need regular on-site presence. Ask in the HR phone screening which arrangement applies to the team you would join.
BASF Software Engineer candidate reports ↗Should I prepare for any part of the loop in another language?
Some accounts of regional loops mention a switch into another language during interviews. Ask your recruiter which languages apply, and if you list a second language on your CV, be ready to give your introduction and one project summary in it.
BASF Software Engineer candidate reports ↗Sources & methodology 3 sources ↗
No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.
- 01BASF Software Engineer candidate reports ↗
Company-reported rounds, questions and FAQ.
Candidate reports · Accessed 2026-09-22 - 02PracHub Software Engineer practice ↗
PracHub practice material, not company-reported.
PracHub page · Accessed 2026-09-22 - 03PracHub preparation framework ↗
PracHub preparation guidance.
PracHub page · Accessed 2026-09-22
Explore related engineering environments and compare the preparation focus.
Cognition Software Engineer Interview Guide
What Cognition asks Software Engineer candidates, from reported rounds and questions.
Vercel Software Engineer Interview Guide
Debugging practice for Vercel software engineer prep built on a reproduction you trust, narrowing to the smallest failing input, and changing one variable per run so the result stays attributable.
Together Ai Software Engineer Interview Guide
Failure-handling practice for Together Ai software engineer candidates: requests whose outcome a timeout leaves unknown, where a retry is safe, and deduplicating at the receiver instead of assuming exactly-once delivery.
Spotify Software Engineer Interview Guide
Timed practice for Spotify software engineer candidates who lose time to the clock: short problems taken end to end, then reviewed against a written rubric rather than a passing test run.