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