Comment by SavageBeast | Hacker News Reader

Comment by SavageBeast | Hacker News Reader

Someone here pointed it out on another post a long time ago but the only explanation for the hazing ritual that has become modern hiring is that we have a glut of engineering talent.

I'm interested to see what the new trend of remote work will do to the current paradigm. I think the lot of us are about to find we're not much more than highly skilled mechanics.

Edit:

On reading all the comments that came after mine, I realize I'll have a decision to make Q1 2021 when my role at my current startup becomes financially unwise to maintain (slow growth on a popular product in a very niche industry). Im a co-founder but still it will make more financial sense to put the tech product in Maintenance Mode for awhile with some offshore contractors. All the hard work has been done save for riding out the slow Change The Industry adoption curve.

When this day comes I'll be back on the market myself and in considering all this I think Im going to target large F500 companies who's core business isn't tech or internet or whatever. Companies that rely on tech as a part of their larger non-tech business.

I know folks who are devs at AMZN and GOOG and I can't help but come away with the impression that save for the RSUs they wouldn't be there either. The pain around getting the offer may not be the worst part - the worst part may be after you accept and actually have to work there. Fairly simple logic might indicate that if the dating phase is this bad, the marriage can't be much better.

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 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.

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.

> 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.

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.

Having been on both sides, that seems like the most likely explanation. For a given job posting we see hundreds of applicants, 90% of which have no business applying for that job and maybe another 5% are close but unqualified.

The process has become optimized for weeding out the 490 bad applicants to eventually get down to the 10 worth talking to. It's painful for both sides, but eventually it does get there.

I think it's more so one can retroactively justify picking a particular qualified candidate from a list of 100 qualified candidates.

That opinion will make anyone with experience in hiring think that you don't have it (experience in hiring). Sturgeon's law holds true for job applicants.

on the other hand, 90% of tech hiring managers have no business being in the decision making position.

it's a lose lose situation

I think this is part of the answer to the question of why hiring sucks. I was speaking to a coworker at one point and discussing mistakes that led to a rejection, and the conversation turned to the fact that these mistakes don't make someone a bad engineer, especially if they weren't actively preparing for interview. He said "Well, you have to reject someone", and the conversation kind of ended there.

I found this answer to both be true and unsettling.

pandemic has worsened the situation

big tech engineer turnover has ground to a halt (employed engineers playing it safe)

they have open positions but those were based on pre-pandemic turnover estimates

so they don't need to hire as many

the result: perfect coding challenges not enough ... now also need perfect behavioral answers, perfect 40 yard dash, perfect push-ups, perfect knife juggling, and most importantly, perfect clown show while wearing red nose and green wig.

Reply on news.ycombinator.com