The reported questions split into four families. Core engineering covers object-oriented principles, design patterns, memory management, complexity on large log files and debugging threads. Embedded and domain questions cover RTOS and Embedded Linux experience, hardware interrupts, drive systems, schematics and sending device telemetry to a cloud backend. Full-stack questions cover REST middleware to legacy manufacturing systems, component-based UIs, schemas for high-frequency sensor data, Cypress or Ranorex suites and frontend bundle size. Behavioral questions cover process limitations, deadlines, cross-functional work, motivation and code review disagreements.
Which family dominates depends on the team. Candidates describe embedded, instrumentation, robotics and drives teams as the ones where electrical basics and low-level questions come up, while enterprise, MES and web teams lean on API, database and frontend topics. Read the job posting for the languages it lists (C++, Java, C#, Python, TypeScript) and weight your time toward that track, but keep a working answer for every family because the reported question list mixes them.
The scenarios candidates describe are concrete. Examples include a driver layer that talks to several sensor types without changing core logic, a C++ routine that logs high-frequency sensor data without stalling a control loop, a billing backend fed by EV chargers worldwide, a status grid for thousands of devices, and a test strategy for a team that only tests manually. Practise these by sketching components, naming the failure modes and saying how you would test each one.
Several tracks also include a walk through a past project or a use-case presentation. Prepare one project in enough depth to cover architecture, trade-offs, error handling, testing and what you would change. Candidates are advised to show this reliability thinking because the software drives physical machinery.
Talent Acquisition Screening
reportedThe first stage is an initial call with talent acquisition. Candidates report that the call goes over your experience, pay expectations and how you match the role. It is a conversation about you, so the preparation is a clear account of your experience and a sensible reason for choosing this team.
What to demonstrate
- Fit between your background and the position
- Whether your experience matches the languages and domain of the team
- Alignment on salary expectations
How to prepare
- Write a short walk through your last two projects with the stack, your own contribution and one measurable result for each.
- Prepare your answer to why you want to join ABB and which business area (Electrification, Process Automation, Motion or Robotics) matches your experience.
- Decide your salary range from your own research before the call so that your number stays consistent in later stages.
Asynchronous Video Submission
reportedCandidates report an asynchronous video submission or an online assessment at this stage, covering aptitude and basic programming logic. Some accounts add electrical or domain concepts for some teams. You work alone and without an interviewer, so the preparation is fluency in plain programming logic and a recorded answer that is easy to follow.
What to demonstrate
- Basic programming logic
- Aptitude-style reasoning
- Clear spoken explanation if the format is a video
How to prepare
- Solve small array, string and log-parsing problems in your main language without autocomplete, then state the time and space complexity aloud. This is the same skill the question on optimizing multi-dimensional data and large log files asks for.
- Record a spoken answer to the question on core OOP pillars and the one on common design patterns, and watch it back for structure, filler and an example per concept.
- If you are applying to a drives or instrumentation team, refresh basic electrical vocabulary such as voltage, current and frequency.
Technical Panel Rounds
reportedCandidates report technical panels that include live coding, object-oriented design scenarios and system architecture discussions, and in some tracks a use-case or homework task that you present. Reported design scenarios include a modular driver layer for several sensor types, refactoring a monolithic telemetry processor, a billing backend for EV chargers and a frontend for thousands of devices. Practise talking while you code and write down the interfaces first.
What to demonstrate
- Working code in a live coding setting
- Object-oriented design and use of established patterns
- System architecture reasoning and trade-offs
How to prepare
- Work the SOLID principles and the Factory, Strategy, Observer, Adapter and Singleton patterns through one example: a driver interface with one implementation per sensor type, selected by a factory.
- Practise the race condition and deadlock debugging walk-through and the memory-leak question out loud, naming tools such as sanitizers, thread dumps and lock ordering.
- Sketch the device-to-cloud telemetry design and the EV charger billing backend, listing components, protocols, retry behaviour and storage.
Deep Technical Probing
reportedCandidates report discussions with senior engineering leads about technical expertise. Little more is reported about this stage, so prepare your own projects at the level of code, constraints and failure cases, and keep the technical areas from the panel stage fresh so you can go deeper on any of them.
What to demonstrate
- Depth of technical expertise in your primary stack
- Ability to explain and defend design decisions you made
- Reasoning about embedded and real-time constraints where your team needs them
How to prepare
- Rehearse an explanation of how a hardware interrupt reaches an interrupt service routine and how it hands data to a task through a queue or semaphore, with no blocking calls inside the routine.
- Be able to compare stack and heap allocation, smart pointers and manual ownership in C++, and describe how you would find a pointer corruption on an RTOS target.
- As extra preparation for database-flavoured follow-ups, write a one-page schema for high-frequency sensor readings, covering time partitioning, indexing, retention and the queries it must serve.
Behavioral Evaluations
reportedCandidates report behavioral interviews with business unit managers about project history and team collaboration style. The reported prompts cover process limitations, tight deadlines, working with hardware engineers and product managers, motivation for joining and disagreement in code review. Come with specific stories in which you personally acted.
What to demonstrate
- Project history and your own contribution
- Team collaboration style
- Handling of deadlines, feedback and disagreement
How to prepare
- Write four stories with a situation, your action and a result, mapped to the prompts on process limitations, deadlines or vague requirements, cross-functional work and code review disagreement.
- Rehearse a project walkthrough that states the architecture, a trade-off you made under constraints, the testing you did and what you would change.
- Prepare a motivation answer that names one ABB product area and one part of your experience that relates to it.
Final Offer Discussion
reportedCandidates describe the final stage as a conversation about the offer and where you want your career to go. Preparation is practical: know the direction you want in your career, the team you are being offered, and the questions you need answered before accepting.
What to demonstrate
- Your career direction and interests
- Expectations on both sides about the offer
How to prepare
- Write two or three sentences on where you want your skills to grow over the next few years and link it to the team's work, whether embedded, full-stack or test automation.
- List questions about team structure, development methodology and how the team measures software quality.
- Review your salary expectations from the first call so that your position stays consistent.
4 candidate reports. Individual accounts describe a particular role and hiring cycle.
ABB Software Engineer interview: logical test and office meeting
I applied through Workday, was contacted, and chose a time for a recruiter call. That simple portal setup moved quickly into a more demanding process than I had expected, although it seemed well managed. I first took a cognitive or logical test and then had an online Teams round. After that I met people in person at the office, including the department for the role, HR, and possibly other manager…
Read full experienceABB Software Engineer interview: fundamentals and a difficult final round
The process started with a familiar technical sequence but became a test of both fundamentals and performance under pressure. I faced medium-level data-structures and algorithms questions, plus computer-networks and operating-systems topics with a clear cybersecurity-basics tilt. There was also a group discussion, which made it feel less like a one-shot evaluation and more like an assessment of h…
Read full experienceABB Software Engineer interview: one quick behavioral conversation
I had one behavioral interview that lasted about half an hour, followed by a short wait while they followed up. Things moved quickly once the interview ended: an offer arrived roughly 15 minutes later. There was plenty of time for questions during the conversation, and I appreciated being able to ask and clarify things. It was a very good experience. The quick, conversational format made it easie…
Read full experienceABB Software Engineer interview: system design with manager and team
My interview path was straightforward: an HR screen, a conversation with the hiring manager, and then a meeting with the team. The second stage was the real technical checkpoint, and it focused much more on system design than deep coding. Once I was there, the structure was clear and there were no surprises about the format. I concentrated on explaining my thinking through the system-design promp…
Read full experiencePracHub editorial advice for the preparation topics above.
Defining OOP pillars and design patterns from memory without a project example
For each concept, prepare one real example, such as a sensor driver interface for polymorphism or an observer for telemetry updates. Name the alternative you rejected and why, because the reported question asks why you chose a pattern over others.
Saying you know C++ or RTOS without describing interrupts, ownership or shared data
Be ready to explain what runs in an interrupt service routine, how it hands data to a task, how you avoid races on sensor readings and how you would trace a leak or pointer corruption on target. If you lack embedded experience, say so and explain the concurrency principles you do have.
Presenting a project or design without error handling, edge cases or testing
For every design you describe, add the failure case and how you would verify it: a dropped connection, a duplicate telemetry message, a flaky test or an overloaded log writer. Candidates are told that reliability and safety matter in this domain.
Arriving unable to say why this company and which of its areas
Learn the four business areas candidates name (Electrification, Process Automation, Motion, Robotics) and a few concepts such as variable frequency drives, SCADA and industrial IoT. Connect one item to your own work in two sentences.
Telling behavioral stories in 'we' language with no personal decision or outcome
For each story, state what you decided or built, and give a result. Rehearse stories on process limitations, deadlines, cross-functional work and code review disagreement so they are separate and specific.
Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.
How do you manage memory allocation and handle potential memory leaks in continuous-running software systems?
How do you manage memory allocation and handle potential memory leaks in continuous-running software systems?
Approach
- Split by runtime. In C/C++ make ownership explicit with RAII: std::unique_ptr for single ownership, std::shared_ptr only when ownership is genuinely shared, std::weak_ptr to break reference cycles that would otherwise never free.
- For software that runs for months, avoid heap churn on the hot path: allocate pools or fixed-size buffers at startup and reuse them, which also avoids fragmentation; many embedded codebases forbid malloc/free after initialisation.
- In Java or C# a leak is a reachable object nobody needs: unbounded caches, listeners or callbacks never unregistered, static collections. Fix with bounded or weak-keyed caches and explicit unsubscribe.
- Detection: run a soak test and watch resident memory or heap-after-GC over hours; a steady climb is the signal. Then use AddressSanitizer/LeakSanitizer or Valgrind memcheck for native code, heap snapshots (jmap plus Eclipse MAT, dotnet-dump) for managed code, and diff two snapshots taken apart in time.
- Distinguish a leak from fragmentation or a growing-but-bounded cache: memory that plateaus is not a leak, and fragmentation shows free heap that cannot satisfy a large allocation.
Follow-up
- Two objects hold shared_ptr references to each other. What happens, and how do you fix it?
- Memory grows on a device with no Valgrind and no OS. How do you find the leak?
- How would you tell a real leak from heap fragmentation in the field?
How do you optimize time and space complexity when working with multi-dimensional data structures or large log
How do you optimize time and space complexity when working with multi-dimensional data structures or large log files?
Approach
- For large log files, stream instead of loading: read line by line or in fixed-size chunks so memory is O(1) in file size, and do the work in one pass where possible.
- Pick the structure from the query: a hash map keyed by error code or host gives O(n) counting with memory proportional to distinct keys; top-k uses a min-heap of size k for O(n log k) instead of sorting everything in O(n log n).
- When even the distinct keys do not fit in memory, hash-partition the file into buckets on disk so each bucket fits, process buckets one at a time, then merge; external merge sort is the alternative when ordered output is needed.
- For multi-dimensional arrays, iterate in storage order (row-major in C/C++) for cache locality; use sparse formats (coordinate list, CSR) when most cells are empty; a 2D prefix-sum table answers any rectangle-sum query in O(1) after O(rows x cols) preprocessing.
- If logs are sorted by timestamp, binary search finds the start of a time window in O(log n) instead of scanning; mention approximate structures (Count-Min sketch, HyperLogLog) when an estimate is acceptable.
Follow-up
- The log is 200 GB and the number of distinct keys is also too large for RAM. What now?
- How would you parallelise the pass across cores or machines and merge the results?
- When is an approximate count acceptable, and what error does a Count-Min sketch give?
Walk me through how you approach debugging a multi-threaded system when encountering a race condition or deadl
Walk me through how you approach debugging a multi-threaded system when encountering a race condition or deadlock.
Approach
- Classify the symptom first: threads stuck with no CPU suggests deadlock; wrong or intermittent results suggest a data race; high CPU with no progress suggests livelock or spinning.
- Deadlock: capture all thread stacks while hung (jstack for Java, gdb 'thread apply all bt' for native, a debugger halt on an RTOS), list which lock each thread holds and waits for, and find the cycle.
- Fix deadlocks by breaking a Coffman condition, usually circular wait: a single global lock order, std::scoped_lock to acquire several mutexes together, or try_lock with a timeout and back-off; also avoid calling unknown code while holding a lock.
- Race: find shared mutable state and check-then-act or read-modify-write sequences; run ThreadSanitizer (-fsanitize=thread) or Helgrind, and raise contention with stress loops and more threads, because extra logging changes timing and can hide the bug.
- Fix with the narrowest tool that keeps the invariant: a mutex around the whole critical section, std::atomic for a single word, immutable data or message passing; prove it with a stress test that previously failed and a clean sanitizer run.
Follow-up
- What is priority inversion, and how does priority inheritance address it?
- The bug disappears when you add logging. How do you keep investigating?
- When is a lock-free structure worth it over a mutex?
How do hardware interrupts work, and how do you ensure thread safety when reading sensor data from physical de
How do hardware interrupts work, and how do you ensure thread safety when reading sensor data from physical devices?
Approach
- Mechanism: a peripheral raises an interrupt line, the interrupt controller (the NVIC on Cortex-M) arbitrates by priority, the CPU saves context and jumps through the vector table to the ISR, the ISR clears the source flag and returns, and the interrupted code resumes.
- Keep ISRs short: no blocking calls, no heap allocation, no printf. Capture the data or timestamp and defer processing, using FreeRTOS FromISR queue or semaphore calls, or a Linux threaded IRQ, tasklet or workqueue (the top half/bottom half split).
- Sharing data between ISR and task: volatile stops the compiler caching a value but does not make access atomic. Protect multi-word data with a brief critical section (interrupts masked) or atomic operations; a mutex cannot be taken inside an ISR.
- For a stream of sensor samples, a single-producer single-consumer ring buffer (ISR writes head, task reads tail) needs no lock as long as each index is written by one side only and updates are atomic and correctly ordered.
- Name the edge cases: a torn read of a multi-byte value (read twice and compare, or double-buffer), interrupt storms from a noisy input, and on multicore Linux using spin_lock_irqsave rather than only disabling local interrupts.
Follow-up
- What determines interrupt latency, and how would you measure it?
- A sensor uses DMA instead of an interrupt per sample. What changes, including cache coherency?
- How do you handle a bouncing mechanical switch wired to an interrupt pin?
How do you structure relational or non-relational database schemas to handle high-frequency sensor readings an
How do you structure relational or non-relational database schemas to handle high-frequency sensor readings and operational logs efficiently?
Approach
- Choose the shape from the queries: a narrow table (device_id, metric_id, ts, value) handles new metrics without schema changes; a wide table suits a fixed set of metrics always read together. Keep operational logs in a separate table or log store, since they are queried differently.
- Index and order for the dominant query, readings for one device over a time range: a primary key or index on (device_id, ts) makes it a range scan. Keep secondary indexes few, because each one adds write cost at high ingest rates.
- Partition by time (PostgreSQL declarative range partitioning by day or month, or TimescaleDB hypertables) so queries prune partitions and retention drops whole partitions instead of running large DELETEs; a BRIN index on ts is small and effective for append-ordered data.
- Precompute rollups (per-minute, per-hour min/max/avg) for dashboards and keep raw data for a shorter window; batch writes with COPY or multi-row INSERTs rather than one insert per reading.
- Non-relational option: in Cassandra, partition by (device_id, day bucket) with ts as the clustering column so partitions stay bounded. For the latest reading per device in PostgreSQL: SELECT DISTINCT ON (device_id) device_id, ts, value FROM readings ORDER BY device_id, ts DESC.
Follow-up
- Readings arrive late and out of order. How does your design handle them?
- How would you serve 'latest value for 10,000 devices' fast enough for a live grid?
- How do you enforce a 90-day raw-data retention without hurting ingest?
Why do you specifically want to join ABB, and how does your background align with our industrial technology fo
Why do you specifically want to join ABB, and how does your background align with our industrial technology focus?
Approach
- Treat it as a motivation question with three parts: what you know about the company, why your background fits the specific team, and what you want to learn there.
- Show real knowledge in your own words: the divisions candidates name (Electrification, Process Automation, Motion, Robotics) and products such as drives, the ABB Ability platforms and EV charging stations, then pick the one closest to the team you applied to.
- Connect a concrete piece of your work to that team's software: embedded C/C++ for device control, full-stack tools for energy or manufacturing data, or test automation, with one result you can describe.
- Say what draws you to software that runs physical equipment, such as reliability and safety constraints or working with hardware engineers, in first person: 'I want my code to run on equipment where a fault has physical consequences.'
- Avoid generic lines about size or reputation that fit any employer, and do not overclaim domain knowledge you cannot defend in a follow-up.
Follow-up
- Why this business unit rather than another part of the company?
- What would you find hardest moving from pure software into industrial products?
- Where do you want your career to be in a few years, and how does this role get you there?
Explain the core pillars of Object-Oriented Programming (OOP) and give real-world examples of inheritance, int
Explain the core pillars of Object-Oriented Programming (OOP) and give real-world examples of inheritance, interfaces, and polymorphism.
Approach
- Name the four pillars and define each in one line: encapsulation (state hidden behind methods that keep it valid), abstraction (callers see what an object does, not how), inheritance (a subtype reuses and specialises a base type), polymorphism (one call site, behaviour chosen by the runtime type).
- Use one domain to carry every example, e.g. a Sensor interface with read() and calibrate(), implemented by TemperatureSensor and PressureSensor; the acquisition loop holds Sensor references and never branches on the concrete type.
- Separate the kinds of polymorphism: subtype (virtual dispatch through a vtable in C++, interface methods in Java/C#), ad-hoc (overloading) and parametric (C++ templates, Java/C# generics), and say which one your example uses.
- Contrast interface and inheritance: an interface (Java/C# interface, C++ class with pure virtual functions) shares a contract, while a base class shares code; prefer composition when the subtype would break the base contract (Liskov substitution).
- Close with a C++ detail: deleting a derived object through a base pointer without a virtual destructor is undefined behaviour. In practice the derived destructor usually does not run, but the standard guarantees nothing, so a polymorphic base class gets a virtual destructor.
Follow-up
- When has inheritance hurt you, and how would composition have changed that design?
- What is the difference between an abstract class and an interface in the language you use most?
- How does virtual dispatch work in C++, and what does it cost per call?
What are common design patterns you have implemented in past projects, and why did you choose them over altern
What are common design patterns you have implemented in past projects, and why did you choose them over alternative architectural patterns?
Approach
- Answer with two or three patterns you actually shipped, each as problem, pattern, alternative you rejected, and the cost you accepted; a list of pattern names without the reason earns little.
- Strategy: interchangeable algorithms (control modes, billing rules) selected at runtime, chosen over a growing switch statement so a new variant is a new class, not an edit to tested code (open/closed principle).
- Observer or publish-subscribe: sensor or device events fanned out to loggers, UI and alarms without the producer knowing the consumers; the cost is harder tracing and listeners that must be unregistered to avoid leaks.
- Adapter and Factory: an adapter wraps a legacy or vendor interface behind your own; a factory builds the right driver or handler from configuration, so the core never names concrete classes.
- Be honest about Singleton: it hides global state and makes tests share it; prefer constructing the object once and passing it in (dependency injection). If asked, a C++11 function-local static is initialised thread-safely.
Follow-up
- Tell me about a pattern that added indirection without paying for itself.
- How would you add a new sensor type to your design without changing existing code?
- Why did you choose events over direct calls there, and how did you debug the flow?
What experience do you have with Embedded Linux, real-time operating systems (RTOS), and C/C++ development for
What experience do you have with Embedded Linux, real-time operating systems (RTOS), and C/C++ development for hardware control?
Approach
- Structure the answer around one or two real projects: the target (microcontroller or Linux-class processor), the OS, what the software controlled, and one problem you solved with a measurable result. If your experience is thin, say so and show the adjacent work you have done.
- RTOS concepts to use correctly: preemptive priority scheduling, tasks, queues, semaphores versus mutexes (mutexes carry ownership and priority inheritance), ISRs that defer work to tasks, and worst-case timing rather than average speed.
- Embedded Linux concepts: kernel drivers versus user-space access (sysfs, ioctl, spidev/i2c-dev), device tree, cross-compiling with Yocto or Buildroot, and PREEMPT_RT when latency bounds matter.
- C/C++ for hardware: volatile for memory-mapped registers, bit masks for register fields, fixed-width integer types, no dynamic allocation after start-up, and watchdog handling.
- Explain one choice between them: an RTOS on a microcontroller gives deterministic timing, a small footprint and fast boot; Embedded Linux gives networking, filesystems and a large software stack at the cost of latency guarantees.
Follow-up
- How did you debug on the target: JTAG/SWD, logic analyzer, trace output?
- Why does a mutex need priority inheritance, and what happens without it?
- What would make you choose an RTOS over Embedded Linux for a new device?
Describe your understanding of low-voltage and medium-voltage variable frequency drives or electrical control
Describe your understanding of low-voltage and medium-voltage variable frequency drives or electrical control systems.
Approach
- Explain the power path: a rectifier turns incoming AC into DC, a DC bus with capacitors smooths it, and an inverter switches IGBTs with pulse-width modulation to synthesise AC of variable frequency and voltage for the motor.
- Why frequency sets speed: an induction motor's synchronous speed is 120 x f / poles rpm, so changing frequency changes speed; scalar V/f control keeps voltage proportional to frequency to hold magnetic flux roughly constant, while vector control and direct torque control regulate torque more precisely.
- Low versus medium voltage: low-voltage drives work at or below 1 kV AC, medium-voltage drives above that for large motors; the control ideas are similar, while power hardware, insulation and protection differ.
- Tie it to software: parameter sets, start/stop and ramp profiles, fault detection (overcurrent, DC-bus over- or undervoltage, overtemperature) with defined safe states, fieldbus communication such as Modbus or EtherNet/IP, and safety functions such as Safe Torque Off.
- Mention the energy reason drives exist for fans and pumps: by the affinity laws power scales roughly with the cube of speed, so a modest speed reduction saves much more energy than throttling. Be clear about where your knowledge stops.
Follow-up
- Why must voltage drop when frequency drops below rated speed?
- How would you test drive control software without a real motor attached?
- What should the software do on a DC-bus overvoltage during fast deceleration?
How would you structure software components to transmit real-time telemetry from a physical device (e.g., EV c
How would you structure software components to transmit real-time telemetry from a physical device (e.g., EV charger or marine vessel drive) to a cloud backend server?
Approach
- Lay out the device side as separate components: acquisition (sampling task), a bounded local buffer, serialisation (Protobuf, CBOR or JSON), and a transport client; telemetry runs at lower priority than control so a slow network never blocks the control loop.
- Transport: MQTT over TLS is a common fit (persistent connection, small overhead, QoS 1 for at-least-once); batched HTTPS is simpler when data is less frequent. Use per-device certificates or mutual TLS for identity.
- Reliability: store-and-forward to flash or a local database while offline, with a stated policy when the buffer fills (drop oldest, or keep alarms and drop routine samples); reconnect with exponential back-off and jitter so a fleet does not reconnect at once.
- Because delivery is at-least-once, give each message a device ID and a monotonic sequence number plus a device timestamp so the backend can deduplicate and order; keep clocks synchronised with NTP.
- Cloud side: a broker feeding a stream (Kafka or a managed equivalent), consumers writing to a time-series store and an alerting path; cut volume with report-on-change deadbands and batching. For EV chargers, know OCPP, the open charger-to-backend protocol.
Follow-up
- The device is offline for two days. What happens to its data when it reconnects?
- How would the backend send a command or firmware update back to the device safely?
- How do you evolve the message schema without breaking older devices in the field?
Explain how you read and interpret basic electrical diagrams or schematics when integrating software with hard
Explain how you read and interpret basic electrical diagrams or schematics when integrating software with hardware components.
Approach
- Start with the frame: title block and revision, power rails and their voltages, grounds, then follow each net label from the MCU pin to the part it drives or reads.
- Read the parts by reference designator (R resistors, C capacitors, U ICs, Q transistors, J connectors) and open the datasheet of every IC the software talks to for pinout, register map and timing.
- Derive software settings from the circuit: pull-up or pull-down resistors set an input's idle state, a bar, '#' or '_N' marks an active-low signal, open-drain outputs need a pull-up, I2C lines need pull-ups, SPI needs one chip-select per device, and UART TX crosses to RX.
- Check electrical compatibility before writing code: 3.3 V versus 5 V logic and any level shifter, the transistor or driver stage between a GPIO and a relay (with its flyback diode), and which state each output takes at reset so the hardware stays safe before the firmware configures it.
- Verify on the bench with a multimeter, oscilloscope or logic analyzer, and write the pin map and polarities down as the contract between hardware and firmware.
Follow-up
- An input reads random values. What on the schematic would you check first?
- How do you handle an active-low reset or enable line in the driver code?
- How would you confirm the I2C bus works before blaming the firmware?
How do you design robust RESTful APIs or middleware to connect frontend dashboards with legacy backend manufac
How do you design robust RESTful APIs or middleware to connect frontend dashboards with legacy backend manufacturing systems?
Approach
- Put an adapter layer (anti-corruption layer) between the dashboard and the legacy system: it speaks the legacy protocol (OPC UA, Modbus, SOAP or direct database reads) on one side and exposes clean, resource-oriented REST endpoints on the other, so the frontend never sees legacy codes.
- Design the contract: nouns as resources (/lines/{id}/machines), versioning in the path or a header, pagination and filtering for large lists, and one error schema that maps legacy faults to consistent HTTP statuses.
- Protect the legacy side: cache or maintain a read model for dashboard reads, apply timeouts, rate limits and a circuit breaker, and return the last known value with a staleness timestamp when the legacy system is slow or down.
- Writes that reach machines must be safe to retry: require an idempotency key, validate and authorise every command (OAuth2/OIDC tokens), and for long operations return 202 Accepted with a status resource the client polls.
- For live status, push changes over WebSockets or Server-Sent Events instead of having many dashboards poll the legacy system; add correlation IDs and structured logs across the layers.
Follow-up
- The legacy system takes ten seconds per query. How does the dashboard stay usable?
- How would you roll out a breaking change to this API while old clients still run?
- A command times out at the client. How do you make sure it is not applied twice?
Explain how you would implement automated test suites using Cypress or Ranorex for web-based control interface
Explain how you would implement automated test suites using Cypress or Ranorex for web-based control interfaces.
Approach
- Set the shape first: most coverage in unit and component tests, a small set of end-to-end flows in Cypress for what matters most on a control interface (logging in, viewing device state, issuing a command with confirmation, seeing a fault alarm).
- Make tests deterministic: select elements by dedicated data-cy or data-testid attributes, rely on Cypress's retrying assertions instead of fixed waits, and reset state through the API (cy.request) rather than by clicking through the UI.
- Stub the backend with cy.intercept to force states that are hard to reproduce, such as a device offline, a fault code or a slow response; cy.intercept handles HTTP only, so stub WebSocket feeds in the app layer or with a mock server. Keep a few tests against a real backend or device simulator.
- Ranorex fits desktop or Windows-based HMI applications as well as web; pick the tool per interface rather than forcing one.
- Run headless in CI (for example an Azure DevOps pipeline) on every merge, parallelise specs, keep screenshots and videos of failures, and quarantine flaky tests with an owner instead of letting retries hide them.
Follow-up
- A test passes locally and fails one run in ten in CI. How do you find the cause?
- How would you test the UI against real hardware behaviour without a lab for every run?
- What would you not test end to end, and why?
What strategies do you use to optimize frontend application performance and minimize bundle load times?
What strategies do you use to optimize frontend application performance and minimize bundle load times?
Approach
- Measure before changing anything: Lighthouse and Core Web Vitals (LCP, INP, CLS) for user-facing speed, and a bundle analyzer (webpack-bundle-analyzer or source-map-explorer) to see what the bytes are.
- Cut what ships: route-level code splitting with dynamic import() and React.lazy, tree shaking through ES module imports, replacing heavy dependencies (date libraries, whole-library lodash imports) and loading rarely used features on demand.
- Ship it efficiently: Brotli or gzip compression, content-hashed filenames with long cache lifetimes, a CDN, and preloading only the critical resources.
- For a live grid of many devices, runtime cost dominates: virtualise rows (react-window), normalise state so one device update re-renders one row, memoise with React.memo and useMemo, and batch incoming updates per animation frame instead of one render per message.
- Keep it from regressing: a bundle-size budget checked in CI and a performance test on a representative data set.
Follow-up
- The dashboard shows 5,000 devices updating every second and scrolling stutters. Where do you start?
- How would you stop a new dependency from silently doubling the bundle?
- When would server-side rendering help this application, and when would it not?
One log partition stops advancing while the others drain
Search results for a subset of tenants are hours stale; the rest are current. The projection consumer reports lag of zero on 15 of 16 partitions and 400,000 on one. Its error rate is flat and its CPU is idle. outbox_event has no pending rows older than a second, so the relay has published everything it holds. Identify the mechanism, give the ordered checks, and state what you do in the first ten minutes versus what you change permanently.
Approach
- Read the lag distribution first. A slow consumer lags everywhere; zero on fifteen partitions and 400,000 on one is not throughput. Idle CPU on the stuck partition means the consumer is not advancing its offset at all, which points at one message it cannot get past rather than at a rate problem.
- Exonerate the producer before touching the consumer. No pending outbox rows older than a second means the relay published, so the event exists in the log. This separates never sent from sent and never applied, which are different code paths and usually different owners.
- Read the message at the stuck offset and the handler's log lines for its event_id. A flat error rate with no progress has two explanations and you must distinguish them: the handler is throwing and the retry loop is swallowing it, or the handler is blocking on something and never returning. Idle CPU with no error lines favours the second.
- Mitigate before diagnosing further. Move the offending event to a dead-letter store and commit the offset past it. Adding consumers does nothing here, because a partition is consumed by exactly one member of the group, and the blast radius is every aggregate hashed to that partition, not only the aggregate that produced the bad event.
Follow-up
- The dead-lettered event carried aggregate_version 7 and the projection had applied 6. What must the replay do differently if 8 and 9 landed in the meantime?
- How do you show staleness to the user while the partition is behind, given the API already returns the projection's watermark?
The plan follows the reported loop: fundamentals and design first, then embedded and domain topics, then APIs, data and test automation, and behavioral stories last. Each day ends with something written or recorded that you can review.
Prepare, practise & reflect
One practical outcome each day. Spend longer where you need it.
0 / 7 done01Map the loop and choose your track
- Write the six reported stages in order and note beside each what you must produce for it, such as a video answer, live code or a project walkthrough.
- Choose your main track from the role's listed stacks (C/C++ embedded, Java or C# backend, React or Vue frontend, test automation) and list the topics from the other tracks you still need to cover.
- List three of your past projects with your own contribution and one measurable result each.
Deliverable: A one-page loop map, a chosen track with a gap list, and a three-project inventory with results.
02OOP, SOLID and design patterns
- Answer the OOP pillars question aloud with one example each for inheritance, interfaces and polymorphism, using a sensor driver hierarchy as the setting.
- Write a modular driver layer in your main language using an interface, a factory and an adapter so a new sensor type needs no change to core logic.
- Prepare a comparison for the design patterns question: for two patterns you have used, name the alternative you rejected and the reason.
Deliverable: A recorded OOP answer, a working driver-layer sketch with interfaces and a factory, and two pattern-versus-alternative comparisons.
Practice prompt ↗Practice prompt ↗03Memory, complexity and threads
- Write a memory-leak checklist for long-running software covering ownership, smart pointers or garbage-collected references, caches without eviction and growing buffers, and tools to confirm each.
- Solve one log-processing problem and one grid problem in your main language, then state the brute-force and improved complexity.
- Write a race condition and deadlock debugging sequence, then work through the PracHub practice debugging exercise on a stuck log partition.
Deliverable: A leak checklist, two solved problems with complexity notes, a written threading debug sequence and a note from the practice exercise.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗04Embedded systems and domain basics
- Explain interrupts end to end: the hardware signal, the interrupt service routine, deferring work to a task through a queue, and protecting shared sensor data.
- Write a summary of your embedded Linux, RTOS and C/C++ experience, or the nearest equivalent, in your own projects.
- Read about variable frequency drives and basic schematic symbols, then write a short explanation of how you would read a schematic before integrating software with a device.
Deliverable: A written interrupt-handling explanation, an experience summary and a one-page drives-and-schematics note.
Practice prompt ↗Practice prompt ↗Practice prompt ↗Practice prompt ↗05Telemetry, APIs and sensor data storage
- Draw the architecture from device to cloud, covering buffering on the device, a message protocol, ingestion, storage and a dashboard, and list failure modes with their handling.
- Design a REST layer in front of a legacy manufacturing system, listing resources, error shapes, pagination, timeouts and how you would isolate the legacy system.
- Write a schema for high-frequency sensor readings with partitioning, indexes, retention and two example queries.
Deliverable: A telemetry architecture diagram with failure handling, a REST middleware design and a sensor schema with queries.
Practice prompt ↗Practice prompt ↗Practice prompt ↗06Frontend, test automation and UI experience
- Outline a Cypress or Ranorex suite for a web control interface, using page objects or Cypress custom commands, stable selectors, API-based test data setup and CI integration.
- Write a frontend performance list covering code splitting, lazy loading, bundle analysis and virtualised lists, and attach a real example from your work.
- Write your component-driven UI story with the decision you owned and a measurable result.
Deliverable: A test suite outline, a performance checklist with one real example and a written UI project story.
Practice prompt ↗Practice prompt ↗Practice prompt ↗07Behavioral stories, motivation and offer stage
- Write four stories for process limitations, deadlines or vague requirements, cross-functional work and a code review disagreement, each with your action and a result.
- Write and rehearse your answer to why you want to join ABB, tied to one business area and your experience.
- Rehearse a project walkthrough covering architecture, trade-offs, error handling and testing, then list your questions for the team and your career direction.
Deliverable: Four written stories, a motivation answer, a rehearsed project walkthrough and a question list for the final discussion.
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 behavioral interviews with business unit managers that explore project history and team collaboration style, and some tracks add a project or use-case presentation. For a role where software controls physical equipment, prepare stories about reliability, working with hardware and product colleagues, and handling feedback. Each story needs your own action and a result.
Describe your experience building component-driven user interfaces using modern JavaScript/TypeScript framewor
Describe your experience building component-driven user interfaces using modern JavaScript/TypeScript frameworks such as React or Vue.js.
Approach
- Pick one UI you shipped and describe its component structure in a sentence: the page-level container, the reusable pieces and which of them owned state. Then spend your time on one decision you made, such as lifting state up versus using a store or context, and your reasoning.
- Explain how data reached the components, whether through props, hooks or composables, a fetch layer, or WebSocket updates for live data. State how you kept rendering cheap with stable keys, memoised selectors and list virtualisation for long lists.
- Say how you tested it: component tests for pure pieces, a few end-to-end flows, and typed props shared with the API contract. If you used only React or only Vue, say so and name the equivalent concepts in the other.
- Finish with a result you can check, such as smaller bundle size, faster render of a large grid, fewer UI defects or components reused by another team. A list of frameworks without a decision you owned is the weak version of this answer.
Follow-up
- How did you decide where state should live, and what would make you move it?
- What made the interface slow, and how did you find the cause?
- Which component would you redesign today, and why?
Describe a situation where you identified a significant technical or process limitation in your team. How did
Describe a situation where you identified a significant technical or process limitation in your team. How did you raise and address it?
Approach
- Choose a limitation you could evidence, such as a manual release process, flaky CI, missing logging or a design that blocked changes. Describe it with a fact or measurement, for example how many releases it delayed or how often it failed.
- Describe how you raised it: who you told, what you brought with you (data, a short proposal, options with costs) and what you asked for. Show that you took the problem to the person who could decide rather than complaining sideways.
- Describe what you did yourself, whether a prototype, a pilot on one component or an agreed plan with owners, and how you handled resistance or the cost of the change.
- End with the result and how you checked it. Mention what you would change in how you raised it. The failing version names a problem and leaves the action to someone else.
Follow-up
- How did you convince people who did not see it as a problem?
- What did the fix cost, and was it worth it?
- What would you do differently the next time you spot a similar issue?
Tell me about a time you had to work with tight project deadlines or vague requirements. How did you prioritiz
Tell me about a time you had to work with tight project deadlines or vague requirements. How did you prioritize deliverables?
Approach
- Open with the constraint in two sentences: what was due, what was unclear and who was affected. Then say how you cut the ambiguity, by asking the requester questions, writing the assumptions down and confirming them, or building the smallest slice that could be validated.
- Explain how you prioritised: ranking by user or safety impact, by risk and by dependency order. State which work you deferred or cut and who agreed to that. A story in which nothing was cut is hard to believe.
- Show how you kept stakeholders informed as the picture changed, for example with a short status note and a revised plan when an assumption proved wrong.
- Report the outcome honestly, including quality trade-offs and any follow-up work. Avoid a story that is mainly long hours; show a decision instead.
Follow-up
- Which requirement did you choose to drop, and who signed off?
- What happened when one of your assumptions turned out to be wrong?
- How would you handle the same deadline if it involved safety-related code?
How do you approach cross-functional collaboration when working alongside hardware engineers, mechanical desig
How do you approach cross-functional collaboration when working alongside hardware engineers, mechanical designers, and product managers?
Approach
- Pick a project in which your software depended on hardware, mechanical or product decisions. Name the other roles and what each needed from you, such as signal lists, timing limits, units, protocol details or a delivery date.
- Show the mechanisms you used to work across disciplines: an interface specification agreed in writing, a simulator or mock device while hardware was unavailable, shared terms, and early integration sessions instead of one late handover.
- Give a conflict or surprise, for example a hardware change after your code was written, and describe how you traced it, who you spoke to and how the plan changed.
- Close with a result such as an earlier integration, fewer defects found in testing on real hardware, or a spec that others reused. Saying only that you communicate often is the generic version of this answer.
Follow-up
- What did you do when the hardware was not available to test against?
- How do you explain a software constraint to someone who does not write code?
- Tell me about a time a hardware or product decision changed your design late.
Give an example of how you handle constructive feedback or a technical disagreement with a senior engineer dur
Give an example of how you handle constructive feedback or a technical disagreement with a senior engineer during a code review.
Approach
- Describe the review disagreement in neutral terms: what the change was, what the senior engineer asked for and where you disagreed. Choose a technical disagreement, not a personal one, and one where both positions had merit.
- Explain how you tested your own view first by restating their concern, checking for a defect you had missed and looking for evidence, such as a benchmark, a failing test or the project's coding standard. Then show you presented evidence rather than opinion.
- Say how it ended. You might have changed your code, they might have accepted your approach, or you both agreed a middle path or asked a third person to decide. Include what you learned about review practice, such as small changes, clearer descriptions or a written decision.
- If you were wrong, say so plainly and describe what you changed. A story where you are always right, or where you gave in without understanding the reason, answers the wrong question.
Follow-up
- What would you have done if the evidence had not settled it?
- Tell me about feedback in a review that changed how you write code.
- How do you give review feedback to someone more senior than you?
- 01
Describe a situation where you identified a significant technical or process limitation in your team. How did you raise and address it?
- 02
Tell me about a time you had to work with tight project deadlines or vague requirements. How did you prioritize deliverables?
- 03
How do you approach cross-functional collaboration when working alongside hardware engineers, mechanical designers, and product managers?
- 04
Give an example of how you handle constructive feedback or a technical disagreement with a senior engineer during a code review.
- 05
Describe your experience building component-driven user interfaces using modern JavaScript/TypeScript frameworks such as React or Vue.js.
- 06
Why do you want to join ABB, and how does your background fit its industrial technology focus?
How many rounds are there and how long does the process take?
Candidates report six stages: a talent acquisition screening, an asynchronous video submission or online assessment, technical panel rounds, deep technical probing, behavioral evaluations and a final offer discussion. The reported span is about 4-6 weeks, although some accounts give shorter times. Business unit, location and local scheduling change both, so ask your recruiter for your own sequence.
ABB Software Engineer candidate reports ↗Do I need electrical or hardware knowledge for a software role?
Candidates report that basic electrical understanding is useful for embedded, instrumentation, robotics and drives teams, where schematics and drive concepts appear in questions. For full-stack or enterprise web teams, standard software engineering matters more. Check the posting, and if it is hardware-adjacent, learn the basics of variable frequency drives, interrupts and schematic reading.
ABB Software Engineer candidate reports ↗Which languages and tools should I prepare?
The listed requirements include one object-oriented language (C++, Java or C#) or a web stack such as React, Vue.js or Node.js, plus Git, data structures, algorithms and OOP principles. Nice-to-have items include Embedded Linux, RTOS, Modbus, CAN bus, OPC UA, Azure DevOps, Docker and Kubernetes. Prepare your main track in depth and the others at overview level.
ABB Software Engineer candidate reports ↗Will I be asked to present a project or complete a homework task?
Candidates report that several tracks ask for a walk through a past project or a use-case or homework presentation. Prepare one project covering architecture, trade-offs, error handling, testing and lessons, and be ready to explain how the design would behave when a device or network fails.
ABB Software Engineer candidate reports ↗What does the asynchronous video or online assessment stage involve?
Candidates report either a video submission or an online assessment covering aptitude and basic programming logic, with electrical or domain concepts for some teams. Practise plain problems in your language, and record a spoken answer to check that it is structured and clear.
ABB Software Engineer candidate reports ↗Are the interviews remote or on-site?
Candidates report that early stages, such as the screening and technical panels, are usually held over video. Some later stages, such as manager rounds, group presentations or facility tours, may be held at a local ABB site, depending on the team. Prepare a quiet setup for video stages and ask about the format of later ones.
PracHub Software Engineer practice ↗How should I prepare for the behavioral rounds?
Use the situation, task, action and result structure, and make the action yours. Prepare four distinct stories for process limitations, tight deadlines, cross-functional work and code review disagreement, plus an answer on why you want to join ABB. Each should have a result you can state.
ABB 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.
- 01ABB 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.
Raytheon Technologies Corporate Headquarters Software Engineer Interview Guide
What Raytheon Technologies Corporate Headquarters asks Software Engineer candidates, from reported rounds and questions.
One Software Engineer Interview Guide
What One asks Software Engineer candidates, from reported rounds and questions.
Lattice Software Engineer Interview Guide
What Lattice asks Software Engineer candidates, from reported rounds and questions.
Freshworks Software Engineer Interview Guide
What Freshworks asks Software Engineer candidates, from reported rounds and questions.