> They can't code because you are looking figuratively over their shoulder---the clock is ticking next to a hundred grand in a suitcase.
There is a difference between me asking you how to optimize a graph algorithm (good luck--I probably couldn't do that on the fly with references in front of me) vs giving me a basic FizzBuzz.
If I let you pick your language for your FizzBuzz, you need to demonstrate at least some of the following things:
I/O of any flavor (I'll even accept Logging if you don't do standard I/O or console I/O)
To be totally honest, I always find these stats about some x% > 50% failure to program at all totally unbelievable. What do these people do all day, if not design and build software? Yet they're apparently completely unable to write code? How is that possible? I understand that there is always a certain amount of slack and underperformance but any workforce would be completely paralyzed by 70% completely incompetent workers. And yet companies everywhere still produce software.
> What do these people do all day, if not design and build software?
Indeed this is a fascinating question, and I explored it a few times.
Some folks who have multiple years of "software engineering" on their resume worked in a place where they did some form of "paint by numbers" programming, producing some work by modifying templates with limited (at best) understanding beyond the specific blanks they were filling.
An example is folks who work with large frameworks that are designed to be extended with little to no coding, such as WordPress and Drupal.
Then they want to advance to software engineering, so they recast their experience - of essentially configuring and deploying software, i.e. sysadmin - as "programming", and get those 5 years represented as "a full time programming position".
There's variants of that, basically "developers" doing very limited ant-work with large frameworks they don't understand and couldn't rewrite from scratch if their lives depended on it.
There's also a bunch of languages and frameworks invented for the explicit purpose that someone with little to no CS knowledge of programming talent could produce useful work.
Most of us here live in a bubble of startups where we often create products from scratch using lean (or no) frameworks. In reality, a scary amount of the "IT work" out there appears to be what I described above. Possibly a substantial majority.
Go through it cover to cover and do all the exercises. All of them. Don't skip a single page or exercise, not even if you think "I already know this", and certainly not because it's too tough.
Once you're done, you should be able to start applying for jobs in whatever language that book taught you. If you're still not passing interviews, take on a serious - but manageable - programming project, such as some simple application for yourself or someone you know. If you're a web developer, a simple dynamic database-driven website is an excellent choice. If you want to do front-end, a simple Javascript game will teach you a lot.
You don't always have to apply for new jobs so early. Lots of tech shops have some teams where actual programming happens, even if most of the rest of the company is "paint by numbers" pseudo-programming. Often you can start to take on more responsibilities that involve actual coding if you show the necessary abilities. You won't have to change companies, or even change teams.
Good/excellent programmers rarely need to interview except as a formality. Consequently, you are, by definition, interviewing weaker programmers.
2) Tool use masquerades as programming
Visual Basic 4/5/6 was one of the original sins in this genre, but it continues now with other tools and frameworks. Being able to point-and-click a tool and plumb it together isn't programming--but people will claim it is. Then when someone asks for an actual program--those people fail.
This does not necessarily mean that those people are not productive. However, it does mean that they can't actually function in a position where they are expected to program.
It's because some large percentage of your time at work is spent in meetings, writing emails, discussing things, etc. where actual ability to do the core task isn't necessary.
And then some large percentage of "enterprise software development" is just hooking up buttons and text fields to a database, and doesn't require any more algorithmic complexity than a few if() statements.
And then some large percentage of the remaining work can be performed adequately by just picking some appropriate ready-made solution off Stack Overflow.
Put them all together and chances are, you can skate by for years (and actually perform acceptably) without ever actually needing to write FizzBuzz-level code for yourself.
It's because current tech interviews are a complete failure and none will admit it. In ten years you'll hear a new fashion and today's will be decried a failure.
The set of interviewees for a software engineering position is not really a representative sample of workers in the industry. Particularly at a company that doesn't have big name recognition, you're going to end up disproportionately getting job applications from the bottom sections of tech talent.
There is a difference between me asking you how to optimize a graph algorithm (good luck--I probably couldn't do that on the fly with references in front of me) vs giving me a basic FizzBuzz.
If I let you pick your language for your FizzBuzz, you need to demonstrate at least some of the following things:
I/O of any flavor (I'll even accept Logging if you don't do standard I/O or console I/O)
String formatting
Modulus Operator
Nested-If statements (or equivalent--Matching, case/switch, etc.)
I'm not looking for production code. I'm looking for 10-20 lines of "A High School senior with a computer class could pass this."
This is not limited to programming, sadly.
I used to have to interview VLSI designers with "Draw me an inverter", and 70% of them couldn't pass.