81–90 of 111 posts
Earlier quoted context omitted.
I didn't expect when I wrote this post that the decoupling caps comment would be the one that starts the HN flame thread. XD
It's pretty bizarre, you have to admit, for junior EEs not to know this — isn't it?
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 issu…
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…
These are for the most part considerably harder than noticing a backwards protection diode or a missing base resistor.
> 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 com…
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.
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.
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.
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.
Earlier quoted context omitted.
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?"
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.
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 issu…
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
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.
> ...should be absolutely riddled with errors. Same applies to code in an interview; it should have syntax, efficiency, correctness errors and more.
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".
Earlier quoted context omitted.
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 com…
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.