Live data from Hacker News

Reviewing Bad Schematics as EE Interview Tactic

cushychicken.github.io

91–100 of 111 posts

Re: Reviewing Bad Schematics as EE Interview Tactic

#91
post #19

Earlier quoted context omitted.

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 Mis…

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.

> It really doesn't matter if the voltage regulator has them or not.

Not all LDOs are stable without external output capacitance in a particular range / ESR.

Re: Reviewing Bad Schematics as EE Interview Tactic

#92
post #83
post #78

Earlier quoted context omitted.

These are for the most part considerably harder than noticing a backwards protection diode or a missing base resistor.

Some are hard, other like asking about a Class C amplifier with OFDM are just lol.

That was one of the few I could do! I figured FSK would survive Class C distortion.

Re: Reviewing Bad Schematics as EE Interview Tactic

#93
post #75

Earlier quoted context omitted.

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.

Sorry, I meant to write "voltage regulator" about which parent asked about, not sure how I ended up with "linear regulator".

Yeah, a switching regulator is still a regulator.

Re: Reviewing Bad Schematics as EE Interview Tactic

#95

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…

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

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

Re: Reviewing Bad Schematics as EE Interview Tactic

#96
post #53

Earlier quoted context omitted.

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

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.

[deleted]

Re: Reviewing Bad Schematics as EE Interview Tactic

#97
post #77

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?

The more I think about it, no - it's not.

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.

Re: Reviewing Bad Schematics as EE Interview Tactic

#98
post #90

Earlier quoted context omitted.

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.

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.

Re: Reviewing Bad Schematics as EE Interview Tactic

#99
post #45
post #36

Earlier quoted context omitted.

I just refuse to believe this. It can’t be.

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.

Could you elaborate on the problem? No offense, I find it very hard to believe that no one knows how to sum the items in an array.

Are you expecting some map-reduce-like parallel sum, or something else?

Re: Reviewing Bad Schematics as EE Interview Tactic

#100
post #76

Earlier quoted context omitted.

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.

It's in Horowitz & Hill. What was your introductory textbook?

Thomas/Rosa/Toussaint. Horowitz's book is way better though.
Post reply on HN