That's like an EE saying, I don't really understand capacitors, but I am building a circuit like this one and it has a capacitor, so I'll just borrow the values and tweak them in simulation.
>> That's like an EE saying, I don't really understand capacitors, but I am building a circuit like this one and it has a capacitor, so I'll just borrow the values and tweak them in simulation.
Dude, in EE interviews, we just ask them some basic about capacitor and how to use it. We don't ask them to derive the mathematical equations of electrolytic capacitors.
In fact, in most EE interviews, you just use them to solve ONE problem and be done. Nobody questions you know EE stuff once you've solved ONE problem.
In programming interviews, you have to solve MANY problems and interviewers just want to keep finding ways of docking points.
I've never applied for a strictly dev position, but my friends have told me they've been asked about how different forms of self-balancing trees work. I haven't implemented my own self-balancing tree since Data Structures, and I'm pretty sure they haven't either. If someone asked me to implement one in an interview I'd honestly think they were crazy. Who would implement a data structure or algorithm they haven't used in nearly a decade without looking an implementation up first?
Bearing in mind that I use my programming ability for analysis rather than developing applications, I'd say that programming is like 90% fundamentals and 10% looking stuff up. If a company really wants to test someone's programming ability in an interview, I feel like the best thing to do would be to make up a programming language, give them a reference sheet, and then ask them to program a couple different versions of fizz-bizz.
Obviously it's not a perfect idea, but I think you'd at least be testing the skills people actually use when programming, rather than whether they can remember every bit of syntax from every language they have listed on their resume. I mean, if I lied and said I knew javascript, I'd almost certainly fail a programming test that used a made-up language based on it.
> If a company really wants to test someone's programming ability in an interview, I feel like the best thing to do would be to make up a programming language, give them a reference sheet, and then ask them to program a couple different versions of fizz-bizz.
Are you joking? Doing fizz-buzz is way too low of a bar. That doesn't even show you can use standard classes and things, like maps and lists.
> but I think you'd at least be testing the skills people actually use when programming
That would tests very few of them, unfortunately.
> rather than whether they can remember every bit of syntax from every language they have listed on their resume
No one I see tests for syntax, but for the more important/broader concepts.
> if I lied and said I knew javascript, I'd almost certainly fail a programming test that used a made-up language based on it.
Probably not. Most mainstream languages have pretty similar syntax. And if you expected people to know others without warning, people would raise hell. Anyone who knows C can probably guess the gist of what a small snippet of non-tricky Javascript does.
Well, other than R, I've never programmed in a functional language before. I programmed Javascript in my High School intro to CS class back in 2004, but I can't imagine I could pass a test based on that alone.
Fizz Bizz is stupidly easy, but I honestly don't think that much of programming is hard in the first place. The hardest thing in my mind is designing a coherent program. You could add any requirements you'd like to your made-up language (no automatic garbage collect or reference counter, etc), but I think you'd be able to tell pretty easily if they were the real deal.
Sadly, that describes more than a few EEs and MEs that I've worked with in the past. Where the act of turning a key in a commercial software package starts to displace practical design considerations that they learned in the classroom.
You don't need to be able to build a capacitor from scratch in order to understand how they work. Furthermore, electrical engineers don't have to build capacitors from scratch during job interviews to prove their competence.
No, but there's a level of the EE tech stack where you do need to understand (and have the ability to build) the level below. I don't need to know: how to construct a transistor, build a logic gate, build a look-ahead adder, construct an ALU, CPU, computer hardware, write assembly, or write a compiler to do my job (although the last couple start getting close enough to my bailiwick that I think they're useful).
I'd expect that something basic in an EE job could be "draw the core part of an oscillator circuit, then we'll talk about the principles of its operation". The discussion would end up going into some properties of capacitors, why they chose that exact form of oscillator, expected use-cases, etc. The behavior of the object lower in the "stack" becomes important, and so does a real understanding of how they work. Of course, actually requiring them to build one would be ridiculous.
>>I'd expect that something basic in an EE job could be "draw the core part of an oscillator circuit, then we'll talk about the principles of its operation".
Sure, but that's the equivalent of drawing a diagram that explains how quick sort works, as opposed to implementing it using real code. Most companies demand the latter during interviews.
The places I've interviewed (a few big names and a few small ones) either wanted something pseudo-code-like (on the whiteboard), wanted an explanation of the algorithm (potentially with some clarifying diagrams or code), or actually provided me a computer with an IDE.
Dude, in EE interviews, we just ask them some basic about capacitor and how to use it. We don't ask them to derive the mathematical equations of electrolytic capacitors.
In fact, in most EE interviews, you just use them to solve ONE problem and be done. Nobody questions you know EE stuff once you've solved ONE problem.
In programming interviews, you have to solve MANY problems and interviewers just want to keep finding ways of docking points.