
Reviewing Bad Schematics as EE Interview Tactic - bcaa7f3a8bbc
https://cushychicken.github.io/bad-schematic-interviews/
======
EdwardDiego
We've used what we call the "Kobayashi Maru" coding exercise with developers.

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.

~~~
xref
I thought at least in TDD your tests could “never be wrong” since you have to
write code that makes the tests pass, not vice versa

~~~
Normal_gaussian
I practice TDD frequently (whenever suitable).

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.

------
fest
Things that come to mind for bad schematic review:

* 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...

~~~
dws
The same approach works. Under-specify a problem, then see what questions
candidate asks, and at what level they jump in. When Windows used to ship with
Minesweeper, I'd ask candidates how they'd approach implementing Minesweeper
for a touchscreen on an embedded device. Good candidates would get clarity on
hardware and constraints first.

------
userbinator
_My example of this: I have yet to meet a junior EE candidate who understands
the need for decoupling capacitors in digital circuits_

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.

~~~
rightbyte
It seems strange that the author has not met a single one that understands
that concept since it is quite basic. I am guessing he just is bad at
interviewing and asks trick questions till he meet someone who know the
interviewing game inside out.

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.

~~~
userbinator
_how should you know that the voltage regulator doesn 't have internal caps
without seeing the specs?_

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.

~~~
rightbyte
Traco Power has some. I don't know which one we used on the top of my head but
kinda like this with fewer pins: [https://www.tracopower.com/products/browse-
by-category/find/...](https://www.tracopower.com/products/browse-by-
category/find/tri-3/3/)

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.

~~~
ohazi
That's a module, not a chip. If it's one of those 1mm x 2mm sot packages, it
almost certainly doesn't have embedded switching capacitors.

------
mlyle
> Then, you give them a fake schematic of the circuit board, and ask them to
> troubleshoot the problem.

> 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?

~~~
romanows
Just give your opinion as you would to a coworker on your best day. That's
what any reasonable interviewer is looking for unless otherwise stated.
Similarly, you can tell a lot by how your comments are received.

~~~
mlyle
"Whoever drew this wasn't just high, they smoked _all_ the crack
_everywhere_."

------
strstr
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.

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.

~~~
irjustin
I agree, the analog isn't a good fit. With EE there's a floor of knowledge
that basic "bad schematics" can build off of.

------
peter_d_sherman
Excerpt:

"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...

~~~
cushychicken
I've never heard of a whole book, but I can see how it'd be a great book if
someone really took the time to make it.

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.)

~~~
yummypaint
That's too bad they removed the bad circuits. I found those extremely useful
when first starting out. Sometimes my first guess at how to do something was
explicitly noted as a bad circuit, which i suspect was the intention. After
reading about a new component, students often wonder "can i just do x
instead?" and the bad circuits section did a great job of anticipating these
kinds of questions.

------
willis936
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.

------
analog31
>>> Then, you give them a fake schematic of the circuit board, and ask them to
troubleshoot the problem.

Is the board built to the schematic?

That's my first question when a board loses its magic smoke.

~~~
imba404
That in itself is a Design for Manufacturing question, involving stack-up,
Gerber correctness, and drill tolerances.

------
ChuckMcM
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."

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'.

~~~
cushychicken
Thanks Chuck. :)

------
ufmace
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.

------
PascLeRasc
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.

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?

~~~
cushychicken
Sounds like the interviewer tried to use this tactic, and did a lousy job of
applying it.

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.

~~~
PascLeRasc
Ok, to be fair, they did say "when we turned it on, part of it blew up" when I
asked for more details, and it was just a 2-page schematic with 6-7
subsections. I think it was pretty fair, I'm just frustrated that it felt like
I couldn't solve it by thinking slowly and methodically.

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.

~~~
makomk
I do wonder if this is just a scenario where there's no way to win. The person
writing this blog post has exactly the same interview prompt - something went
pop when the board was powered up - but they expect candidates to spot subtle
things like missing decoupling capacitors that almost certainly aren't the
cause of the problem.

~~~
cushychicken
Just about every person I've used this prompt on has found the prompted error,
and then gone on to find a few more. However, I don't really care about the
number of errors you find nearly so much as I do seeing and hearing you reason
your way through a new problem.

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.

------
emmelaich
> _...should be absolutely riddled with errors._

Same applies to code in an interview; it should have syntax, efficiency,
correctness errors and more.

~~~
analog31
You should use your own production code. This will kill two birds with one
stone: Does the candidate know how to read code? Is your production code
readable?

~~~
nocturnial
I very strongly disagree with this approach.

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".

------
Treblemaker
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!

~~~
cushychicken
I considered including the actual one page PDF I use for interviews in the
post, but I didn't want to chance someone finding it online before they came
into an interview with me.

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.

------
madengr
Here are some of my RF specific interview questions. Spend no more than 1
minute on each.

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?

~~~
imba404
Dude, I work in RF and it would take me more than a minute to remember some of
the answers to these questions.

------
princess445
Analog will be gone in the next few years. EE is the new technology for the
future

------
mmmBacon
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...

