Reviewing Bad Schematics as EE Interview Tactic
cushychicken.github.io
cushychicken.github.io
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).
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"
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.
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.
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.
The tests are wrong 70% of the time. Either a silly mistake, the design wasn't conceptualized properly (or was changed), or just plain bad code.
If you're tackling your suite one test at a time, and committing code that solves just that test, seeing it fail and then pass, and thinking about why, everything will be fine. If you batch things, or don't debug success, you'll ultimately be buggy.
I wouldn't say that it's 'hard' as such, but it is selecting for a specific type of person; one which you may or may not be more interested in...
* Linear voltage regulator with high input voltage powering an obviously very power hungry load.
* No ESD protection/current limiting for sensitive pins exposed to outside world.
* Tantalum capacitors with very narrow voltage rating margin
Another tactic I like (something similar is mentioned in sibling comment): a small design problem representative of real life task.
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."
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.
Now, if only I could come up with similar strategies for software positions...
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.
Examples he gives:
"Current limiting resistors missing (BJTs, diodes, etc.)
Shorting a potentiometer node to a rail
Voltage regulators missing capacitors at input/output
Missing pull-up/pull-down resistors on digital buses
Missing decoupling capacitors"
I mean ... looking at a schematic how should you know that the voltage regulator doesn't have internal caps without seeing the specs? Missing pullups? How do you know those are not internal? It is stupid.
Can you name one voltage regulator that has them? Maybe you've worked with a few, but just off the top of my head, the 78xx, 317, and 1117 don't, and neither do all the other miscellaneous ones that I've seen in consumer electronics.
It's not my field and I had little clue what was happening at the EE level. Maybe you could argue they are not what is normally meant by saying voltage regulators.
In general I agree with the GP look at how many unpopulated areas exist on modern boards.
How should you know if the lack of input filtering is because of poor design vs the fact that the spec of the power supply changed and you no longer need it?
If it’s not universally true and obvious it’s not a good test.
Modern boards are super complex I’m not an EE but I would more likely flag lacking probe points, probe points which are too far or too close apart or too far from common ground as bad design choices than try to figure out if there are enough caps for the voltage regulator without knowing the full specs of the damn thing.
For all i know that voltage regulator isn’t even being used anymore because the IC or PSU specs have changed mid production but because it was wave soldered with a different soldering method than the other SMTs they already had them on a bunch of boards...
If you can’t reverse engineer the board or the relevant within a few min it shouldn’t be in an interview.
Not an EE but I do a lot of HW RE if anyone puts a modern multi layer doubled sided board on my lap and tells me to point out what’s wrong with it in an interview I would ask them what’s wrong with them.
I would still argue that logic IC have alot of internal pull ups. Or that eg. "Reset sequence of digital component is wrong" is a bad whiteboard question.
Otherwise the person may just ask: "where are caps, or is this thing a module or what?"
They're useful if the voltage drop isn't too large and/or if you need a particularly stable output voltage; contrast them with switching regulators, which are more efficient but have some amount of output ripple.
One design that I worked on used a switching regulator to generate 5V, then linear regulators to generate something like 3.7V and 2.9V for various sensitive analog circuits.
Definitely not a switcher or module, could be an LDO.
I think my best one was shorting a (slow) clock to power, which made the whole thing blink on and off.
If the role's primary function is to do validation prior to manufacture this seems like reasonable. it assumes that new circuits will have some number of fairly common mistakes. in my experience this is very true, despite the skill of the engineer who designed the circuit. missing termination, pullup/downs missing, etc. if the role is applications engineering...well...its far less likely you would be troubleshooting common circuit design issues so much as you would be troubleshooting common system design issues. im sure you can extend this to other functional roles an EE may take on. if the job is to design a MCC and size breakers to minimize arc flash hazards i doubt the applicant will be up on a correctly build half-bridge rectifier.
in that list quoted i've encountered all of it in new designs, including missing stuff plainly stated in the part's application notes (like those regulator caps).
That's exactly what everyone says when candidates fail FizzBuzz.
The best explanation I know is that good candidates get hired quickly, so at any given moment, the candidate pool is dominated by people who keep failing questions like this.
It would be great if they'd stumble over conundrums like "what if there are non-numeric entries in the array." Most often, they just stare and don't even start on the problem.
Are you expecting some map-reduce-like parallel sum, or something else?
- Stress-levels of the candidate - Tone / demeanor of interviewer - Communication prior to interview
I mean, sure, if you fail fizzbuzz interviews 10 times in a row, there seems to be some pattern going. But you could might as well fail it the first time, and get blackballed as incompetent.
This is different than for bulk capacitors, but even those should still be on the same PCB assembly because connectors have higher resistance and this will limit their ability to handle transient surges.
Not all LDOs are stable without external output capacitance in a particular range / ESR.
Understanding that the capacitor and the trace form an RC circuit and that distance matters is what separates a professional from a beginner.
I can't think of one junior EE I've interacted with who couldn't have told you what decoupling caps were for. Sizing them correctly (instead of just sprinkling the 0.1uF magic fairy dust on your board) might be another matter but I've yet to see someone fail to grasp the purpose.
Explain please?
Yes, there are some considerations when you're dealing with RF, but a modern 0402 0.1uF cap works pretty much everywhere because it has such a great frequency response due to its small size.
Now, explaining to people that their 10uF 6VDC 0402 across the power rails probably doesn't have as much capacitance as a 2.2uF 15VDC 0402 is a little subtle.
It is also an issue that decoupling caps can hold too much energy and keep a power domain operating when you wanted it shut down. That makes for some interesting debugging. Power domains now require discharge circuits because IC's use so little power.
Interviewer: "Can you draw me the schematic symbol for an LED?"
Me: Draws LED schematic symbol.
Interviewer: "What would you say the forward voltage is on that LED?"
Me: "That depends - maybe between 1 and 4 volts depending on the color?"
Interviewer: "Good, let's call it two volts. What would you say would be a reasonable current if we're just using it as a power indicator?"
Me: "I usually set it to around one milliamp on my boards."
Interviewer: "That sounds good. Can you show me how you would connect that to a 5 V supply?"
Me: Calculates ballast resistor size for 1 mA current from a 5 V supply with a 2 V LED drop, then draws a circuit with an LED, resistor, and 5 V source.
---
And on it went. We ramped up through complexity: next we did simple BJT and FET switches, then basic op-amp circuits including single-pole filters. I stumbled on a differential BJT amplifier question, but the interviewer helped me through it. And so on. I didn't nail everything, but I got most things right. I ended up getting the job.
When I asked the interviewer later about his experiences using test for hiring, he told me a sizeable chunk of new graduates flunked out on the first question, which I found pretty shocking. A lot of students with excellent resumes didn't even know how to hook up an LED!
As to the cause - it's just a guess, but I think many "good students" these days are very good at regurgitating information and memorizing procedures to complete formulaic exam problems, but aren't very good at actually developing the physical understanding of what's really going on. When I was in my senior year, I designed a buck converter as a small part of my capstone project. One of my team members remarked that he didn't realize a buck converter was a power supply, and that he had seen it in his power electronics class but had no idea what it was used for. He could do the duty cycle calculations for one all day long, but he didn't even realize it was a DC/DC power supply!
Universities these days do not seem to successfully evaluate deep understanding. Rather, they seem to optimize for the superficial appearance of understanding. Even "lab courses" when I was a student were formulaic: plug this wire in here, put your probe here, read this value here, do this calculation here for your report. There were very few courses that were actually designed to encourage real experimentation and practical learning. A good EE needs to develop a mental model of the underlying physics and be able to relate it to practice, and that is a tricky thing to teach in the classroom.
Anyway, all that said - I really like the idea of the "bad schematics" approach for an interview question. If I ever find myself in a hiring role, I am 100% using it.
At our university we had basically only TWO courses that required you to "understand" to pass them and not just mindlessly puke out formulas and insert values. These were theoretical electrodynamics and integrated analog circuits. These were exactly the exams that kicked people out of university, since you had only 3 attempts to pass them.
So, no, uni's will never try to force understanding, since so few are actually capable of that. Unis teach you to know the basic set of symbols, be a mindless symbol manipulating monkey and hope that industry would pick you up and enlighten you afterwards.
Indeed: as a teacher, I have had the experience that there's pressure to pass underachieving students in the elementary courses (we don't want to scare everyone off by flunking them out of their first courses!) and then there's pressure to pass underachieving students in the advanced courses (it's not fair to pass them to this point, and then suddenly hold them to higher expectations!—or even, directly, "if we don't pass them then they won't be able to graduate").
In the software industry we have a similar problem; alot of people can follow instructions on how to glue together lots of libraries and frameworks, but have no idea how to go beyond that --- or understanding of how computers work in general --- much less debug it when something goes wrong. There's a classic article about this:
Most small LEDs will tolerate per datasheet 20mA; 4mA is "well-lit". A little less than 1mA is going to be pretty anemic looking on lots of LEDs.
So I'd be more inclined to put down 470 to 1k5.
For use as indicators for firmware debugging under typical office lighting, I find 1 mA to be the "sweet spot" - bright enough that I can tell it's lit with a quick glance, but not so bright that if I'm staring at the board it becomes uncomfortable to look at, or distracting out of the corner of my vision.
However, if it's for indication for an operator of a device, and it's inside a case going through some lossy elements (eg: aforementioned light pipe or diffuser), I'll definitely use more current to make it a bit brighter.
(Maybe I'm biased because I often have my office window open and it's bright... and having couple orders of magnitude of current above what a microcontroller pullup/pulldown will source/sink has been nice sometimes-- that or I'm just stubbornly trying to justify following the very-old 4mA rule of thumb).
But I'm modestly good at math and the EE classes were essentially an elaborate sequence of math riddles (complex functions? Fourier? I'm great at that), superficially excused as representing some "circuit".
1. Extremely theoretical, minimal practical elements (labs, demos, etc.). These would have classes in Electromagnetism, Signal and systems, ICs, RF, Optics, etc.
2. Very practical, but only skin deep on theory. Power systems, electrical circuits, electrical machines, etc.
The very few classes where we had a nice 50/50 ratio of theory / work were perfect, but I always felt like missing out on the other classes. Unfortunately the coursework was quite heavy, so you didn't get much time to do self-study either. Labs always crammed, always some projects / HW / home exams / labs that needed be handed in.
However, you’re often working in groups, so it’s not uncommon for one person to really “get it” while the other members of the group nod along but don’t fully understand the choices being made. In addition, TAs in the lab probably don’t have industry experience, so there are basic practical circuit design practices that aren’t taught or enforced.
Labs are a good way to get initial experience, but I think there’s a lot that you inevitably have to learn on the job. There’s a reason you can’t earn a license as a Professional Engineer until you have 4 years of work experience.
Digital systems classes can cover it too, when going over power distribution, but that’s usually a graduate level class.
The digital VLSI or signal processing tracks of EE might not require this stuff anymore.
For one thing, many of my professors (in fact, probably all of them) were very theory focused, and had very little experience implementing electronics. I think they figured that practical topics like this were too specific to lecture about, and we'd pick it up on the job anyway. I'd have to assume that mindset is not wholly exclusive to my undergraduate degree.
For another thing, I find that commonly, large employers are frequently not doing much to train their new grad EEs, or even let them near much design work. As a result, they miss out on practical experience that would teach them about concepts like decoupling.
Same! I didn't realize you needed them until I entered industry. I think that's a little disappointing - it's a very simple explanation, just one that most professors don't choose to spend time on.
I'm trying to put together a good demonstration of why you need decoupling capacitors in a lab setting. Best one I can think of is paralleling a bunch of inverters with no decoupling caps, and then measuring the current draw on the rail using a shunt resistor.
> 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
I think you need to communicate to the candidate that this is a board with a lot wrong. 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?
And if the employee sees a sample of the company's work and it's awful, they're liable to judge they're unlikely to learn much from working there.
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.
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.
"Need some ideas for a crappy schematic? Here are some easy ones I can think up off the cuff:
o Current limiting resistors missing (BJTs, diodes, etc.)
o Shorting a potentiometer node to a rail
o Voltage regulators missing capacitors at input/output
o Missing pull-up/pull-down resistors on digital buses
o Missing decoupling capacitors
o Powering ADC reference voltages from a switching supply
o Transistors placed in wrong/backwards configuration
o No signal conditioning/buffer for analog signals into ADC
o AC coupling high-pass filter sets corner frequency too high into ADC
o Reset sequence of digital component is wrong
o Antenna is missing a matching network/filter
o Clock/data lines swapped backwards in digital bus
o No pull-up/pull-down resistors on IC configuration pins
o No frequency compensation on unstable opamp circuits
o Improper gain settings on opamp circuits"
Fascinating!
Would love to see a book about these errors and others -- with the title:
"Learn EE (better!) -- by studying things that don't work"
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...
I guess you could argue that The Art of Electronics kind of fills this niche. Horowitz and Hill call out a bunch of non-functional or error prone circuits with large, friendly "DON'T DO THIS" labels. The second edition had a great section at the end of each chapter entitled "Bad Circuits" that served just this purpose. (The only flaw with the 3rd edition is that they took out "Bad Circuits", in my opinion.)
Is the board built to the schematic?
That's my first question when a board loses its magic smoke.
While its interesting to see what vector their over-thinking takes, it doesn't help move the interview along.
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.
All good ways to see how much of the 'craft' the candidate knows versus the 'facts'.
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?
1) "Why it wouldn't work" is vague and nonspecific. "Applying power and hearing a pop/smelling smoke" is a big hint. You have to phrase the question in a way that gives up some information for it to be a decent use of time.
2) Complexity fucking kills these interviews. You shouldn't be handing off a multi-page schematic with complex interconnects. Five or six major components, max. Label your subsections for clarity: things like "microcontroller", "EEPROM", "LED driver", "half bridge driver", "ADC", etc.
Sounds like you did the right thing, and got penalized for it. Fuck 'em. They weren't the right fit for you anyway.
It was a really cool company and I'd have loved to work there. It's the kind of place where I want to be a good fit.
I don't expect you to find all the issues. (But if you do, then congratulations! I'm gonna try to hire you.) I do expect you to talk to me about your thought process when confronted with a novel issue.
That's what good electrical engineers do. They don't know all the answers - they reason their way through unexpected challenges.
I gotta say though, if they themselves designed this board that promptly blew up, perhaps they should recalibrate their expectations for EEs.
They failed you for doing what any competent engineer would do.
Same applies to code in an interview; it should have syntax, efficiency, correctness errors and more.
Suppose a candidate identifies a crucial flaw in your production code but for some reason the hiring negotiations breaks down and can't hire them. What happens next? Do you compensate the candidate for the time and effort to improve your code base?
The interview process shouldn't be a free code review.
I like your idea of testing if they could work with your code base. I just think there are better ways to test for this without getting into potential predatory actions. The only way I see how this could work is that you say: "You'll either get hired or we pay you a bug bounty of X amount".
I might be too cynical but good luck on convincing the higher ups there's a small chance they need to pay candidates if they did extremely well in the interview process because it's "only fair and they did the work".
But yes, the central point of the exercise is "show me where the smoke came out!" (It's a very, very dumb mistake. Nearly everyone I've spoken to has reasoned their way to it.)
The rest of it is to let people demonstrate what other errors they can pick out, or serve as fallbacks for the folks who don't find the magic smoke/component death failure.
Power Amplifiers
Q: Where do GaAs/GaN FETs DC gate currents originate, and why are they positive and negative?
Q: How would you temperature compensate the transistor DC bias.
Q: What is AM-AM and AM-PM distortion and how would you measure it?
Q: Give an example of a “memory effect”.
Passive RF/Microwave Circuits
Q: How would you measure unloaded Q of a resonator?
Q: What is self-resonant frequency of a component (i.e. chip L or C) and when is it useful.
Q: Why does a stripline coupler typically perform better than microstrip?
Q: What’s the characteristic impedance and electrical length for the lines in a 2-way Wilkinson splitter.
Q: Where does the current flow on a microstrip line and its return path?
Test and Measurement
Q: What’s the difference between RBW and VBW on a spectrum analyzer?
Q: When is a sliding load used in VNA calibration and how does it work?
Q: What does noise marker mode do on a spectrum analyzer?
Q: How would you measure a SMT part at several GHz with proper reference planes?
Q: What’s a quick way to tell if your spectrum analyzer is contributing to IMD3.
Digital Comms
Q: Why are RRC filters used so frequently?
Q: Describe the flow of PSK receiver?
Q: What is an Error Vector Magnitude (EVM) measurement?
Q: What effect does clock jitter have on an ADC or DAC.
Q: Would a class C amplifier work better with OFDM or FSK?
Antennas
Q: What typically limits the bandwidth on a single frequency patch antenna?
Q: What’s common mode radiation on a coax (to antenna) transition and what are a couple of ways to minimize it.
Q: What happens to an antenna’s input impedance and directivity when you move it very close to a “ground plane”.
Q: What’s an IFA or PIFA antenna and how does it relate to a monopole; why are they so common in compact devices.
Q: Given a VNA and two linearly polarized horn antennas with known gain, how would you measure the gain of a circularly polarized antenna?
RF Front Ends
Q: What are the typical blocks in a superhet receiver (or down conversion chain)?
Q: What typically determines diode mixer linearity?
Q: What’s IMD?
Q: What’s more important in LNA; noise or impedance match?
Q: What’s cross-modulation?
Synths and Oscillators
Q: What are the advantages and dis-advantages of a Frac-N over an Integer-N synth?
Q: What specs would you look for in a linear regulator to isolate a synth analog section from a switching supply?
Q: Given you don’t care about settling time, how would you set loop filter bandwidth to achieve best noise performance?
Q: Given you don’t care about settling time, how would you set loop filter bandwidth to achieve best noise performance?
Q: What do synth ICs have charge pump trim settings (i.e. upper and lower different gains)?
Connectors and Waveguides
Q: What is skin effect?
Q: What is the torque specification for a 3.5mm connector?
Q: Why is nickel used in plating processes? What effect does it have on RF?
Q: What’s the highest frequency that an SMA connector can be used for TEM propagation? What happens above that?
Q: If you needed to slice a rectangular waveguide in half, would you slice down the broad wall or the narrow wall? Why?
Simulation
Q: Why would use you use 2D thick metal (or 3D EM) on edge coupled lines? Is there a rule of thumb?
Q: Would you use harmonic balance or transient simulation (or both) to model a simple diode detector?
Q: What are some quick methods to determine if your EM simulation is plausible?
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.
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?