> If it's FAANG

And that's really the issue.

The FAANG's are throwing around so much money that people are willing to put up with almost any amount of abuse to be on the other side of the line. The FAANGs can deal out any amount of abuse and they will still have a line of applicants around the block--there is no negative feedback in the interview process no matter how bad they make it.

> Hiring in Tech is broken and I don't know what we can do to fix it.

Software hiring in the Valley is broken--possibly.

Hardware folks I know still go through the same old, same old. Single phone call with an engineer to make sure you're not simply a waste of oxygen. One on-site with 4-6 people (and 6 would be an unusually long day--generally that would mean you're doing well and some extra people want to talk to you). One week to response--two weeks MAX.

WTF are you software people doing?

I've interviewed for ME, EE, FW, and SW roles. It's not better in hardware. There's an equivalent to all the things people are complaining about here. Take home coding challenge -> take home hw design challenge where they expect you to have access to expensive software. I got a FW challenge once that assumed I had two different dev boards on hand. Spot the bugs in this printed out code? Find everything wrong with this schematic in 5 minutes. Now quick what's the transfer function of this filter? I have a dozen more questions to get through.

I had an ME friend who got into an argument with an interviewer about the convection equation. The interviewer was completely wrong, eventually my friend admitted "Ok I literally have it pulled up on my screen right now, I think you're mistaken."

> Spot the bugs in this printed out code? Find everything wrong with this schematic in 5 minutes.

I don't consider those terribly unfair. Depending upon how the discussion goes, I could see myself doing something like this.

For example, one of my standard questions for firmware people is a state machine in Verilog (for those who claim to know Verilog). What I'm looking for is whether you know the difference between blocking and non-blocking assignment.

> Take home coding challenge -> take home hw design challenge where they expect you to have access to expensive software.

> I have a dozen more questions to get through.

These are not fine, though.

> The interviewer was completely wrong

This, sadly, happens. I have had an interviewer cite incorrect information about semiconductor device physics.

Quite often, though, it happens in more junior interviewers with "standard" questions that are passed around because the interviewer doesn't fully grasp the question. When I was a junior engineer, I was always terrified that I would make that screwup. I used to do review study on my own questions and area before every interview to make sure that didn't happen.

For example, I had an interviewer who gave me a question of "clock a binary number in serially and use a state machine to divide it by 3." It's a really cool question and was passed around between engineers of a certain company. But ...

This is either a really easy question or a really hard question depending upon your choice of direction to clock the number in. If you pick the easy way, it's something like 3 states and it's obvious. If you pick the hard way, it's 6 states and takes a somewhat subtle inductive proof to show that you're right. If the interviewer doesn't know that this can happen, he can't dig the candidate out if they pick the hard direction.

Of course, you know which direction I picked in the interview. LOL.

I have no problem with spotting schematic issues (or spotting code issues) given appropriate time to do it. I actually prefer these to rushed questions where you have to implement the solution because it lets me get into the design considerations without spending time drawing symbols or stumbling through syntax.

Last time I got that question it was a schematic large enough that I would have put it on multiple pages and I only had a few minutes to get through it, which was a problem. Brought it up because it seems to be a touch point for others.

> WTF are you software people doing?

I think it stems from the fact that software is "soft" i.e. highly malleable and flexible. This improves time-to-market considerably and there is an inherent expectation built-in to "move"/"execute" quickly.

This also creates problems. Now the same thing can be done in multiple ways. There is a "my-company" way of doing. There is "my-way" of doing. Throw in personal tastes, likes-dislikes for testing, syntax, editors to name a few. Over the time, people take on multiple identities (e.g. FAANG, language fraternities, clubs of certain technology, editor fraternities etc). These mix and match in at best interesting ways and at worst in toxic ways.

Seems like software engineering too often attracts personalities that like creating uncessary complexity. It is deeply ingrained in the culture.

I think we can teach people how to hire. The way I would do it is three-part:

1. An exam. You literally take a test. This mostly takes care of the technical portion, evaluates your cognitive skills, IQ, EQ, whatever. The idea is to get a general idea of what you "know" and gives some baseline reference numbers. You could also do a "coding test" as part of the exam, but I would not lean too heavily on those as they are subjective too. You would need to look at the results to see where they were strong/weak, as for some roles it's fine to be weak one place and strong another.

2. A veteran/senior (or two) interviews the candidate, asking deep questions to probe into the person's actual experience - because experience is 1000% more important than "what you know". The way I do this is a "binary search" of questions both simple and very specific, and based on responses I get more general or more specific. I can very quickly discover how much real-world experience the person has this way.

3. An interview with the team. This is actually for the team, not the candidate. The team can see whether the candidate is a mesh for their particular culture. It's just as important that the candidate fits the team as whether they're capable of "performing".

Within this system, you wouldn't ever do more than 5 rounds (3 on average), you get a mix of "impartial facts" (the exam) and "gut feeling", and you still have the human factor both evaluating the person's experience/responses and checking for culture fit.

> Why don't you find people working on a problem you like, then ask them if they have open positions?

That's not always straight forward. Once you get patched over to HR, it's their process.

I am glad to hear that this is still working for you, hopefully a serendipitous moment will occur soon to open a door for me as well.

> Working though engineers is almost always better than filtering though company recruiters.

Doesn't this say something about hiring being broken when you have to dig through profiles on a company website or linkedin and cold contact devs to get your foot in the door?

I am by no means suggesting that what you are saying is a bad idea, just that this reeks of poor and inefficient hiring policies.