This electrical engineering interview candidate did 2 things that I’ve never seen.

I’ve been seeing a lot of painfully generic interview advice splattered all over the internet. Some “gurus” say that you have to be confident, others say that you have to talk constantly, and others say that you have to talk little. The jungle of interview advice out there is difficult to navigate and is frankly difficult to discern right from wrong.

My manager tasked me to conduct an interview with a potential hardware engineering candidate, and it was one of the best that I’ve ever seen. Not only did he answer questions correctly, but he inspired confidence that the process that he would take was sound. I noticed 2 special occurrences within my notes.

The “choose your own adventure” interview style

EEs love depth. They love to get lost within the theoretical machinations of engineering theory and design so it seeps also into the interview process. Unfortunately, the interview process is timebound, so this can burn candidates.

My candidate asked me a very natural question: “I can answer at a high level first, then go into component selection and corner cases. Which do you prefer?”

I frankly loved this… it not only allowed me to gauge the candidates thought process, but it magnified his ability to think at a bird’s eye perspective. Oh yeah, and he crushed the technical aspects.

I fell in love with this interview framework

I used to be a TA within my EE undergrad. I’ve seen my fair share of undergrads doing math and attempting to decipher it as if I’m trying to crack the Rosetta stone. Engineers (other than maybe doctors) probably have some of the worst handwriting.

So this candidate comes in, and I ask him to draw a circuit diagram on the whiteboard. He does anything but that…

First he writes 3 columns. The first column split into constraints and assumptions, then the middle column was design, and the last column split into testing and risks. He then proceeded to go through all 5 of those categories, asking me insightful questions into the scenario, requirements, and function. He then wrote everything in, so that we could all see and remember, and then finally worked through the entire thing from conception to testing.

I thought this was a brilliant framework and I could see everything.

Conclusion

I’ve seen others mention that you must “take control of the interview”. Seeing it in action fully blew me away. Unfortunately, to do this, there has to be a little bit of legwork and studying that you have to do before the fact. While interview resources and topics exist dime a dozen on LeetCode, Voltage Learning, Art of Electronics, or even the JD, as engineers we definitely underrate the value of networking.

Before any interview, reach out to employees at the firm to really understand what it’s like to work there. There’s no better advice than from the source, and you never know where your network will take you.