My Google interviews were similar. A guy had me write an algorithm for scoring bowling, then after everything asked me to "turn it into an API" without specifying anything beyond that.

I asked a few questions about the use cases and he refused to expand.

At that point I had no choice but to just start adding weird methods and turning the one-shot algorithm into an iterative scoring class (where you could calculate score as you added frames) and the guy started to nitpick literally everything I did.

"Why did you indent here?" Because a new block of code is there. "Why did you put the brace on the same line?" Because I like to follow 1tb style personally, but I can change it if you'd like. "Yes please do."

Then was rejected, without any feedback other than "perhaps consider brushing up on your coding abilities, or take a code camp and try again in 6 months". I've been writing code for 20 years, 11 professionally. It is, quite literally, almost all I ever do.

Ultimately realized how terrible of a company Google was, anyway, so I dodged a bullet in the end. But you just kind of have to learn to roll with these punches.

And yet they're still terrible at interviewing.

Why?

(and if you think I'm exaggerating-- thats how Steve Yegge described it when he was interviewing at Google, though it migth have changed since then)

My radical proposal is to record interviews, for later playback and study.

Ages ago, I ran for office. Very similar hazing ritual.

The recorded endorsement interviews were generally terrific. Only one of the unrecorded interviews was constructive; I wish it had been recorded.

The majority of unrecorded interviews were shit shows. Which then seeded more drama. I quickly learned to make my own recordings. Kinda like having dash cams.

And the spiral continues.

'Not the most efficient solution' was the feedback, even though all that was happening was that their method required 1 loop and mine had split those operations into 2 loops, with exactly the same time and space complexity.

Oh, and I had immediately taken their hint to modify my code anyway and the solution was working in both cases.

FAANG and peers set the bar about 1-2 std. div. above their typical hire. The cost of a bad hire is much higher than the cost of a missed good hire. People run the gauntlet. You can do the stats, but it:

- Misses a majority of good hires

- Rejects a supermajority of bad hires

Unless you are 1-2 std. div. above a typical Googler, you should expect multiple interviews before you're hired. If you're qualified, and it's 1 std div, it takes about 3-4 tries. If it's 2 std. div, it takes 20(!) tries. If you're underqualified, that goes up very rapidly, and if you're overqualified, it goes down a bit.

Few people are overqualified on all axes (soft skills, coding, system design, etc.), so virtually everyone runs into rejections like this. The sooner you learn to deal with rejection, the better off you are.

I see this all the time, but never anyone backing it up with studies.

I'm not calling you out specifically - but rather, I wonder, does anyone here have any comprehensive study on this topic that they can link?

(I'm asking, because this industry is littered with dubious claims that sooner or later become accepted as facts)

A single bad hire can suck up the vast majority of your management time, drain team morale, drain it further when you inevitably fire them, open you up to liability, and generally make your life miserable.

Bad hires do slip in, and each time they do, BOY does it suck.

You need a study for this just about as much as you need a study for "Don't touch the kitchen burner."

I think, based on comments here and elsewhere, FAANG companies always have job postings up and are always interviewing simply to vacuum talent up from competition and to project the image of an ever expanding company that is hard to get into. I wouldn't like to be forced into interviewing candidates for essentially generic job postings where the majority of outcomes for candidates is negative. How depressing.

How's that metric determined? For the candidate, current staff, and interviewer themself?

    <div style="z-index: 2" />

* Setting the bar at 2 std dev means you need to interview 20 candidates at your hiring cut-off to find one you believe is qualified. The other 19 qualified candidates get rejected by chance.

* Setting the bar at 1 std dev means you need to interview 3-4 candidates to find one who you believe is qualified. The other 2-3 are rejected by chance.

Of course, most candidates aren't right at cut-off, so it's not quite 1:20, but it is pretty random. A good model for hiring, from the candidate side, is that you interview. If you pass, you role a die, just like in an RPG.

Unless you're coming in through a side door or a backdoor, rejections are just part of life. People take it personally, and fault the interviewer for a bad process, but interviewing is fundamentally a very noise measurement. It's the only way we've found to get good employees at scale:

* You set an unreasonably high bar.

* You interview a lot of people.

* Occasionally, qualified candidates pass by chance, but the majority are rejected.

* If you set the bar high enough, unqualified candidates will rarely pass by chance, by virtue of how Gaussian curves look

* Let's say I was hiring someone to do calculus.

* I want applicants who typically score at least a 90% on a calculus AP. The exam has a std. dev. of 3 points.

* I get an applicant, and I give them an AP exam.

* They score a 91. What do I do?

That means they are 1/3 of a std. dev. above my cut-off. They might typically score 88 and got a little bit lucky, or even 85 and got very lucky. Or they might typically score a 94, and got unlucky.

If I hire that person, although they're probably qualified (assuming a uniform distribution of applicants), I'll get a lot of bad hires.

To avoid that, I set the cut-off at 93% or 96%. This means I intentionally reject most people who meet my cut-off. On the other hand, if I hire someone, I can be pretty confident they're qualified.

The cut-off needs to be high in part since the distribution of applicants isn't uniform. Most applicants are unqualified morons. Qualified people will apply to a few places, and are quickly hired. Unqualified people will apply over, and over, and over, everywhere they can.

Given this is true, won’t it be the case that you’d hire more people who were unqualified but repeatedly got better at interviews as opposed to the qualified one(someone who always gets 91 or 92 in your example)

You’ll actually end up hiring folks who are not good at what they do but people who got better at interviews.

That's not really how it happens, though. You get people who are really good at whiteboard coding and little invert-a-tree type exercises, with no other skills. Most don't do this through interviewing over and over, but by practicing online. You end up with big companies full of people with nothing better to do with their time.

A lot of the people who interview over and over really have no idea what they're doing wrong. Employers don't give feedback, aside from "Thank you. We'll let you know. [ghost]," or at best "Thank you. We filled the role." A half-dozen interviews helps, but from then, it's rapidly diminishing returns.

I like startups, where you can do all sorts of side and back hiring channels, but none of those scale above maybe 100 people, and usually not past a dozen.

Definitely a good advice. Thank you. I appreciate it.

For some random and arbitrary reason you and this existing employee didn't get on and are likely not to work well together.

This fact is obvious to them, to you and even HR - everyone is in agreement on this.

I wouldn't look as the rejection as just personal criticism of you - I'd see it as rejection of a team consisting of you and them. Unfortunately as they're the current employee and you're the applicant, you get the shitty end of this 'team rejection stick'.

I'd take the suggestion to "apply to other teams" as strong positive feedback and do just as they suggest. I'm sure Twitter has a long and illutrious applicant list, so if they didn't think you were a fit for the company they could have just told you (or not) and phoned the next person.

I got told I "didn't have enough C# proficiency, and this role is unsuitable for C# learners" on a take-home assignment recently. I found that feedback point interesting but vague, so I pushed my luck and quizzed the recruiter further. Apparently the problem was using C# 9 features (pattern matching, record types). I'm not really a cynical person, but I find it amusing I'm apparently incompetent in a language because... I can use the new features? (You could say I over-complicated it, but I really didn't.)

In my experience time spent at the beginning of the interview establishing rapport with the interviewers is well spent. Make smalltalk before the interview properly starts. Ask how the interviewers plan on asking questions. Always stay friendly, agreeable and positive. It's far harder to be an asshole to someone you've already been nice to. If they continue to act up, then feel free to end the interview yourself because you don't want to work there.

Bottom line is - if a company actually wants to hire, they don't waste time. I've met engineers from other companies at meetups who told me they have rejected every single candidate because they didn't want to hire, management was pushing them to. Others said they have deliberately chosen "Elite Language X" to weed out "bad developers" and so on.

I'm a tadpole in a puddle.

I recently wrapped up a job search, and it occurred to me just now that in each of my job searches since finishing undergrad I’ve ended up at the company with the least painful hiring process. That’s not something I’ve intentionally tried to optimize for, but apparently I weight it pretty heavily.

What’s really interesting is that this time around I ended up in a US federal position that I cold-applied for, over private sector positions for which I was being actively recruited. You’d think startups would be able to do better than the most bureaucratic organization in the history of our species, but no, they insisted on 5+ rounds of interviews and 8-hour “take home” exercises.

For what it’s worth, my previous employer was a startup, I applied on a Friday afternoon and had a written offer in hand on the Monday morning 6 business days later.

He started off by saying that he knew I had interviewed at a lot of other companies on campus, and that I’d probably heard a lot of positive things said about those companies. He said that I could assume that all those same things were also true of working for the government.

What he then proceeded to spend his time doing was telling me about all the disadvantages of working for the federal government.

I really, really appreciated that authentic and unvarnished (well, probably lightly varnished) approach. And for some reason, they decided to hire me anyway.

Thanks, Mr. Brewer!

A dev I knew used whether somebody knew string intern() as his main indicator that someone was proficient with Java. This one trivia fact determined whether or not you were considered proficient.

5 candidates who could talk but could barely write a line of code later, three technical screen was then the first layer.

I'm not talking difficult leetcode style problems either, my initial questions were barely a step a above fizzbuzz.

I got invited to a Leetcode interview yesterday. In the interview instructions doc, they have this:

"Review data structures and algorithms from university, stuff you haven’t touched in a while."

So they admit that it is not used regularly, at least not everything by everyone, but go learn it for the interview anyway.

When you use algo questions, people complain that it's not practical.

When you do use practical questions, people complain that they can't study one thing for all jobs like with algo.

When you do a take-home, people complain that it takes their personal time with no commitment from company's side.

When you take more than 1h for an interview, people complain that it takes too much time, some will demand payment.

When you do remote interviews, people complain that the dynamics is not the same and they'd prefer to whiteboard stuff, or that they'd rather not turn their camera on for whatever reason.

When you do on-site interviews, people complain about commuting and coding with people watching.

If you do fizzbuzz, people will be offended because they think you think they are idiots (this includes people who can't do fizzbuzz)

If you interview people with many years of experience in the industry, some will complain that they have to do anything during interviews since their credentials speak for themselves. Some of them will try to pressure you into changing the interview process just for them. These people are typically the worst candidates you get in terms of skills and personality.

When you don't give feedback, people complain about it.

When you give feedback, people will disagree with it, sometimes violently (I was stalked by one particular weirdo).

If you ask soft questions, some people will complain the questions have nothing to do with the job.

If you don't ask soft questions, some people will think that the interview is very impersonal.

Complaining about the take-home, fizbuzz is a little unreasonable. Complaining about needing a perfect Leetcode medium answer in 30 min is not an unreasonable complaint.

Okay, so it was for a DevOps Engineer role and not an SDE role, but we did have one guy who refused. He didn’t feel that he was a good enough programmer to do that on a whiteboard in front of a panel of interviewers, and so he refused. He even refused to talk about the core functions you’d need to make fizzbuzz work. He felt that he could work it out over time outside of the pressure of a hiring situation, but he didn’t feel he could do it on the spot.

To be honest, I felt that his recognition of that lack of skill and talent and his refusal to be pushed down that road, that was one of his strongest features for me. He was willing to stand up in front of the whole group and say “I Don’t Know”. I pushed hard for him to be hired, and the guy who had asked the fizzbuzz question didn’t feel as strongly that we shouldn’t hire this person.

To this day, I think he was the best hire the company ever made. I don’t know if he ever learned how to do a fizzbuzz program, but he was definitely one of the best DevOps Engineers we had.

I know this because I had 4 roommates who were working at the same firm, with the same job title, but under different Partners.

P.S. I guess this is one of the non-legal related reasons why companies don't give feedback, they'd like to avoid being featured in hackernews, I presume.

EDIT: I always forget driving my point home after crafting a lengthy comment.

My point is, I can almost guarantee that someone out there has the exact opposite of your experience w.r.t. the hiring process of twitter.

It's very difficult to counter because you don't know the people interviewing you or the team's politics. You're discovering it as the interviews go based on cues, including the way they interact among themselves.

I completely agree. I had that feeling. He made up his mind already.

Then they send out a rejection letter saying you don’t know enough about the topic. What can you do? Reply back ‘But you know that topic has nothing to do with the position’. It was the first time I saw a interview version of a ‘kill switch’.

As an interviewee, you also develop radar for this where you also can just check out 10 minutes into the interview and not care too much (so much is decided on initial perception, looks, vibes, speech - within minutes).

Hearing that you're "not proficient" sucks big time and this is probably what hits hard. Do you _feel_ you're not proficient? Did HR meant something else? Snap out of it and just continue. Have you been in very cozy environment you're whole life? It's like your mom telling you you're the most handsome boy and then you walk up to a girl that's say your an ugly weirdo. Maybe you are, maybe you're not. You just check out the next girl. Or boy.

Like, this whole analysis of the situation, really makes me wonder, how old/experienced everybody is (including you). Like in general, life, you know. You can code an A* heuristic in 5 minutes, but you still don't know communicate/interrupt each other during an interview?

But, I try not to burn any bridges over it. If I got the interview because of a personal connection, I will do whatever I can to maintain that personal connection, regardless of the fact that I got rejected. They might know of something that comes up in a week, or a month, or six months, or they might move on themselves to a different company, or whatever.

And who knows — maybe they did actually tell you the truth, and you just didn’t get enough context in the answer to fully understand why.

But that also doesn’t stop you from continuing to try elsewhere, and take what you can learn from that experience and apply it to your next interview.

Like, who the fuck gets to say you did bad behaviorally, or you don’t fit the culture, over a 3 hour meeting? That’s extremely unfair.

The technical feedback is up for both parties to decide and no one side is right. It was either a fair question, followed with a fair answer.

If a company was sincere about wanting interviewees to feel comfortable and to perform their best, they would ask the interviewee (ahead of time of course) to choose what videoconference software they'd prefer.

It's a joke being forced to download MS Teams or Skype or whatever just for a single interview, and then not have the ability to do a "test run" in advance to make sure your mic/camera/bluetooth are all working correctly and to become familiar with the UI.

You can’t always do that with whatever whiteboarding or shared IDE solution they might want you to use, but at least with the chat/shared screen solution, you should definitely be able to do that. Find friends or family to help you, or whatever it takes to practice that.

The in-person equivalent would be knowing exactly how to get to the building where you’re going to interview, know where parking is, etc…. You do a dry run and see what it’s like. Maybe also take a moment to look at people going into the building to see how they’re dressed.

Make sure to fully review any material that HR or the recruiter gives you before the meeting. Review it again just before the meeting. If they have any suggestions on interview techniques or the kinds of things you can do to help explain your experience, make sure you can do that in spades.

Beyond that, I would encourage you to be authentic. Be your best version of yourself, sure — but still be true to your core nature. If they don’t like you, then you’ve probably dodged a bullet.

For all my references, I ask them to be radically transparent and honest with their discussion of me. I wouldn’t ask them to be my reference if I didn’t trust what they were going to say in the first place, so I would prefer that they don’t whitewash anything they would say about me. If my references scare off a potential employer, then again — they’ve helped me dodge a bullet.

Still, even though this is logical it still can feel like a failure: it isn't.

Onwards and upwards :)

Forget Twitter lol