Other industries manage this problem by having a professional qualification that you do the exam for once, and then you're good for years. Possibly with refresher courses to keep up with rule changes.

> filter out applicants who are completely unqualified, from the vast amounts of people applying.

It's not really surprising that industries which pay incredible amounts of money get a lot of applicants.

The "gate" has to be somewhere. At the employer, or at a professional body, or at the education system? All have advantages and disadvantages.

If people did generally put the gate only at the employer, where they randomly hire and then fire their way back down to competence, people would complain about that too. And with some reason.

A further lemma: No matter where the gate is put, a lot of people will complain.

The problem with programming is that it’s easy enough to self-teach to reasonable competency without going through the formal channels. Contrast becoming a physician or engineer.

That's not only the history of our industry given that CS and CE arrived much later than programming jobs but it's also a feature.

CS and CE cover some theory, but that theory is widely inapplicable to most jobs in the industry. People that don't come from formal backgrounds often work in cross-functional roles or roles that CS and CE deeply don't touch on. An example of the former is SREs. You can become a SWE by getting a CS degree, but a SRE job involves policy, userland software, systems, and so on skills. An example of the latter is Systems Engineering. I've found very few formal schools for Systems Engineering in the way it's practiced in industry. To make matters more complex most systems engineers also need to be familiar with writing application code.

I don't think that's a problem, as long as exams are open. The problems would be a) blindspots among the self-taught, or b) largely useless, complex material added to the exam by the people who sell formal education in order to force people into formal education.

edit: and only the second is a real problem, the first is a feature.

> Another part is the job market, both employer and employee side. As long as only reasonably qualified people apply and companies accept reasonably qualified people having multiple rounds of interviews is just a waste of everyones time.

Right but that doesn't happen. People throw their resume at any company without a second thought, and then outright lie on it.

We have a rule that we only ask questions about stuff they write on resume or submit in questionnaire (that is basically "here are few things, judge in 1-5 scale how much you know them) and still some people say they are expert and fail basic non-curveball questions or topics.

Going back to EE example it would be like writing you're an expert on amplifier design then not being able to recall equation for gain for noninverting operational amplifier

It absolutely is an indictment of the applicants as well. These questions get asked for a good reason.

One problem I see is that these types of interviews, which are essentially basic aptitude tests, might be regarded by the interviewers as far more than they really are. The idea of "preparing" for a coding interview is absurd. If the applicant feels it is neccesarry to prepare he either is completely unqualified or the testing method is bad.

I am quite certain that in a 15 minute talk I could easily figure out if some applicant has the technical knowledge for a position similar to mine. And that seems to me what Interviews should be about.

>One problem I see is that these types of interviews, which are essentially basic aptitude tests, might be regarded by the interviewers as far more than they really are. The idea of "preparing" for a coding interview is absurd. If the applicant feels it is neccesarry to prepare he either is completely unqualified or the testing method is bad.

I think it is because it started as just simple "weed out the weeds" questions and somebody got bright idea that "the harder brain teasers they ask the better candidates will be left", not realizing they are just recruiting people that are good at trivia.

That 15-minute talk would also give you the more important information of how easy they would be to train on all the things they do not yet know.

Yep. I've never screwed up hiring people just by having a technical conversation. It just never goes wrong in the sense of me hiring some person who couldn't learn to do the thing I wanted. The only bad hires I've had were motivational, people who decided to do other things with their lives despite knowing how to code.

With any modern tech-heavy business, there's just so much industry specific jargon that if you hadn't done whatever was on the CV that led to the interview invitation, you would get found out in a short conversation.

I hear people sometimes run into some smooth talker who knows all the words and none of the actual skills. Never happened to me, and it's so far from it I can't really imagine it.

My guess is that the smooth talkers are more of a problem in jargon-heavy interviews.

I strongly suspect that discriminiation, affirmative action, and bureaucratic recordkeeping play at least some role here.

Informal, application-free processes are great for those for whom they work, but are also frequently a path to discrimination based on ethnicity, gender, religion, or other factors. Standardised forms and recordkeeping provide a track record that can help address any claims or investigations arising (though won't always cure the underlying problem).

That and simply increased information-handling capacity by businesses, moving from pen-and-paper to computerised formats --- initially punch-cards, now almost entirely electronic recordkeeping.

An awful state of the industry matched only by the number of applicants that fail them. I shouldn't assume 'they wouldn't waste company time on them if they weren't necessary', but they are, in fact, necessary.

> Personally I think "coding interviews" are just very insulting and speak of an awful state of the industry. Imagine giving an electrical engineer a 1st year undergrad assignment to make sure he really can calculate the properties of a basic circuit. Seems like a good reason to just walk out.

I don't want to defend whiteboard programming, not at all. But I think one can get a lot of value out of simple concrete questions.

Example: Person applying to C/C++ systems programming job -- think low-level file formats, kernel interaction, custom network protocol -- without understanding hex numbers.

Me, the interviewer, asking what 0x10 is in decimal (feel free to use pen & paper!) is a lot quicker than trying to sniff out a good bullshitter that you've allowed to be in control of the conversation.

No, I really don't think you can do the job without knowing hex.

Yes, I really think any background that would have prepared you to be successful at the job would have had you interacting with binary data in some form. (Saying you personally prefer octal would have been a plus, not a minus -- it would have communicated experience.)

I absolutely agree, I even like the question.

The difference to the coding interview is that nobodys time is wasted. It is a very quick question and if you get a slightly confused "16" back, you can just move on to more relevant matters.

This is different to a 30 minute long question where you examine the applicants ability to solve first year undergrad homework.

But that you are asking the question at all speaks by itself for major problems in employment.