We've used what we call the "Kobayashi Maru" coding exercise with developers.<p>It was code deliberately filled with various errors, from JavaDoc with @param names not matching argument names, to generic issues, to more subtle issues. One of the last ones involved threading and concurrent access. It also had a test suite to help candidates gauge their progress for programmatic issues, not so helpful for code style issues (that JavaDoc comment).<p>Basically, we wanted to see the dev a) look at the reds and yellows in their IDE, b) run the tests, and then c) prioritise the issues. And d) say "these tests are wrong"<p>It was a highly effective filter for people with "qualifications" from dubious private training institutes (one candidate fixated on the red Javadoc for a mismatched parameter name, we hinted that he check the arguments in the method, he muttered "method, method, method..." to himself while scrolling down the code looking for the actual word 'method' - spoiler, he didn't find it, and he didn't get the job), but we left it behind when we found it was causing candidates genuine anxiety when they couldn't get all the tests to pass - which was intentional - anyone who figured out that the tests were deliberately wrong was an instant hire.<p>But we felt it was unfair, it's very very hard in a job interview to say "hey, I think your tests are wrong" so we dropped it.<p>These days, we use a simple filter - write code in your preferred language to find the element in the list that only has one occurrence. It's surprisingly effective as a first pass. People with years of Scala on their resume from writing Spark jobs, who choose Scala, but who can't quite get the hang of how you define an array of X in Scala... when you find yourself telling them to use square brackets for generics instead of angle brackets, you learn a lot about their actual capabilities vs. their projected.
Things that come to mind for bad schematic review:<p>* Linear voltage regulator with high input voltage powering an obviously very power hungry load.<p>* No ESD protection/current limiting for sensitive pins exposed to outside world.<p>* Tantalum capacitors with very narrow voltage rating margin<p>Another tactic I like (something similar is mentioned in sibling comment): a small design problem representative of real life task.<p>For generic EE position I like the following: "Suppose there is a project using this microcontroller. Project requires this micro to power an externally connected solenoid with this specification."<p>I find this reveals a lot of the seniority/thought process of the candidate: what (if any) questions candidate is asking to better understand the problem ("Do I need to consider output short circuit? What are the cost/size constraints? Don't we need a internal/external feedback?"), what is their process of component selection (if that is required in job description) and the suitability of this process for the needs of particular company.<p>Now, if only I could come up with similar strategies for software positions...
<i>My example of this: I have yet to meet a junior EE candidate who understands the need for decoupling capacitors in digital circuits</i><p>That says a lot about the state of education. I'm not even officially an EE, and only did some embedded hardware stuff and some electronics as a hobby, yet I know what that's about.
> Then, you give them a fake schematic of the circuit board, and ask them to troubleshoot the problem.<p>> Here’s the test: the fake board schematic should be absolutely riddled with errors. All sorts of errors - errors that you’ve seen before, errors that you’ve heard about before, errors that have thrown your product development efforts for a loop. These errors should run the gamut of severity<p>I think you need to communicate to the candidate that this is a board with <i>a lot wrong</i>. If you hand me something that looks like a real board made by the organization, and it's of exceptionally poor quality-- panic will ensue. Is there a single issue I'm supposed to point out? Is the interviewer not aware of how bad this is? Do I even want to work at a place producing shoddy work like this?
I’ve tried (and abandoned) a similar question suite for Security SWEs. Giving people sample code riddled with security flaws and asking them to explain what was wrong.<p>I found it difficult in the security domain since so much of it is context dependent (what’s the interface? Is this code in the kernel? Are you concerned about speculative side channels?). I also found it difficult to calibrate.<p>There’s probably a good question space in there if I were to spend time testing the questions more, but there are enough other questions in the neighborhood that I’ve moved on.
Excerpt:<p>"Need some ideas for a crappy schematic? Here are some easy ones I can think up off the cuff:<p>o Current limiting resistors missing (BJTs, diodes, etc.)<p>o Shorting a potentiometer node to a rail<p>o Voltage regulators missing capacitors at input/output<p>o Missing pull-up/pull-down resistors on digital buses<p>o Missing decoupling capacitors<p>o Powering ADC reference voltages from a switching supply<p>o Transistors placed in wrong/backwards configuration<p>o No signal conditioning/buffer for analog signals into ADC<p>o AC coupling high-pass filter sets corner frequency too high into ADC<p>o Reset sequence of digital component is wrong<p>o Antenna is missing a matching network/filter<p>o Clock/data lines swapped backwards in digital bus<p>o No pull-up/pull-down resistors on IC configuration pins<p>o No frequency compensation on unstable opamp circuits<p>o Improper gain settings on opamp circuits"<p>Fascinating!<p>Would love to see a book about these errors and others -- with the title:<p>"Learn EE (better!) -- by studying things that don't work"<p>The book could be divided into chapters... Each chapter delves into another way that a circuit can fail, along with an explanation of why, and the correct way to engineer that type of circuit/circuit component... The chapters would be ordered from the most common errors to the less common ones... it would be a great teaching tool for people who wanted to become better at EE...
You don’t need anything fancy in an interview to figure out someone’s competence with circuits. Granted, it depends on what level you’re targeting and what specialties you’re looking for, but even asking them to draw a schematic of a lit LED may be very telling.
>>> Then, you give them a fake schematic of the circuit board, and ask them to troubleshoot the problem.<p>Is the board built to the schematic?<p>That's my first question when a board loses its magic smoke.
I love that idea. I always try to be cognizant of the stress thing too. I cannot count the number of times I've given the candidate a problem based on some basic EE or CS concept, only to have them over-think the heck out of it because the answer seemed "too easy."<p>While its interesting to see what vector their over-thinking takes, it doesn't help move the interview along.<p>Doing similar examples with code is also good, as debugging is probably a big chunk of the time people will spend on things. And there are various shades of bug from "in your face" like you have an if statement in C or C++ that uses only one = sign, to "subtle" where a local definition masks a global variable, to just plain ridiculous like structure packing alignment issues based on compiler options.<p>All good ways to see how much of the 'craft' the candidate knows versus the 'facts'.
I only have a basic level of understanding of EE stuff, but I've been interviewed like this for software jobs, and thought it worked well. Just 1 page worth of code, riddled with glaring errors, subtle errors, security issues, code smells, etc. Naturally, spotting more things and more subtle things faster is good.
I had one of these for an interview a few months ago. A huge schematic and I was told to find out "why it wouldn't work". It took me about 10 minutes to figure out that one FET's diode network was set up so that it'd short out and fail, and I ended up failing the interview for taking so long and labeling every subsection. They told me this was a spot test, and this kind of thing should just jump out immediately if you're smart enough. They also said me immediately jumping into the details of each component and its role was a red flag and they didn't think I'd be able to get the big picture of circuit design.<p>I've been thinking about this since and I don't know how I can fix this. I just don't know any other way to think other than looking at the details. Does their assessment that this is a flaw seem on point?
> <i>...should be absolutely riddled with errors.</i><p>Same applies to code in an interview; it should have syntax, efficiency, correctness errors and more.
I get that this is intended to be a general exercise in spotting schematic errors. But as someone who brought-up and debugged numerous complex power supply boards for mobile electronics, it seems to me the most important and useful bit of information is missing from this exercise: show me where the smoke came out!
Here are some of my RF specific interview questions. Spend no more than 1 minute on each.<p>Power Amplifiers<p>Q: Where do GaAs/GaN FETs DC gate currents originate, and why are they positive and negative?<p>Q: How would you temperature compensate the transistor DC bias.<p>Q: What is AM-AM and AM-PM distortion and how would you measure it?<p>Q: Give an example of a “memory effect”.<p>Passive RF/Microwave Circuits<p>Q: How would you measure unloaded Q of a resonator?<p>Q: What is self-resonant frequency of a component (i.e. chip L or C) and when is it useful.<p>Q: Why does a stripline coupler typically perform better than microstrip?<p>Q: What’s the characteristic impedance and electrical length for the lines in a 2-way Wilkinson splitter.<p>Q: Where does the current flow on a microstrip line and its return path?<p>Test and Measurement<p>Q: What’s the difference between RBW and VBW on a spectrum analyzer?<p>Q: When is a sliding load used in VNA calibration and how does it work?<p>Q: What does noise marker mode do on a spectrum analyzer?<p>Q: How would you measure a SMT part at several GHz with proper reference planes?<p>Q: What’s a quick way to tell if your spectrum analyzer is contributing to IMD3.<p>Digital Comms<p>Q: Why are RRC filters used so frequently?<p>Q: Describe the flow of PSK receiver?<p>Q: What is an Error Vector Magnitude (EVM) measurement?<p>Q: What effect does clock jitter have on an ADC or DAC.<p>Q: Would a class C amplifier work better with OFDM or FSK?<p>Antennas<p>Q: What typically limits the bandwidth on a single frequency patch antenna?<p>Q: What’s common mode radiation on a coax (to antenna) transition and what are a couple of ways to minimize it.<p>Q: What happens to an antenna’s input impedance and directivity when you move it very close to a “ground plane”.<p>Q: What’s an IFA or PIFA antenna and how does it relate to a monopole; why are they so common in compact devices.<p>Q: Given a VNA and two linearly polarized horn antennas with known gain, how would you measure the gain of a circularly polarized antenna?<p>RF Front Ends<p>Q: What are the typical blocks in a superhet receiver (or down conversion chain)?<p>Q: What typically determines diode mixer linearity?<p>Q: What’s IMD?<p>Q: What’s more important in LNA; noise or impedance match?<p>Q: What’s cross-modulation?<p>Synths and Oscillators<p>Q: What are the advantages and dis-advantages of a Frac-N over an Integer-N synth?<p>Q: What specs would you look for in a linear regulator to isolate a synth analog section from a switching supply?<p>Q: Given you don’t care about settling time, how would you set loop filter bandwidth to achieve best noise performance?<p>Q: Given you don’t care about settling time, how would you set loop filter bandwidth to achieve best noise performance?<p>Q: What do synth ICs have charge pump trim settings (i.e. upper and lower different gains)?<p>Connectors and Waveguides<p>Q: What is skin effect?<p>Q: What is the torque specification for a 3.5mm connector?<p>Q: Why is nickel used in plating processes? What effect does it have on RF?<p>Q: What’s the highest frequency that an SMA connector can be used for TEM propagation? What happens above that?<p>Q: If you needed to slice a rectangular waveguide in half, would you slice down the broad wall or the narrow wall? Why?<p>Simulation<p>Q: Why would use you use 2D thick metal (or 3D EM) on edge coupled lines? Is there a rule of thumb?<p>Q: Would you use harmonic balance or transient simulation (or both) to model a simple diode detector?<p>Q: What are some quick methods to determine if your EM simulation is plausible?<p>Q: Given microstrip element models, would you model a short, wide line as a line with two steps, or a cross with two long stubs; the layout is identical.<p>Q: What type of EM simulator (2D or 3D, infinite or finite boundary, gridded or gridless, time or frequency domain) would you use for: patch antenna, planar filter, horn antenna, cavity filter. Why?
Sorry but this is probably terrible. Without knowing the part datasheet this interview isn’t going to tell you much. I think it’s much better to focus on signals/systems plus some circuit level problems that focus on the basics; open drain outputs, op-amps, RC/RLC circuits, transmission lines etc...