I'm extremely well calibrated here. Conducted 400+ interviews at Meta.
You are likely borderline. For an initial screen, it depends a bit on the difficulty of the question and how clean your code was and how well you communicated your thinking process.
The 5 mins of Q&A cutoff is standard pacing and doesn't indicate anything one way or the other.
I advise people all day long about preparing for Meta interviews and my advice here if you make it to the onsite: manage the time better yourself - if you acknowledge there might be something better than O log (n), you can say "Given the time, I feel confident about writing out a clean O log (n) solution" and then write it super cleanly. You might not get a "strong hire" on the interview but you are more likely to get a "weak hire" and a "weak no hire". You can also discuss verbally the O(n) if you finish everything early and get some partial credit.
u/Interestarrer wrote (the comment Michael replied to):
Thank you so much! If I get a weak no hire, can I move to onsite or not? There is any chance I may have to give interview again like a follow up or something?
So you're saying that I can basically make no interpretation regarding the fact that the interviewer said that the solu
u/michaelnovatireplied·
If you get a weak no hire, they MIGHT do a second screen, but that's usually for MISSING SIGNAL (I can go more what this means, but it usually means something happened and the interview isn't confident in their assessment) not for just borderline performance.
Yeah it's hard to tell, if you didn't have any kind of remotely close code for the 2nd problem I would say it would be a no. So saying it looks good, is a sign that you are in the running, but ultimately the cleanliness of both the code and your communication will make the difference.
You don't have to dry run it no, that's not a hard requirement, so I wouldn't sweat that. Full dry runs can actually eat a lot of time, so I actually discourage just automatically doing them. The reason you can't compile your code at Meta is they want to see you explain your thinking process of walking through your code. If you do that extremely well while you are coding (and before) then you might not need a full dry run. If you didn't speak at all while coding, then you need a dry run so the interviewer can see you explaining your code and thought process.