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.
Maybe if prefaced with something like "anything in this project, including tests may be buggy, your job is to make everything work as intended", it would be less of a test of "guts to speak up on interview" and more just technical challenge. Of course that guts may be a value in itself..
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.
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...
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.
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.
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.
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.
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.
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.
Integrated Switched-Capacitor Voltage Regulators will definitely be a thing in a few years they have already been produced in research labs and quite likely reached even limited production for low power <10W applications.
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.
>It seems strange that the author has not met a single one that understands that concept since it is quite basic.
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.
- 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.
Lately, my company has been looking for folks who can, essentially, compute the sum of items in an array in JavaScript. Seniors continue to fail 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.
I can't really elaborate, but it's only barely more complicated than I'm representing. I'm with you. I can't believe it. Boggles my mind every time. And no we're not expecting a complicated solution.
I think it makes sense depending on the nature of the role in question.
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).
Decoupling capacitors need to be within a few mm of the integrated circuit consuming the power. It really doesn't matter if the voltage regulator has them or not.
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.
I've yet to see a voltage regulator IC with built-in caps. DC-DC modules sure, but author argues that this kind of info (module / ic) should be present in schematics. BTW, some linear regulators can't handle ceramic and low-ESR capacitors at output, and may be better with none if that's the choise.
I hate to maybe be proving his point by showing that I'm not into the EE field and thinking of a board mounted DCDC-converter as a voltage regulator (which it is but not what you usually call it in english?)
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.
I believe that without qualification "linear regulator" could be just anything that regulate voltage. Usually you can easily tell from schematics around it if it's some switching IC, an LDO or a module. And if you have layout or 3d render of the board it'd be almost certain.
Otherwise the person may just ask: "where are caps, or is this thing a module or what?"
In my experience, "linear regulator" refers specifically to voltage regulators which drop from a high voltage to a lower voltage by burning all of the power in between (e.g. the venerable 7805).
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.
No, switchers aren't “linear.” And on a schematic the regulator isn't going to be a box labeled “regulator”! It will have a part number, probably a familiar one.
ICs with multiple power domains have a boot sequence that must be followed or the IC isn't in the proper state. Many interview questions fall into the "assumed assumptions" category. Simply saying, "lets reset to a known good state and modify one variable at time disqualifies many candidates". Because we don't teach science like we should. We should be teaching the scientific method before we teach the three Rs.
It's not that stupid. If a candidate asks the questions you are asking then you know they are on the right track. It isn't about getting the right answers but about having the knowledge to ask the right questions.
My EE education didn’t cover decoupling caps, and from talking to others from different schools they didn’t learn it either. It's something that only comes out in DIY projects, and unfortunately most schools don't care about projects or fostering independent/continuous learning.
Are you an analog EE? If so that’s surprising. Did you have any microelectronics classes where you essentially build up your own opamp, one stage at a time? Bypassing is usually covered in this class, or in its lab, especially when discussing PSRR of the system.
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.
I'm an EE. My first job out of university had a pretty good whiteboard interview (I know - we're not supposed to say good things about whiteboard interviews on HN). I thought the process was pretty straightforward. The first exchange went something like this:
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.
"Universities these days do not seem to successfully evaluate deep understanding" If you (as Uni) try and do that, you'd immediately find your quota of those who have finished a degree to plummet.
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.
> If you (as Uni) try and do that, you'd immediately find your quota of those who have finished a degree to plummet.
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").
The closest standard value for that resistor would be a 3k3, if I'm not mistaken...
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:
If it's just a bare LED on a board (ie: not in a case going through a light pipe or diffuser), 1 mA is actually pretty bright with modern LEDs. They're a lot more efficient than they used to be.
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.
I can't be sure it's "on" unless it leaves little 0603-sized purple spots in my vision. ;)
(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).
I did 0.5 EE degree in the best Uni in my country with very good grades and my level of insight wrt how ICs work borderlines a Golden Retriever.
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".
When I got my BSEE, there were unfortunately only two types of professors:
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.
Do EEs have to do any projects as part of their curriculum. I'm just an SE by training, but have done some electronics purely as a hobby. A power, resistor, LED circut is bassically my hello world for any electronics project I do. I cant imagine getting through any of my hobby projects without calculating an LED resistor at least 1. Although, at this point I always use the same LEDs, so I could get away with just looking at what I used last time.
Yeah, every EE program that I’m aware of has lab courses where you build things on a breadboard, learn to use the oscilloscope and logic analyzer, and probably accidentally let the magic smoke escape from a couple ICs.
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.
I don’t know. If junior = lack of experience implementing circuits in practice then I don’t think they should. After all, in theory you don’t need to bypass. In practice, you might. :)
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.
Well, I've definitely taken a pre-EE class where we breadboarded a bunch of logic circuits without decoupling caps. But #electronics on Freenode, Horowitz & Hill, and EEVblog are all pretty emphatic about them, so I figured everybody would know by the time they considered themselves a junior EE.
>I've definitely taken a pre-EE class where we breadboarded a bunch of logic circuits without decoupling caps
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.
Maybe you should involve an ADC or DAC in your demo. Shitty audio is a more convincing problem than a VCC current measurement, and even tens of mV of ground bounce should be quite audible.
It’s not obvious that you need them. In modern hw especially, often you don’t. Most people add them because it is (usually) not harmful and it can be helpful and they don’t care if it’s wasteful.
https://youtu.be/P8MpZGjwgR0
Seems like it says more about the writer's hiring pool.
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.
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.
There's also a difference between "can tell you what decoupling caps are for" and "when given a circuit will call them out as missing", especially in an interview situation. (Parallels probably apply to software interviews: under stress it's easier for many to answer "define X" than to identify how/if to apply X when not prompted for it)
> 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?
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.
Of course you should be polite in an interview - but for a desirable employee it's not only the company judging the employee, it's the employee judging the company.
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’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.
"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'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.)
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.
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.
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'.
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.
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?
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.
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.
Did they tell you exactly where it blew up? Then it might be fair, 2 pages is not that big. Though you'd still be at quite a disadvantage compared to someone who spent a lot of time designing the thing.
I gotta say though, if they themselves designed this board that promptly blew up, perhaps they should recalibrate their expectations for EEs.
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.
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.
Hard to say for sure, since I don't know you or the company and can't see the test myself. It is a legitimate skill, especially in higher-level engineering positions, to take a huge pile of code or schematics or whatever and get a high-level understanding of what it seems to be doing without getting too bogged down in over-analyzing any particular sub-section too soon. Some things do tend to jump out easily when you have a sufficient level of experience with the overall domain.
I would suggest it’s not about “being smart enough”, but about pattern-matching.
Over time, the brain gets trained to recognise things and react without conscious effort. You haven’t put in enough repetitions to get to that point yet, for that interview.
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?
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".
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!
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.
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?
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...
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.