Embedded systems engineer

What does an embedded systems engineer do?

An embedded systems engineer writes the software that runs inside a device.

Examples are sensors, controllers, medical monitors, payment terminals and factory equipment. This software is often called firmware. It runs on small processors with limited memory and power.

In Singapore, the job sits in electronics and semiconductor firms, medical device makers, precision engineering, marine and aerospace suppliers, and consumer hardware teams. Most engineers work in an R&D or product engineering team and report to an engineering manager.

You work daily with hardware engineers, who design the boards. You also work with test engineers, product managers and manufacturing teams. Security and compliance staff join design reviews when the device handles data or connects to a network.

What the work involves

• Write and review C or C++ firmware for a module, such as a sensor driver or a communication stack.
• Read schematics and datasheets with the hardware team to plan how the software controls each part.
• Bring up new boards and debug faults using a debugger, an oscilloscope or a logic analyser.
• Test the software on real hardware and work out why a failure happened.
• Write test tools and scripts, and document how the device works for colleagues and customers.

Pay in Singapore

Back to top

Skills an embedded systems engineer needs

Back to top

Embedded systems engineer job description

We are hiring an embedded systems engineer to design, build and test firmware for our hardware products.

You will work with hardware engineers from the first requirements through to production. Expect to write C and C++, bring up new boards, debug on the bench and support the product after launch.

Responsibilities

• Design and write firmware modules in C or C++ for microcontrollers and embedded Linux boards.
• Take part in hardware design reviews and security architecture reviews.
• Turn business and user needs into written software requirements.
• Read schematics and datasheets to plan drivers and interfaces.
• Integrate software with hardware and check that the two work together.
• Diagnose faults and study failed test cases to find the root cause.
• Improve speed, memory use, power use and reliability of the firmware.
• Build tools and scripts that automate testing and speed up releases.
• Write technical guides for internal teams and customers.
• Follow secure coding practice and help plan how the device receives updates.

Requirements

• Diploma or degree in electronic engineering, computer engineering, computer science or a related field.
• Fresh graduates can apply for entry roles. Mid-level roles typically ask for about 3 to 5 years of firmware work.
• Solid C, and often C++, for resource-limited devices, plus working knowledge of Linux.
• Experience with common interfaces such as I2C, SPI, UART and CAN, and with a real-time operating system.
• Comfort with lab tools such as debuggers, oscilloscopes and logic analysers, and with Git for version control.

Back to top

Embedded systems engineer career path

The SkillsFuture ladder for this job runs from an associate engineer to an engineer and then to an engineering manager.

The steps move from writing modules to leading designs and then leading teams.

1. Associate embedded systems engineer

   Entry · SkillsFuture title

   You write and test parts of the firmware under guidance, learn the hardware and fix defined bugs.

2. Embedded systems engineer

   Mid · SkillsFuture title

   You lead the design of modules, join hardware and security reviews, and own integration and debugging.

3. Embedded systems engineering manager

   Lead · SkillsFuture title

   You lead the team, set design and test practices, manage budgets and projects, and agree requirements with the business.

Steps marked "SkillsFuture title" follow the career pathway in the SkillsFuture Skills Framework. The others are titles commonly used in Singapore.

Related jobs and their pay

Back to top

Embedded systems engineer interview questions

We wrote these questions from the skills this job needs. They are not an official question bank.

1. What does the volatile keyword do in C, and when do you use it in firmware?

   What a good answer covers

   • It tells the compiler the value can change outside the normal program flow, so it must not cache or remove reads.
   • Used for hardware registers, variables shared with interrupt handlers and memory-mapped I/O.
   • Notes that volatile alone makes access neither atomic nor thread-safe.
   • Gives an example of a bug caused by a missing volatile under compiler optimisation.

2. When would you use interrupts instead of polling, and what rules do you follow inside an interrupt handler?

   What a good answer covers

   • Interrupts suit events that are rare or time-critical, while polling suits simple, predictable loops.
   • Keep handlers short and set a flag or queue data for the main loop.
   • Avoid blocking calls, printing and dynamic allocation inside the handler.
   • Protect data shared with the main code, for example with critical sections.
   • Mentions interrupt priority and latency.

3. Why do many firmware teams avoid malloc and free, and what do they use instead?

   What a good answer covers

   • Heap use can fragment memory and fail at run time on a device with little RAM.
   • Allocation time is hard to predict, which hurts real-time behaviour.
   • Alternatives include static allocation, fixed-size memory pools and ring buffers.
   • Explains how to check stack and memory use with the linker map file.

4. Compare I2C, SPI and UART. How do you choose between them for a new sensor?

   What a good answer covers

   • I2C uses two wires with addressing and several devices on one bus, at moderate speed.
   • SPI uses more wires and chip-select lines, and is faster.
   • UART is point to point and asynchronous, with no shared clock.
   • Choice depends on speed, pin count, number of devices and cable length.
   • Mentions pull-up resistors, clock settings or bus errors.

5. What is priority inversion in a real-time operating system, and how do you prevent it?

   What a good answer covers

   • A low-priority task holds a lock that a high-priority task needs, while a medium-priority task keeps running.
   • The high-priority task is delayed longer than expected.
   • Priority inheritance or priority ceiling mutexes reduce the problem.
   • Also mentions keeping critical sections short and avoiding shared locks where possible.

6. Walk through what happens when an embedded Linux board boots, from power on to your application.

   What a good answer covers

   • Boot ROM loads a bootloader, such as U-Boot, from storage.
   • The bootloader loads the kernel, the device tree and the root file system.
   • The kernel starts drivers and the init process, which starts services and the application.
   • Says where to look first if the board stops at each stage, using serial console logs.

7. Which C++ features do you use or avoid on a small microcontroller, and why?

   What a good answer covers

   • Classes, templates and constexpr can improve safety and cost little at run time.
   • Exceptions, RTTI and heavy standard library containers may add code size and unpredictable behaviour.
   • Avoids hidden dynamic allocation.
   • Notes that project coding rules, such as MISRA-style guidelines, may limit the choices.

8. Your product has three hardware revisions in the field. How do you organise firmware in Git?

   What a good answer covers

   • Uses a main branch with short-lived feature branches and pull requests.
   • Handles hardware differences through board support packages or build configuration, not copied code.
   • Tags releases and keeps release branches for older revisions that still need fixes.
   • Stores build outputs and version numbers so a field unit can be traced to exact source code.

1. Units in the field reset randomly about once every few days. You cannot reproduce it on your desk. How do you investigate?

   What a good answer covers

   • Checks the reset cause register and the watchdog setting first.
   • Adds logging that survives a reset, such as a ring buffer in retained memory.
   • Looks at stack overflow, memory corruption, brown-out and power supply noise.
   • Reviews recent code changes and runs a long soak test with fault injection.
   • Works with the hardware team to rule out electrical causes.

2. A new board revision arrives and your tested firmware does not run on it. How do you decide whether the fault is in hardware or software?

   What a good answer covers

   • Starts with the basics: power rails, clocks, reset line and boot pins.
   • Compares the schematic changes against the datasheet and the pin configuration in code.
   • Runs a minimal test program to blink an LED or print over serial.
   • Uses a scope or logic analyser to check the signals.
   • Shares evidence with the hardware engineer instead of assigning blame.

3. A battery-powered device must last twice as long between charges. What do you change?

   What a good answer covers

   • Measures current draw first and finds the biggest consumers.
   • Uses sleep modes, lower clock speeds and event-driven wake-ups instead of polling.
   • Turns off unused peripherals and batches radio transmissions.
   • Checks the change against timing needs and test results.
   • Agrees trade-offs, such as response time, with the product team.

4. Your team uses an AI coding assistant. It suggests a sensor driver that compiles, but you have never seen the approach. What do you do before merging it?

   What a good answer covers

   • Reads the code against the sensor datasheet, checking registers, timing and error handling.
   • Checks for hidden dynamic allocation, blocking calls and unsafe interrupt use.
   • Tests on real hardware, including failure cases.
   • Keeps proprietary code and schematics out of tools the company has not approved.
   • Gets a human code review like any other change.

1. Tell us about a time you disagreed with a hardware engineer about how to solve a problem.

   What a good answer covers

   • Describes the technical issue and each side's reasoning clearly.
   • Uses measurements or a quick experiment to settle it.
   • Stays respectful and focuses on the product, not on who was right.
   • Explains the result and what changed in how the two of you worked.

2. Describe a bug that was found late in testing. What did you change afterwards?

   What a good answer covers

   • Explains the bug and its cause without blaming others.
   • Shows how you found it and how quickly you told the team.
   • Names a concrete change, such as a new unit test, a static analysis rule or a review checklist item.
   • Shows what you learned about your own habits.

1. Your device records audio and location and sends them to a cloud service. What do you raise with the team under the Personal Data Protection Act (PDPA)?

   What a good answer covers

   • Asks what personal data the device collects and whether the purpose is clear to the user.
   • Raises consent, notice and data minimisation, for example collecting less or processing on the device.
   • Protects data in transit and at rest, and limits who can access it.
   • Plans how to delete data and handle user requests.
   • Involves the data protection officer or legal team instead of deciding alone.

2. Your company plans to sell a Wi-Fi connected device in Singapore. Which security features do you build into the firmware, and which local guidance do you check?

   What a good answer covers

   • Unique device credentials, with no shared default password.
   • Signed firmware images, secure boot where the hardware allows it, and a safe update process.
   • Disabling unused ports and services, and encrypting network traffic.
   • Checks the CSA Cybersecurity Labelling Scheme with the compliance team, as home routers sold here must meet it.
   • Plans how long the product will receive security updates.

Common questions about an embedded systems engineer job

Sources