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.
comments
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.
b) thought process is very important actually. You can't just show up and code the most optimal solution without thought process
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.