In SWE coding interviews for companies like Google, Facebook, Uber, Airbnb. a) Is it almost always a reject if the interviewee was able to come up with a solution but couldn’t completely code it. Is is completely binary (1/0)? 1=selected if you are able to come up with near optimal or most optimal solution and code it bug free and vice versa. b) Or the thought process is given some value? As in his performance will be evaluated against other candidates on that question.
Following
There are a lot of factors at play, including things like interviewer didn't liked your personality, solving problem is one of them.
Can anyone share some anecdotal experiences where they were thrown a hard/tricky problem in 1-2 rounds and they were not able to come up with the most optimal solution or were not able to code the complete solution. And still made the cut and got the offer?
This absolutely depends on your interviewer. We all have our own styles and preferences--and furthermore, don't underestimate the soft skills factor. Never mind "behavioral" questions: if you come across as unlikable, or seem difficult to work with, you're probably doomed no matter how good your code is. Personally, being a high-mid/low-senior level interviewer, I'm genuinely more interested in the candidate's thought process and holistic depth of understanding--most specifically their ability to reason through trade-offs, as that (to me) is the closest analogue to real-world engineering we're going to get in 45 minutes with a contrived coding problem. To this end, I'll give candidates a single easy-ish (medium?) problem, and once they solve it one way, I'll ask them to do it another (and, if we have time, a third). At the end of this, we'll talk about how they differ and which one they should use in the real world (given some known--or unknown--set of constraints). I also like to probe lower level/practical knowledge (system-level bottlenecks, cache vs. random access, etc.). Pseudocode that somewhat strongly resembles any real language is OK, and minor bugs (error handling and missing obscure edge cases) and syntax mistakes are generally OK. I do all of this because I know we all use keyboards and IDEs in the real world and move at a measured pace (rather than writing on a whiteboard or using a plain text editor, and working under artificial time pressure) and I don't want to introduce additional noise by biasing the process towards candidates who spent a lot of time prepping. In the end, the candidate who can write at least one to my satisfaction, and comfortably describe one or two others (ideally they'd also write one--again, the problems I chose tend to be fairly easy by design), is almost always going to get my vote over the one who cranks out the one that optimizes for time complexity and can't figure out any other way to do it, or can't argue why any of the "less optimal" approaches may sometimes be preferable in real code (hint: they may be MORE optimal in other ways, such as memory use or code complexity). Hope that helps.
You sound like an amazing interviewer!
Usually there are multiple coding rounds.. in one of the rounds if you are not completely able to come up with working code, it's ok as long as you can think through the solution, discuss the bottlenecks and explain how are you planning to solve it. But you need to at least write working code for one or more of the coding rounds. In some cases if your other rounds are good and one coding round is messed up, they might give you another chance for coding interview. In general you are being hired as SWE and if you can't code your a even once, then you haven't proven that you can actually code and what will you do in the role once you join.
I don’t think any companies have truly solved this problem. Interviews are not a scientific process. At the end of the day people are giving you a thumbs up or a thumbs down and some people are harsher than others. Usually people who are newer to interviews are less lenient as they don’t know how to look for clues of how good you are other than if your solution runs correctly. So there’s a ton of false negatives.
a) absolutely not binary. This depends on many factors. b) thought process is very important actually. You can't just show up and code the most optimal solution without thought process
I understand that if you just regurgitate the solution, you obviously are going to get rejected because the interviewer would know that you memorized the solution. But if you haven’t seen the problem before and are able to recognize the correct pattern and may be come up with some solution not entirely optimal. Will you still get rejected? I guess the question is how high is the bar??
Depends on the question. Think easy vs hard ones. If you're given an easy question and can't come up with the optimal solution then I don't think you'd have a chance.