What Does an Embedded Systems Interview Actually Test?

When a job goes up on LinkedIn, we get 1,000+ applicants within 1-2 days. Freshers, students, experienced engineers — all applying.

Filtering that down to 50 interview candidates takes days. What are we looking at?

Not marks. Academic scores mean almost nothing to us at this stage.

We look at whether someone is genuinely passionate about embedded and electronics. Projects they've built. GitHub repositories, Online projects, Competition participation, etc. Any evidence that they've actually made something, not just studied it.

If all someone has is a degree and a CGPA, they're very likely to be screened out before we even talk to them.

Every technical interview I take starts with the same question. I've given it to freshers, interns, CDAC graduates, and experienced developers. It decides whether we continue or stop within the first five minutes.

Here it is:

"I give you one LED and a 9V battery. How do you connect it to make it glow?"

That's it. Nothing complicated. No microcontroller, no code, no datasheet.

But here's the thing — only about 1% of candidates answer it correctly on the first try.

What I'm looking for is someone who immediately asks or mentions the current-limiting resistor. That tells me they understand that the LED has a forward voltage drop, that too much current will destroy it, and that a resistor is needed to protect it, if they can do a rough calculation. Also, LED leads identification- how they detect it- tells all about their practical understanding.

What I usually hear instead: the candidate connects it directly. Or they name the anode and cathode correctly but forget the resistor. Or they know a resistor is needed but can't explain why.

Candidates from good engineering colleges. Candidates with expensive PG diplomas. Experienced developers. Most of them fail this question more often than you'd expect.

If someone can't answer this, the interview ends there. Because if the fundamentals aren't there, nothing else matters.

Once a candidate gets past the LED question — or gets partway there — I go deeper. Always starting from the basics.

Parallel resistors. "If I connect two 10kΩ resistors in parallel, what's the equivalent resistance?" I want the answer without a formula. If a candidate starts writing out calculations, that's a signal — this should be immediate for any engineer.

Bit manipulation. A = 0x80; A = A | (1 << 1); What's the value of A? Or: write code to set the 7th bit HIGH. This is day-one embedded programming. I need to see it done without hesitation.

ADC calculation. "An 8-bit ADC has a 5V reference. The input is 2.5V. What's the ADC output?" Again, I'm checking whether they can think through the calculation, not remember a formula.

Real circuit design. "I want to control a 230V bulb from a microcontroller — ESP32, Arduino, whatever you're comfortable with. Walk me through the hardware connections." This is where I see whether they understand isolation, relay driving, or using a TRIAC. Most candidates go blank here.

Project understanding. Projects on their resume, I ask: what exactly did you do, and how did you do it? I'm not looking for a polished answer. I'm checking whether the work was real.

I sometimes check for something harder to teach: engineering intuition. Everyone knows 200 km/hr on a bicycle is impractical-  you have an instinctive sense of speed. Do you have the same sense about voltage and current? If I tell you a standard 5mm LED needs 2A to glow, does that feel wrong immediately? It should. Or how much max current controllers(ARM, PIC, AVR) consumes- if someone say 1A or 5A 😐

That instinct — knowing when numbers are off before doing any calculation — separates engineers who truly understand electronics from those who've only memorised it.

Notice what's not on this list: ARM architecture details, RTOS internals, advanced peripherals. I don't ask about those. If someone has strong fundamentals and genuine engineering passion, they'll pick up RTOS or 32-bit controllers quickly with the right guidance. If the basics aren't there, no amount of advanced knowledge covers it.

Once fundamentals are solid, interviews at more senior or technical companies will go into:

Embedded C. Bit manipulation, pointers, volatile, struct packing, circular buffers, state machines. Not as theory — as code you write on a whiteboard. [LINK: Embedded C Programming track]

Microcontroller peripherals. GPIO, UART, I2C, SPI, timers, ADC, PWM, interrupts. Not just "I know what SPI is" — but can you explain the modes, calculate a baud rate register value, describe what happens when clock speeds don't match. 

Component selection. Can you look at a component and know what it is and where it belongs? Can you select the right transistor for switching a relay? Can you explain why you'd use a Schottky diode here and a TVS diode there? [LINK: Component Skills track]

Debugging scenarios. "Your UART output is garbled. How do you start?" "Your ISR fires but the main loop never sees the updated value — what's wrong?" No single correct answer. I want to see a structured approach: check the obvious first, isolate variables, use the tools available.

We need engineers who think in voltage, current, and binary — not people who've memorised formulas to pass an exam.

The difference shows up fast. When a candidate understands why a resistor is needed — not just that one is needed — they'll figure out the right value for any LED, any supply voltage, any situation. That kind of understanding transfers. Memorisation doesn't.

The candidates who do well are almost always the ones who've actually built things. A project they stuck with, debugged for real, and understood end to end. Not a course certificate. Not a CDAC diploma. Something they made work with their own hands.

Expensive courses and PG diplomas. I've interviewed candidates from CDAC, candidates with master's degrees, candidates who've spent ₹1–2 lakh on training. A certificate has never been the reason someone got hired. It might get their resume opened. That's about it.

Memorising interview question lists. Multiple websites and YouTube influencers share "top 100 embedded interview questions" lists. These lists feel like a shortcut to crack the interviews. Many candidates walk in having memorised every answer on every list. It shows immediately- the answers are rehearsed, not understood. One follow-up question they haven't seen before, and it falls apart.

Watching tutorials & building as it is. Watching someone else build a project and following his tutorial with the given code, the circuit won’t help. You are not developing anything- just assembling things.

Also, considering their grades will help them to secure a good job.

Focus on the signals over noise- Build skills

Identify the noise. Don’t go after certificates, grades or those expensive PG diplomas or courses- go for skill building. Design, debug, build. That process needs to happen hundreds of times before it becomes instinct.

Build things. Solve problems. Debug real circuits.

That's not a vague answer — it's the only thing that consistently produces engineers who can handle an interview.

The Minimal, No-Fluff Learning Path that I recommend-

Step 1- Electronics Fundamentals

Start with the basic Electronics: resistors, capacitors, transistors, LEDs. Skip the heavy theory and focus on behaviour — voltage dividers, transistors as switches, capacitors in power supply filtering.

Also basic Digital Electronics in parallel: number systems, gates, latches, flip-flops. These will pay off in every step that follows.

Reference books: The Art of Electronics or Practical Electronics for Inventors — either works as a companion, not a primary.

On EWskills, follow the Component Skills track — practical, scenario-based, product-design-level problems. (Practical Electronics Skills and Digital Electronics Skills tracks with built-in simulation coming soon.)

Step 2- Embedded C

Move into Embedded C only after Step 1. The focus here is hands-on: write bit manipulation code, pointer operations, and common C patterns from scratch. Don't just read examples- submit code and verify it runs correctly.

Video courses can help you grasp concepts, but without practice, that understanding fades. Practice builds instinct, with practice, you stop remembering it- you just know it.

Follow the EWskills Embedded C Programming track for structured, auto-graded practice.

Step 3- Microcontroller Peripherals

Work through GPIO, ADC, UART, SPI, I2C, timers, and interrupts. The benchmark: can you configure a peripheral directly from a datasheet without external guidance? That's the interview-ready bar.

Set up a basic lab in a corner of your room- with any AVR, ESP32, or STM32 board, a basic setup will cost around ₹4000-₹5000. This investment is mandatory and 100x better than spending on courses. (Lab setup tools details- https://www.ewskills.com/arduino/mastering-microcontroller-concepts )

Follow the EWskills Mastering Microcontrollers track. (Simulation-based skills with auto-validation launching soon.)

Step 4- Build Small Real Projects

Build small applications from scratch: home automation, a control and monitoring system, a sensor data logger. No YouTube tutorials, no copy-paste from guides. This is where interview-ready thinking actually forms, builds the confidence.

Consistency matters more than intensity. Two problems a day, every day, for three months is worth more than a weekend sprint before an interview.

• Focus on fundamentals- without it you won’t be able to develop the engineering thinking.
• What interviewers are hiring for is engineering thinking- not formula recall, not certificates, not marks.
• The candidates who do well have almost always built and debugged real things.
• Expensive courses and memorised question lists rarely help. Structured, hands-on practice does.
• Fundamentals first: components → Embedded C → microcontroller peripherals. In that order.

FAQ

Q: Do I need to know a specific microcontroller? No. What interviewers care about is whether you understand the underlying concepts — GPIO behaviour, timer calculations, interrupt handling — well enough to apply them anywhere. That said, register-level experience with AVR, STM32, or ESP32 will set you apart from candidates who've only ever used Arduino's digitalWrite().

Q: Embedded C or C++ — which should I focus on first? Embedded C. Almost all entry-level firmware job descriptions list C. C++ is increasingly relevant in IoT and automotive, but the time to learn it is after your C fundamentals are solid — not before.

Q: How long does it take to be genuinely interview-ready? If you can write basic C and have some digital electronics background, 12–16 weeks of consistent daily practice — building real circuits, solving graded problems — is usually enough to interview confidently for junior firmware roles. Not cramming. Daily.

Q: I'm a complete beginner. Where do I start on EWskills? Start with Component Skills to build your hardware foundation. Then Embedded C. Then Mastering Microcontrollers. Work through them in order, solve 2–3 problems a day, and don't skip ahead.

Written by-
	Ganesh Khomane (Co-Founder EWskills)
	Linkedin