[Bahamut]

My coding question I give (in the occasion I am called upon to ask one to candidates) typically is not particularly unique, but practical - if someone wants to study for it, it doesn't really give them a notable edge given all the possible branching questions. The most notable tell if people did see the question prior though is if they jump right into talking about the problem without asking qualifying questions, implying that they are quite familiar with the problem & don't need me to qualify it & don't think to verify scenarios with me.

For my non-coding problems, I just create it from scratch depending on the position/needs & spend a bit of time navigating the scenario myself and store the question in my notes.

As to failing a question, failing a single question isn't necessarily a deal breaker in itself - it's showing a pattern of not meeting the bar that is. I may rate someone a 2 out of 4 if they didn't go into sufficient depth in a particular question I asked, but I probably won't stay in the way of hiring them if they did ok otherwise and that failure was just an aberration. Loss of integrity is perception that is likely to sour people on any upside of hiring though, and overcoming that bar is incredibly difficult - if someone is clearly rehearsed on a particular question and is dishonest about it, they're probably not getting a 3 or 4.

[weatherlite]

I've failed enough interviews to know that failing a question is almost always a failing interview. There are enough candidates that will get the question right and one of them will be hired, not me. Honesty aside.To be clear I am talking about FAANGs or famous startups that get hundreds of candidates per position.

[Bahamut]

I'm a senior engineer at a FAANG who is close to reaching staff by promotion - I've conducted enough interviews over the past 5 years at my current company to at least understand how my org operates.

How the process for us works is if you are a strong enough candidate, we have no qualms giving multiple offers simultaneously and working out the reqs afterwards, even borrowing against a future one if we have to. How we evaluate is probably also a lot different & more thoughtful than a lot of candidates realize - we're discussing leadership traits, strengths & weaknesses, and skills in our debriefs and what we all observed about the candidate in our sessions. No candidate does perfect in any given session - even candidates who I have given 4s for have slipped up or had negatives observed.

[weatherlite]

I think you are an outlier then. What leadership traits do you discover when forcing candidates to do BFS on a binary tree or similar questions? Why would you take someone who said he knows question A and then moved on to bomb question B when you have 30 candidates who solves question A? Ok no one does perfect but bombing a question seriously hinders your prospects. If you see a question you know or semi know you gotta be very silly to say it. People don't drill Leetcode to say oh sorry I saw this one already. Nope. In fact even remembering hundreds of questions and being able to solve them under stress is hard enough. Many FAANG candidates are just brilliant and don't really need much preparation to get accepted. But others are normal smart but spent months preparing by going through algorithm questions. It's quite certain they come up with 1-2 question they have seen before and this enables them to pass. If it wasn't the case no one would subscribe to Leetcode....

[Bahamut]

My org is generally anti-leetcode so I can’t speak for your experiences - the only data structure/algorithm questions you may encounter in an interview with my org is likely practical questions (i.e. problems we have had to solve on the job).

I’m usually not even asking a coding question in my session - I set up a practical/common problem beforehand and we explore the scenario together. I can assure you that many candidates don’t pass my session necessarily, even if they have proven in other sessions to be brilliant coders - I’m not looking for technical brilliance in most of the interviews I give, and neither are the hiring managers I work with. To me, focusing on the coding is most important on the technical screen, not the full panel - once you reach the full panel, your goal is to demonstrate technical leadership, which includes expertise in knowledge, coding competency, focus on UX, and some other areas for more senior roles (conflict management, responsibility, navigating different stakeholders for product/project decisions, etc.).

If all your focus is in is just the coding questions, you’ve likely already set yourself up for failure.