I got to the last thread too late for a comment to make a difference, but I'm exactly the person most of you want to talk to or hate. I'm an interviewer at a F

I got to the last thread too late for a comment to make a difference, but I'm exactly the person most of you want to talk to or hate. I'm an interviewer at a FAANG company with >500 interviews in the last 5 years, I teach multiple internal courses on interviewing, and I think the system makes a lot of sense for companies at our scale. Ask Me Anything :) I currently have a toddler on my lap, but I'll edit this post later today to address some common criticisms and misunderstandings, but also point out which concerns I think are valid and where we should do better. edit: Okay, let's go through the most important points 1) I'm a Software Developer. I interview other SDEs. I ask them problem solving coding questions, algorithmic coding questions, data structure questions, and whiteboard architectural design (not at the same time, but it could be any of these) 2) Our process is REQUIRED for a company of my size. You would not believe the amount of candidates we get. We have a high bar for hiring, but fundamentally we have to be efficient with our time. That completely removes as an option superior interviewing techniques like "spend a day with the dev team working on a small real task" or "do this take home test over the weekend and then the interviewing team will review it with you". Both of these are better at uncovering good candidates than a whiteboard coding interview, but don't scale, and are themselves controversial in the industry from candidates who are unhappy of the time they require. 3) A common criticism of "algorithmic" questions (leetcode) is that they don't reflect the reality of day to day work. If a lot of people even at FAANG are working on typical 3-tier front-end-back-end-database systems, utilizing the tools and systems other employees built before, why bother evaluating if the candidates could build the next generation of such systems if asked. Because once these people are inside the company, we'd like to think that everyone passed a similar tech bar. That means that if a new database or distributed system does need to be purpose built for a high scale system, and someone applies internally, you can be flexible with the kind of interviewing process you put an internal transfer through - you already know they passed a high technical bar, and are likely qualified to work on the hard stuff. 4) another common misconception is people underestimate the complexity of "typical" systems inside the FAANGs of the world - compared to their prior job experiences. A payment processing integration at Amazon scale is not a payment processing integration at your company's scale. An internal CRM build at Google scale is not an internal CRM build at your company's scale. The 10,000 foot view is similar, but the expectation would be that the system would be 1/ built out faster, 2/ built out better, and 3/ scale better than a comparable project on a less technically strong company. 5) Coming back to the interview process. What that means, is that when we ask a candidate to solve a hard algorithmic problem on a whiteboard in 20 minutes, or deep dive into the inner workings of a complex data structure, or show how they could combine multiple data structures to solve one problem, we are not validating "Can this candidate write an algorithm in 20 minutes on the job at their desk" What we're checking is "Can this candidate do something really hard, ambiguous, and time-sensitive in the Computer Science domain, when prompted to." The real life challenges will be different, but if they CAN do the first one, they'll likely be able to do the second one. Of course we miss out on candidates who are terrible at these skills, or can't code on a whiteboard, or are overwhemled by the interview stress and can't perform. But we are willing to do that because of Point (2) above. We'd rather say no to a "maybe" candidate than hire someone who can't perform. Despite what people state that ability with algorithmic performance on a whiteboard does not translate to on the job success, that is not my experience. Remember - I'm not looking to see if a person can spit out A* search algo on a whiteboard from memory. I'm looking to see how they approach a problem they haven't seen before, how they break it down, what kind of assumptions they make, what ways they simplify it, how they consider ideas and tradeoffs, and finally how their ideas translate to code (fluently or not) 6) The majority of people I see cannot execute that last paragraph well enough to join a team at my company and be productive. Sorry, hackernews readers, but that's just the case. This isn't a "can't solve fizzbuzz" level of incompetence - these are good engineers who are likely stars at their smaller companies, and who can be relied upon to get the job done. But they would not thrive at a FAANG-level company because they lack some ability - either clarity/coherence of thought, or ability to understand their techncial domain in depth enough, or because they just aren't fluent at translating ideas into code. edit2: 7) All this to say...if you're not FAANG++(Dropbox, Salesforce, etc I don't know)....stop copying us. You don't need this process. Your company has fewer candidates, and you both can't afford to be as picky as us, and you don't NEED to. Each of my previous companies (in the 200-500 person range) had a process of a simple coding question onsite, followed by a take home test that a decent candidate (and I don't mean decent for FAANG, I mean decent across the SDE community) could complete a reasonable solution in ~2-3 hours. We set expectations as "you could do it in a weekend" because certainly some people took closer to 8 and got hired.