[koopuluri]

I believe that this problem is far, far, far more pervasive than just a software/technology problem.

> there are means to validate a candidate's competency before they are allowed to interview for a position: licensing, required internships, legal certifications/authorizations, authorized relationships, and so forth.

The problems with credentials that you mention:

1. They are often weak signals of actual competence, and in the case that they are decent, there is still a lot of room for improvement through experimenting via a data driven process (current credentialing is, in many cases, outdated, and doesn't map to what actual work is like).

2. They are not accessible by everyone. This is problematic as the means to learning is becoming more accessible (through online education, etc.), but the credentialing is still restricted - since the institutions that hand them out haven't scaled credentialing. There is a lot of opportunity to provide signal for competence that scales... and measures skill that is actually used on the job (which is also changing as technology matures and penetrates other industries - we'll need a credentialing system that can adjust to those changes quickly).

In fact, I'll go as far as to say that this is a bigger problem in non-software industries. At least in software, there is a more objective way to measure a candidate's competence independent from the path they took to gain that competence. This means that people that might not have necessarily had a formal education / credentialing have a sliver of a chance of an opportunity to prove their skill. In other industries, if you don't have the credentialing, you have no shot.

[austincheney]

> They are often weak signals of actual competence

I disagree. They are weak at separating the top 10% from the rest of the qualified people, but they are excellent at removing the people who have no business being there in the first place.

The first two that comes to the minds of most people are law and medical licenses. These licenses don't exist as a job qualifier. They exist as a legal qualifier. That means a gross abuse of the license requirements are cause for law suits and serious criminal offenses even though most lawyers and doctors are corporate employees.

If programmers had the realization that gross negligence could land them in jail or cause them to lose their career and property in a lawsuit I suspect they would take their jobs more seriously than merely writing code.

Programmers don't just write code just like doctors don't just prescribe painkillers and soldiers don't just shoot people. They make numerous critical decisions that have real world implications. Examples of gross failure are simplistic known security breaches that allow confiscation of millions of credit card numbers and PII. Other examples include discriminatory and accessibility violating software products.

These are basic foundational qualities of competence. In any other industry negligence of this magnitude would put in prison. Since the base line is so ridiculously low for hiring developers these are considered advanced qualities often transferred to third party firms and only after threats of pending legal actions. All we care about when hiring developers is whether they are literate and have a pulse.

Be serious, no change to any hiring process will fix that.

> They are not accessible by everyone.

Don't care. If a person want to achieve access to a given career they will find a way through their own internal motivation. If the industry wants to make the careers more accessible they will promote a desirable education path. This isn't a secret legendary arcane black magic.

[Cyph0n]

Law and medicine are not relevant examples at all.

In both cases, licensing did not arise because of hiring issues, but rather because both law and medicine directly involve human lives and livelihoods.

Any field where this can be the case on a day-to-day basis ends up having strict licensing and/or training requirements. Examples include civil engineers, pilots, soldiers, sea captains, heavy machinery operators, and so on.

[lr4444lr]

The guys who work at Lockheed Martin programming vehicular data sensors, or who work for medical device manufacturers on MRI machine interfaces - they aren't directly involved in human lives and livelihoods? What about the massive security failures at Equifax? That's not putting people at risk?

[Cyph0n]

Once again, these kinds of industries adapt to the kind of work they do. There are numerous bureaucratic and access-control procedures in place at defense contractors. The FDA has a ton of requirements for anyone working on medical devices.

Equifax was a monumental shitshow. I think SSNs are also a shitshow, but I digress.

[austincheney]

> but rather because both law and medicine directly involve human lives and livelihoods.

How does that not describe software? When was the last day you were completely without software? Software powers all manners of our gasoline vehicles and the various traffic signals we encounter. It powers many hygiene products and kitchen utilities. Soon all of these will be part of the internet of things if they already aren't.

> Any field where this can be the case on a day-to-day basis ends up having strict licensing and/or training requirements.

Except software.

[Cyph0n]

It seems like you're not understanding my point at all.

> Software powers all manners of our gasoline vehicles and the various traffic signals we encounter.

The automotive sector has its own complex procedures and policies in place for working on vehicular control software. You and I would likely not even be able to land an interview for an automotive firmware design position without prior experience and/or certification.

In many cases, there are entire programming standards that dictate how such systems need to be written.

In other words, the software that runs inside your vehicle is nothing like the software powering our favorite websites.

> It powers many hygiene products and kitchen utilities.

The chance of a kitchen appliance endangering a human is much lower than a car going haywire or a doctor making a mistake due to inadequate training.

[austincheney]

> The chance of a kitchen appliance endangering a human is much lower than a car going haywire or a doctor making a mistake due to inadequate training.

The chance of any device on the internet of things leaking your personal habits online is not low. Furthermore, the risk of death or injury from electrical devices is only due to regulation upon such devices before commercial software was ever imagined. I would also say the hiring and performance of truck drivers is far more regulated than the firmware developers who write the code that powers that very truck.

> the software that runs inside your vehicle is nothing like the software powering our favorite websites.

So website software doesn't need to be written by competent people with regard for your privacy or security? Is insecure online software not harmful? Are credit card data breaches not harmful?

[Cyph0n]

> Is insecure online software not harmful? Are credit card data breaches not harmful?

Harmful, yes. Life threatening, no. There is a world of difference between losing a kidney due to incompetence vs. losing money.

[sotojuan]

That tech is open to people of all backgrounds, even self taught, is awesome but it has its drawbacks: it's harder for the interviewer.

I disagree that there are objective measures and the vast amount of e-ink spilled on interviewing practice debates is proof of that (tech interviewing also doesn't correlate to the actual work being done!).

I'm on the "tech should be open to all" side but it _is_ harder for companies to filter out potential bad candidates. That's why they make up their own filters like "we only want seniors".

[koopuluri]

> the vast amount of e-ink spilled on interviewing practice debates is proof of that (tech interviewing also doesn't correlate to the actual work being done!)

You're right that CURRENT interview screening practices are far removed from actual work, but that will change. I don't think that it's proof that there aren't better assessments (which should be aligned with how work is actually done on the job). If anything, this is an opportunity to experiment more, and find better assessments.

> I disagree that there are objective measures...

I agree that there aren't fully objective measures, and may never be. What I do believe is that you can get SOME signal of competence from, say, someone's code about their competence at building something right now, which is a more objective, impartial signal than what happens in other industries which relies mostly on a behavioral interview (which allows for a lo t of bias to creep in)