What We Actually Look For When Hiring an Embedded Automotive Engineer

A candid Q&A with one of our senior engineering leads, who's sat on the other side of this table more times than he can count.

We sat down with one of our engineering leads — someone who's interviewed candidates for embedded and ADAS roles for the better part of a decade, across two companies before BlinkThor — and just asked him to talk honestly about what actually happens on his side of a hiring interview. No corporate talking points. Here's the conversation.

Let's start simple. What actually makes a CV stand out to you?

Honestly? Specificity. I can tell within about ten seconds whether a CV was written by someone who did the work or someone who's describing the work at arm's length. "Worked on CAN communication for automotive ECU" tells me almost nothing. "Debugged an intermittent bus-off condition traced to an oscillator tolerance mismatch across four nodes" tells me this person was actually in the trenches, because you don't write a sentence like that unless you lived it. I'm not looking for jargon — I'm looking for the specific texture of a real problem, because that's very hard to fake convincingly.

Is there a specific technical question you find yourself asking almost every time?

Yeah, and it's not even that clever — I ask people to walk me through a bug they personally found and fixed, start to finish, in as much detail as they're comfortable with. Not "tell me about a challenge," the corporate version of that question. The actual bug. What the symptom was, what you initially suspected and were wrong about, how you actually found the real cause, what the fix was.

The reason I like this question so much is that it's almost impossible to bluff convincingly for more than about thirty seconds. Someone who really debugged something will naturally include the wrong turns — "I first thought it was the power supply, spent a day on that, then realized..." — because that's how debugging actually goes. Someone reciting something they read about, or something a teammate actually did, tends to give a suspiciously clean, linear story with no dead ends, which is basically never how a real hard bug goes.

Do you weigh certifications heavily, or do real projects matter more to you?

I'll be diplomatic and then I'll be honest. Diplomatically: certifications show initiative and a baseline of structured knowledge, and I don't dismiss them.

Honestly: I have never once, in probably a hundred-plus interviews, had a certification tell me something more useful than fifteen minutes of someone describing a real project did. A certification tells me you can learn material and pass an assessment. A real project — even a messy, unfinished, "we never shipped this" side project — tells me how you actually think when a problem doesn't have a clean textbook answer, which is most of what the job actually is. If I had to choose between a candidate with three relevant certifications and no personal projects, versus a candidate with zero certifications and one genuinely interesting half-finished GitHub repo they can talk about in real depth, I'm leaning toward the second person almost every time. Not because certs are bad — because depth of engagement with a real problem is just a stronger signal than a completed course.

What's the most common mistake you see candidates make?

Overselling breadth at the expense of depth. I get a lot of CVs that list what feels like fifteen different domains — AUTOSAR, ADAS, cybersecurity, RTOS, cloud, AI, telematics — and when I ask a genuinely basic follow-up question in any one of those areas, the answer is noticeably shallow. I understand the instinct; the job market feels competitive and it seems safer to seem broadly qualified. But in practice it does the opposite of what candidates intend — it makes me trust the CV less overall, not more, because now I'm wondering how much of the rest of it is similarly inflated.

I'd genuinely rather see three things you can go deep on than twelve things you've only touched. If your CV says "AUTOSAR" and you can talk for ten focused minutes about BSW configuration specifically, that's worth more to me than a CV that also claims cybersecurity and cloud and AI experience but can't go past a surface-level answer on any of them.

Is there anything candidates do that immediately makes you more excited about them?

Asking me a genuinely sharp question back, especially about something that isn't in the job posting. Most candidates ask reasonable, expected questions — team size, tech stack, growth path, all fine. Every so often someone asks something like "how do you handle the tension between AUTOSAR's static configuration model and needing to iterate quickly on early-stage feature development" — something that shows they've actually thought about the domain, not just prepared for the interview. That kind of question tells me more about genuine engineering curiosity than almost anything in the CV does.

Any final advice for someone job hunting in this space right now?

Don't try to be what you think we want. Try to be specific about what you actually did, including the parts that didn't go well. I promise you, across enough interviews, "I tried this approach, it didn't work, here's why, here's what I did instead" reads as more competent than a suspiciously perfect account of everything going smoothly. Nobody's engineering career actually looks like that, and pretending otherwise in an interview is usually the thing that gives it away.

Interested in what it's actually like working on embedded/ADAS problems day to day at BlinkThor Labs? We're always happy to talk, even if you're just exploring.