Comment by 6gvONxR4sf7o | Hacker News Reader

Comment by 6gvONxR4sf7o | Hacker News Reader

Parent Full thread

More specifically than just a glut of engineering talent, is an incredibly broad range of engineering talent. I'm not talking about genius 10x engineer controversy or anything like that.

I'm talking about the difference between someone transitioning fields fresh out of a 12 week boot camp and someone with a computer science degree, full stack experience, and knowledge of what's going on under the hood. Even when you see many years of experience on somebody's resume, it's really really hard to tell what that means.

It's the combination of a really wide range of skill and a really big difficulty assessing that skill from just the resume. So the interview really has to do heavy lifting in this field.

Compare that to my partners field, where there's a licensing board, the job duties are pretty much the same anywhere, and all you really need is quick check of is this person sane, is their license and training up-to-date, and do their references check out. Even in that field, you can imagine the interviews being way more extensive if there wasn't a license requirement and mandatory regular training. It would be like a lawyer having to pass the bar exam at every interview, instead of being able to say that they've passed the bar exam.

(This is all coming from somebody without a CS degree who transitioned into the field, so I'm really really not proposing we do gatekeeping. I'm just acknowledging that without gatekeeping, we effectively have to pass the bar exam at every interview.)

I believe I have posted this before, but one of the big problems with this industry is the mashing of a whole bunch of different roles into the same bucket.

I used to be an electrical engineer. In the traditional engineering world there are mechanics/assemblers (high school with maybe a vocational certificate program), technicians (two-year Associates or vocational degree), engineers (Bachelor's or Master's degree in a specific, relevant discipline), and researchers (Ph.D.+ in a specific, relevant discipline).

In the Valley-oriented tech industry, the first three all get squashed into "software engineer". It's often not clear what a company needs, even to the company. Some companies seemingly don't care; Google, for instance, seems to hire all software engineers to the same bar then sorts them internally into the mechanic/technician/engineer bins based on what teams will take them. I think hiring is going to remain fundamentally broken until companies start making an explicit distinction between these roles when they open reqs and interview candidates.

Now, I'm not saying my former industry's way of doing things is all good. I have effectively left it for good by virtue of not having touched a circuit card or JTAG debugger professionally in 14 years. I do think this industry could learn from the separation of roles, though.

The problem with the bar comparison is that at a white shoe law firm (the rough equivalent of FAANG) associates go through an extremely competitive, up-or-out apprenticeship/hazing program. The interview gatekeeping isn’t gone, it just becomes chronic instead of acute.

I think in addition to the skill differences, there are also huge opinion differences. Nobody really knows the best way to write software, but everyone has their particular way they think it should be done. So even if you had two genius developers, they might disagree so much they essentially can't work together.

> It's the combination of a really wide range of skill and a really big difficulty assessing that skill from just the resume.

If you know what skills you are looking for (hint: lots of companies and recruiters don't), this is not actually that hard.

For every skill, there are questions that should be really easy to answer for everybody with expertise, but are suprising/hard to answer for everybody who pretends to have knowledge. This enables you to check quite quickly whether the claimed skills are actually there or not.

For example, the easier sections in

> https://github.com/satwikkansal/wtfpython

might give you a hint for topics that most seasoned Python programmers should know blindfolded while they are probably rather surprising for anybody with shallow Python knowledge. Let the applicant explain how they came up with their solution for, say, some of the problems, and you will see rather fast whether the claimed skills are actually there or not.

Quizzing on programming language minutia is a terrible way to hire. It's mostly quizzing how long people have been writing that specific language and their interest in language minutia.

It's been several years since I wrote JavaScript or Python on a regular basis professionally and I'd almost certainly fail your quiz. Yet I'm very confident I could be quickly productive in a Python environment.

Interviews should probe thought processing, not language minutia.

> not proposing we do gatekeeping

The opposite of gate keeping, by analogy, is letting everybody in. That is, hiring each and every single person who applies in. As soon as you set a minimum bar, the first person who can't clear it accuses you of "gatekeeping".

I meant gatekeeping to the whole industry itself, like everyone needs a license and certification from the American Association of Software Engineers, for which you need a computer science degree from an accredited university, or something like that. Good point though.

Reply on news.ycombinator.com