Interview guides · BASF

BASF Software Engineer Interview Guide

BASF Software Engineer interview guide: the four reported rounds, CI/CD, test plan and behavioral questions, take-home prep and a 7-day plan.

The 60-second brief

BASF is a chemical manufacturer, and the Software Engineer role candidates describe sits on its digital side. The work is software for industrial processes: applications that support plant operations, supply chain visibility and data analytics, plus automation pipelines, test case management frameworks and internal web tools that visualize plant metrics. The people using that software are internal engineering teams, plant operators and digital product owners, and the systems have to connect with physical machinery, control systems and enterprise resource planning software. In practice the role mixes ordinary software engineering with testing and release automation, applied to a manufacturing setting.

This guide is for candidates interviewing for a Software Engineer role at BASF. It covers the four rounds candidates report, the 15 reported questions (five behavioral stories, a CI/CD experience question, and open-ended questions on testing, debugging, digitalization and prioritization), and a seven-day plan. The requirements candidates describe list Python, Java or JavaScript, hands-on CI/CD with Jenkins or GitHub Actions, and software testing with test case management; industrial automation, control systems, Docker and Kubernetes appear as nice-to-have.

Candidates report four rounds over about 3-5 weeks: an HR phone screening, panel interviews, a take-home technical challenge and a group assessment center. Regional offices reportedly condense or expand the stages.

Focus areas

CI/CD (Continuous Integration/Continuous Delivery)
Performance Testing
Jenkins

Overview

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.

The BASF interview process

Candidates describe four stages, from a recruiter call to a full-day group assessment. Treat the order as typical rather than fixed, since regional offices reportedly condense or expand it.

HR Phone Screening

Candidates 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

Candidates 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

Candidates 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

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

Where candidates lose points

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.

Questions & practice

Walk us through your problem-solving process when faced with a vague or ambiguous technical requirement.

Medium · Problem-Solving and Case Studies

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

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?

Replace offset paging on the resource feed with keyset

Easy · keyset pagination · composite index · sort order

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?

Medium · Technical and Domain Knowledge

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?

Medium · Technical and Domain Knowledge

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

Medium · Technical and Domain Knowledge

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?

Medium · Problem-Solving and Case Studies

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.

Medium · Problem-Solving and Case Studies

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?

Medium · Problem-Solving and Case Studies

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?

Medium · Problem-Solving and Case Studies

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?

Medium · Technical and Domain Knowledge

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?

Suggested practice checklist

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.

Day 1 — Map 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.

Day 2 — Build 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.

Day 3 — Test 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.

Day 4 — Rehearse 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.

Day 5 — Performance 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.

Day 6 — Manufacturing 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.

Day 7 — Speak 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.

Stories for the panels and the assessment day

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 me about a time when you had to explain a complex technical concept to a non-technical stakeholder.
Describe a situation where a project failed or missed a deadline, and how you managed the aftermath.