This was actually a really nice process. Someone from LinkedIn reached out, screened me, and then proceeded to set up a one hour technical interview over the phone with Coderpad.io - which was at my discretion. He wasn't pushy, he was very encouraging, but he also warned me to train as much as possible.
Unfortunately, this was really my first coding interview, so I didn't know what to expect. If this is your first coding interview, I highly advise that you get some cycles in on Pramp and do A LOT of studying (written, visual, and practical). I did as much studying as I could, and while I was satisfied with my performance, I also learned my main weakness is speed. I spend a lot of time analyzing before I jump in and with less than 25 minutes a section, that's not a luxury you're afforded. Additionally, just like everyone here has said: be VERY aware of edge cases.
I didn't make it to the second interview - but that's my fault. Some on this forum say that they're looking for perfection in speed and accuracy which is completely false: that's NOT what they're looking for. They want to make sure you know what you're doing and that you're fairly good at it. To assume you won't need to be fast and accurate is a mistake, though, as this is a very competitive market and there are other candidates who can (and will) go through these problems with great speed and veracity.
The technical interview is designed to assess your awareness and application of data structures and algorithms. Facebook is looking to confirm that your problem solving skills and your ability to apply existing coding techniques is second nature; at no point during my interview was I asked to solve something impossible. If you hit any bumps in the road, you should be able to articulate what, exactly, it is that you're looking at. That is a great indicator of experience.
As for personal advice from one candidate to the next: with 25 minutes in each section, I'd highly advise re-thinking how you approach the traditional 'coding' interview. Try and target 5 minutes for each problem. That mean's unless you're SUPER fast, don't attempt to prototype a solution with a 'brute' force approach and instead have a quick discussion about classifying the problem, the edge cases, and then begin implementing the correct approach while keeping the edge cases in mind.
I had practiced for the traditional coding interview where I take the time to brute force a solution, and then optimize it, and it definitely cost me precious time. I could've jumped into the correct solution (using a while loop instead of using built ins and list comp) and knocked out one more problem.
Knowing what I know now, I would love to take a crack at this in a year. With that much time, I could definitely develop the speed I'm missing and brush up on my sorting, recursion, and graph traversals.
Finally, if you're a postgres / t-sql guy like me, PRACTICE ON CODERPAD.IO! MySQL 5.7 is missing a lot of useful features so there's a learning curve there that you can overcome by getting some reps in on coderpad.io.
Good luck!
