> I think it has to do with people the weird phenomenon of people that are working as "programmers" that don't know how to program.

This absolutely isn't unique to software. There's plenty of incompetent workers in other fields, like construction workers, bureaucrats, pretty much anything.

Yeah, I've seen it with finance where someone doesn't know how to use Excel or basic finance concepts, but in general they could be taught within a reasonable timeframe. Programming takes many years to become productive. An inexperienced programmer in a code-base is a net negative on the organization. Teaching someone programming on the job is pretty much a non-starter

Teaching someone finance on a tight finance team is not easier -- finance (the real kind, not the automatable kind) is just as technical a field as programming.

What I think is different is that it's not so much deep, like programming can be, as wide -- meaning a skilled interviewer can correlate experience and technicity in a way that gives reasonable assurance.

This is not the case with more junior positions where you need to make sure technicity has actually been acquired by the candidate, lest it be just as you say a "net negative" for the team: for finance positions with less than 10 years of experience, we have a case interview. That case interview is not meant to be selective but just a check of capability. Only candidates that have passed phone screening and hiring manager interview get the case interview, which is also delivered by the hiring manager so gives a chance to see the candidate in another kind of situation.

I disagree that finance requires the number of hours required to become a competent programmer. I worked in finance, maybe it wasn't the "real kind" or "tight finance", but it was sophisticated. I went into it not knowing much about structured finance and how securitizations work. After reading a few prospectuses, playing around with some models, discounted cash flows, mentoring, etc, I kind of figured it out, enough to be useful at least. I came in with some knowledge (time value of money, interest rates, etc), but those didn't take hundreds of hours to learn either. Screwing up a spreadsheet does not have as bad consequences as pushing bad code to a code-base. Just look at finance spreadsheets the pros use. It's appalling how little care they take (e.g. use of named variables, no version control, insane work-arounds to deal with the limitations of Excel, tolerance for complexity, ridiculous inscrutable formulas, etc).

Junior bankers fresh out of school do the heavy lifting in huge important deals. They get supervision of course and there's a steep learning curve, but the fact is they are in the trenches pretty early on. Senior bankers deal more in relationships and sales. Could you imagine Google hiring junior engineers right out of college to tweak their ad-engine?

Programming on the other hand has taken a lot more time for myself, and pretty much most competent programmers I know. To think about it another way, I don't know anyone in finance that spends hours at home working on side projects learning finance for years. However every competent programmer I know has spent a considerable amount of time outside of the classroom and work honing the craft to reach a basic level of proficiency.

There's a place for junior programmers, but its one of those professions that if you don't truly enjoy it, the payoff in terms of the time you have to spend on it just isn't worth it. And the competition is a lot stiffer. The percentage of finance guys that spend their weekends contributing to open source finance projects, creating educational resources, or answering questions on a stack overflow type platform is much lower when compared to programmers that do this stuff for fun.

Agreed. Point is, even then, you'll find unrepentant pikers and jacklegs everywhere. Every organization that can't fire them or route around them will be overcome and mired in dysfunction. For whatever reason, other professions just accept this as reality and move on.

Real life example:

- how much would you rate your knowledge of C++ on a scale to 10?

- 9/10

- Can you explain "pointers"?

- blank stare

The 1 to 10 scales are tricky. My rating would be 5 is use professionally or equivalent, 7 build non-trivial app and maintain legacy code, must know best practices and style guidelines, basically able to work in a large code base with other users. 9 would be contribute to the language or at least be involved in the community. But I don't know if everyone has the same interpretation of the scale, so you could be relatively competent but only rate yourself a 5 or 6.

Serious question, if the person actually had a 9 out of 10 knowledge of C++, how would he answer? Or is this just a teaser question?

I don't know C++ but I would answer pointers are addresses in physical (?) memory. They let you pass around variables by reference where the receiving function has full access and permission to edit its content. Pointers have to be dereferenced with the appropriate type before being able to read it

9 out of 10 for me means you know metaprogramming etc.

Any answer is basically fine, as long as it's clear you know what pointers are.

It's basically also a starter question to go further into memory allocation and freeing, smart pointers, etc.

The thing is, it's fine if you answer 3/10 "because it's been a while since I saw it". It's just to probe self knowledge.

I would call that a successful interview (succeeds in detecting a candidate who would likely fail at their duties). Interviews are important. But would any random programming or whiteboarding task add anything of value to this?