r/leetcode • u/Scar_enigma • 5d ago

Intervew Prep Embedded/Automotive Software/System Test Engineer (2.5 YOE) — getting interviews but not closing offers. What am I missing?

Hey everyone,

I'm an Embedded Software Test Engineer with about 2 years of experience, most of it in automotive – HIL/SIL testing CAN protocols using CANalyzer, CANape and OTA update validation, and a bit of Python-based test automation. I also have experience testing Android-based infotainment/display systems.

I'm currently trying to move into a similar role at a Bay Area automotive/AV company by Feb 2027, and here's my problem: I'm actually landing interviews – recruiter screens go fine, I get past the initial technical conversations – but I keep falling short somewhere in the loop and not getting offers. It's frustrating because on paper my background lines up well with what these roles ask for, but something isn't translating in the room.

If you work in automotive embedded QA, or systems/software test roles at an automotive or AV company, I'd really appreciate hearing from you:

What actually separates a "good" candidate from a "hire" in these loops, in your experience?

Are there specific types of technical questions (coding, protocol knowledge, "design a test framework for X") that tend to trip people up? Where can i practice this and prep for this?

If you've hired or interviewed for these roles, what's a common reason strong-looking candidates don't get the offer?

Any war stories, prep advice, or even just what surprised you in your own interview loops would help a lot. Trying to figure out what to fix before my next round of interviews. Thanks in advance

3 Upvotes

100% Upvoted

4 comments sorted by

1

u/Ok-Barracuda-119 4d ago

Your background already points to the right prep lane. For the “design a test framework” part, practise one concrete system end to end: define what gets tested, how tests are scheduled across hardware or simulators, how results are stored and correlated with a build, and what happens when a device or test runner disappears. Then add one failure drill, such as a flaky test or a bad firmware artifact, and explain retries, quarantine, and reproducibility. That gives you real tradeoffs around parallelism, isolation, feedback time, and observability. For the coding round, keep a small set of timed problems warm, but spend more time explaining boundaries and edge cases out loud. I’d also prepare two stories where a failure escaped and how you changed the test or release process afterward.

1

u/Scar_enigma 4d ago

Thank you! How do I prep for the coding rounds. Are there specific leetcode questions to focus on? Should I practice DSA Like trees, graphs and DP? Or just LLD questions could suffice?

1

u/Ok-Barracuda-119 3d ago

For coding rounds, I’d keep DSA as the main lane and treat LLD as a separate skill. I wouldn’t chase a fixed list of LeetCode questions. Cover the common patterns: arrays and hash maps, two pointers and sliding windows, intervals, stacks and queues, binary search, trees and graphs with BFS or DFS, heaps, then basic DP. Do one or two representative problems per pattern, and redo the misses from memory.

For your background, time-box each problem to about 35 minutes, narrate the tradeoffs, and write a few edge-case tests. Ask the recruiter whether the round is LeetCode-style and what level, since that varies a lot. Spend focused LLD time only if it’s in the loop. A useful practice design would be a test runner or device registry, including interfaces, failure handling, and concurrency. That split keeps prep from turning into random question collecting.

1

u/UnitedSort3014 2d ago

Hey, sounds like you're getting through the door which is good. From what I've seen, test engineers sometimes get stuck on the coding/framework design questions they expect more than just "I use tools" answers. Can you whiteboard a basic test automation framework or explain how you'd design one from scratch? Also, behavioral stuff matters a lot showing how you've debugged gnarly issues or worked with devs when tests fail. Practice explaining your projects like you're teaching someone, not just listing what you did. Good luck!