The myth of the developer that can't code

So much of your work has insane barriers to entry, even for internships, that I'm surprised your roles don't come with one or two assistants to manage the mundane business of scheduling meetings, filtering emails, and planning deadlines around out of office time.

I got my BS in Cybersecurity, and after a few interviews, I nope-d out of IT as a whole. They'd post preferred certs on the job description (like CCNA) only to ask why I wasn't a CCNP during the first or second interview. Or they'd debate whether some other candidate with a CompTIA cert was better prepared for the $15/hr. internship. And I'm nowhere near the specialization of most engineers.

Awesome, awesome work, but it takes a ton of grit to get your foot in the door, and even more grit to switch jobs.

I work for large corporations, mainly banks.

In this setting there are couple of ways for people with absolutely no ability to code to get through the cracks. For example, one way this happens is through an external contractor vendor.

These vendors are only interested in fulfilling contract requirements and typically will try to sneak developers with least ability they can get away with. As hiring process for vendor-supplied contractors is relaxed it is not at all difficult and will only depend on management of the team/project to prevent. Then, if it is no longer sustainable to keep particular developer on the project the vendor will not let go of the developer, it is more likely he/she will be rotated to another project.

I have worked for a project in Credit Suisse where the "principal developer" was a person rotated from another project where she served as "development manager" and had many years of "experience" as Java developer before that. This person had only barest ability to code, she struggled to write a simple loop. When asked to add Json serializer to an application she was confused and wrote a bunch of code that concatenated strings to produce something not exactly resembling Json. She did not even have knowledge to spot the problems and would blame tools and other team members for parsing errors produced from parsing the code. Surprisingly, these explanations were accepted by the management as she had more "experience" than other team members.

When I joined the team and spotted this situation I implored management to reevalute her as principal developer. The management had no development experience either and were taking her explanations on face value. They told me that I need to spend more time on the project to "learn the way they are doing things". Only after months of persuasion and showing countless examples of glaring incompetence I was able to succeed to resolve this problem.

I find it not difficult to imagine more possible settings where people with no competence in coding can flourish when they can initially build a strong position for themselves and can exploit incompetence of their managers and peers.

This is especially true for large corporations which have huge appetite to hire developers and huge budgets but also can have managers with no incentive to do their hiring very well.

In one project I worked for the manager kept overseas staff even though it was net negative productivity because "higher management said so".

Let's say I give candidates a basic whiteboard problem that requires no fancy algos/data structures other than knowing about arrays and dictionaries. A passing candidate will demonstrate the following attributes:

1. Understands basic programming constructs and elementary data structures (loops, vars, arrays, dictionaries)

2. Can model problems in her head

3. Can communicate effectively

4. Can work well under the pressure of an interview environment

So it's process that selects candidates that have desired attributes 1+2+3 but the downside is that it also selects irrelevant attribute 4

This is a pretty good system! Sometimes it will fail because candidates will be rejected for lacking 4 even though I don't care about it. Is there a better system? I don't believe that just looking at resumes and past experience selects for 1+2+3 nearly as well.

Furthermore I've said that "works well under the pressure of an interview" is an irrelevant attribute, but I think you could also make a case that it is weakly relevant in this way: if a candidate can do 1+2+3 while under pressure then you would expect them to perform 1+2+3 as well _or better_ when not under pressure.

There is also desired attribute 5 "is pleasant to work with" — coding interviews don't really select for this, but I don't think anything else does either short of probationary periods.

For instance explain the concept of MVC. I have interviewed candidates that only could explain where they would put certain code based on the framework they used but could not explain the design pattern nor why they would put the code where they said the would. these types of questions will give you some insight if someone is able to reason about code and explain why they prefer some style over the other.