A Senior Engineer’s Guide to FAANG Interviews

Context: I've interviewed around 200 people for our current org, and have "settled" on an interview that's used for a certain position. I don't think I'm necessarily good at interviews, and I'm not sure I'm "doing it right". I give the number to show that my sample size is reasonable. We're solving practical problems, with code. Our interview sessions are 45 minutes for each person (which is the fundamental limitation).

I don't look at GitHub projects, or really ask about previous work.

I used to, but I very quickly found that the vast majority of people lie on their resumes. Generally, the more senior, the more lies. Most people put bullet points of "achieved x" which end up really being "kinda helped those people who were achieving x". For GitHub, in most cases, it was obvious the person was not the author of the Github repo they gave me. They could answer questions about the code, but couldn't go into any depth about it.

I found that going over previous work, or Github repos, ended up taking a huge chunk of the 45 minutes, that put each person on a different standard, somewhat of their own crafting, leaving no time to find out if they were actually able to write a for loop or not, which I've had Phd candidates, with "15 years of experience", fail to do. For feedback of the candidate, I need a tangible justification, and clear demonstration of why I say yes/maybe/no. There are no "gut feelings" allowed from the panel; you need reasons.

So, I give the candidate a simple, practical, work relevant, problem to solve during the interview. No compilation, no running code, no worries about perfect syntax, and no esoteric knowledge/libraries required. They're free to use whatever language they want. It's an interview where they have to demonstrate their thought process, how they question/navigate the requirements, and ability to see consequences (which I think is 90% of programming).

Maybe a few percent have finished within 10 minutes. For these people, we had fun talking about their other work, and they showed great knowledge, as expected. But, as desired, that wasn't required to do first. The interview itself proved that they would already.

I would love feedback about this approach, even though it seems to be working well for our orgs needs. Ideally, I would take the Jim Keller approach, and have a nerd out session, but, I have a feeling people are more properly filtered before they would get to him.

Diving into a github and then asking questions about it, in the same way as you would ask about stuff on a CV seems like a massive win for the skilled interviewer.

I did the recruiter call, then phone screen, then a series of 4 hour-long interviews. Since it was AppSec, not coding, I expected 3 interviews asking me technical questions about AppSec and a behavioral interview. Instead, all I got 3 hours of behavioral/leadership principles questions (With a lot of repeated questions between them), and 1 coding exercise.

I got rejected while feeling like I never actually got a chance to show my technical ability to do the job. I know how much they value leadership principles, so I probably wasn't going to get the job anyways, but it still made me feel a bit disgruntled.

What would be your advice? How do you personally deal with fails? It feels shitty every time it happens, regardless of the amount of reframing or whatever else I put into my mind.