> Note though that asking them to write code does not equate to leetcode. We'll generally give people access to an IDE containing a template project and common

> Note though that asking them to write code does not equate to leetcode. We'll generally give people access to an IDE containing a template project and common tooling they would use on a day to day basis in the job. We also select problems that have some relation to our systems rather than asking hardcore questions about algorithms and data structures: we give them internet access so they can look that stuff up if they need it to help them (just like the rest of us do in our day jobs). This is the best way I've found to assess if the interviewee can actually do the job. If you're trying out to be a violinist in an orchestra, they'll give you some sheet music and ask you to play your instrument. Leetcode would be like sitting the prospective violinist down at a piano, then asking them how to resolve exotic chord progressions and grilling them on obscure music theory. Yeah, any great violinist who studied at a decent music academy probably learned that stuff and still remembers it, but it's still a stupid test for the job you're asking them to do. > Cynically, a lot of interviewing I've seen over the years seems to be about the interviewer trying to appear to be the cleverest person in the room I'm even more cynical. People who were hazed to get where they are tend to want the new people to get hazed too. To them, it's only fair. And make no mistake, leetcode is hazing: it's not a test of ability, it's a test of how hard you're willing to grind for the possibility of giving a company your labor. I think it can make sense in only one instance: for entry-level positions, if the person is trying to break into the software industry and they don't have a relevant degree. These people simply won't be able to do the same stuff that someone who's had a relevant position (or even just an internship) would. Navigating an unfamiliar IDE alone might kill them. But if they've done a bootcamp and they can crush some hard puzzles, they're probably competent enough to train up quickly, and it they're eager and they seem like they'd be great to work with, it can absolutely make sense to bring them onboard. For everyone else, I just want them to show me what they've done in the past, and I want to test them on a problemset similar to what they'd actually be doing on the job just to make sure they're not full of shit. This is usually much less stressful for everyone involved, and provides a much more accurate signal. The reason Google doesn't do this is likely for HR reasons: for a given position, they have to try to give the exact same interview questions to each candidate, as steering individual interviews in different directions on a whim can open them up to discrimination lawsuits. For example: women applicants might have less technical backgrounds on average, be given leetcode problems, and then the company could rightfully be accused of giving a typical woman a harder set of questions than men. But there's opportunity there. While companies of Google's size are forced to formalize and lock down their interviews pretty hard out of an abundance of caution, smaller companies have a lot more freedom to tailor interviews to the individual candidate to figure out if they're right for the job. Great hiring managers figured out years ago that you can build a stellar team by snatching up the really talented folks who either refuse to play the leetcode game or happen to have a life outside of work. They're easy to identify if you're looking for them.